pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feed Re[2]: [PERFORM] pgtune + configurations with 9.3
3+ messages / 2 participants
[nested] [flat]
* Re[2]: [PERFORM] pgtune + configurations with 9.3
@ 2014-11-14 14:23 Alexey Vasiliev <leopard_ne@inbox.ru>
1 sibling, 0 replies; 3+ messages in thread
From: Alexey Vasiliev @ 2014-11-14 14:23 UTC (permalink / raw)
To: Shaun Thomas <sthomas@optionshouse.com>; +Cc: 'Josh Berkus' <josh@agliodbs.com>; pgsql-performance
Fri, 7 Nov 2014 14:13:20 +0000 от Shaun Thomas <sthomas@optionshouse.com>:
>> Yeah, pgTune is pretty badly out of date. It's been on my TODO list, as
>> I'm sure it has been on Greg's.
>
>Yeah. And unfortunately the recommendations it gives have been spreading. Take a look at the online version:
>
>http://pgtune.leopard.in.ua/
>
>I entered a pretty typical 92GB system, and it recommended 23GB of shared buffers. I tried to tell the author the performance guidelines have since changed, but it didn't help.
>
>
>______________________________________________
>
>See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
>
>
>--
>Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance
Hello, author of http://pgtune.leopard.in.ua/ is here.
I think everyone can do pull request to it. Old one take 25% for shared_buffers and 75% for effective_cache_size. I think I can even add selector with version of postgresql (9.0 - 9.4) and in this case change formulas for 9.4 (for example).
But I don't know what type of calculation should be in this case. Does we have in some place this information? Or someone can provide it? Because this generator should be valid for most users.
Thanks.
---
Alexey Vasiliev
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re[2]: [PERFORM] pgtune + configurations with 9.3
@ 2014-11-14 19:10 Alexey Vasiliev <leopard_ne@inbox.ru>
1 sibling, 1 reply; 3+ messages in thread
From: Alexey Vasiliev @ 2014-11-14 19:10 UTC (permalink / raw)
To: Shaun Thomas <sthomas@optionshouse.com>; +Cc: 'Josh Berkus' <josh@agliodbs.com>; pgsql-performance
Fri, 14 Nov 2014 17:06:54 +0000 от Shaun Thomas <sthomas@optionshouse.com>:
> Alexey,
>
> The issue is not that 8GB is the maximum. You *can* set it higher. What I'm saying, and I'm not alone in this, is that setting it higher can actually decrease performance for various reasons. Setting it to 25% of memory on a system with 512GB of RAM for instance, would be tantamount to disaster. A checkpoint with a setting that high could overwhelm pretty much any disk controller and end up completely ruining DB performance. And that's just *one* of the drawbacks.
>
>
>
> ______________________________________________
>
> See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
Ok. Just need to know what think another developers about this - should pgtune care about this case? Because I am not sure, what users with 512GB will use pgtune.
--
Alexey Vasiliev
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Re[2]: [PERFORM] pgtune + configurations with 9.3
@ 2014-11-17 04:52 Stuart Bishop <stuart@stuartbishop.net>
parent: Alexey Vasiliev <leopard_ne@inbox.ru>
0 siblings, 0 replies; 3+ messages in thread
From: Stuart Bishop @ 2014-11-17 04:52 UTC (permalink / raw)
To: Alexey Vasiliev <leopard_ne@inbox.ru>; +Cc: Shaun Thomas <sthomas@optionshouse.com>; Josh Berkus <josh@agliodbs.com>; pgsql-performance
On 15 November 2014 02:10, Alexey Vasiliev <leopard_ne@inbox.ru> wrote:
> Ok. Just need to know what think another developers about this - should pgtune care about this case? Because I am not sure, what users with 512GB will use pgtune.
pgtune should certainly care about working with large amounts of RAM.
Best practice does not stop at 32GB of RAM, but instead becomes more
and more important. I am not interested in edge cases or unusual
configurations. I am interested in setting decent defaults to provide
a good starting point to administrators on all sizes of hardware.
I use pgtune to configure automatically deployed cloud instances. My
goal is to prepare instances that have been tuned according to best
practice for standard types of load. Administrators will ideally not
need to tweak anything themselves, but at a minimum have been
provided with a good starting point. pgtune does a great job of this,
apart from the insanely high shared_buffers. At the moment I run
pgtune, and then must reduce shared_buffers to 8GB if pgtune tried to
select a higher value. The values it is currently choosing on higher
RAM boxes are not best practice and quite wrong.
The work_mem settings also seem to be very high, but so far have not
posed a problem and may well be correct. I'm trusting pgtune here
rather than my outdated guesses.
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2014-11-17 04:52 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-11-14 14:23 ` Alexey Vasiliev <leopard_ne@inbox.ru>
2014-11-14 19:10 ` Alexey Vasiliev <leopard_ne@inbox.ru>
2014-11-17 04:52 ` Stuart Bishop <stuart@stuartbishop.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox