Fri, 14 Nov 2014 16:28:16 +0000 от Shaun Thomas <sthomas@optionshouse.com>:
> Alexey,
>
> The issue is that the 1/4 memory suggestion hasn't been a recommendation in quite a while. Now that much larger
amountsof RAM are readily available, tests have been finding out that more than 8GB of RAM in shared_buffers has
diminishingor even worse returns. This is true for any version. Further, since PostgreSQL manages its own memory, and
theLinux Kernel also manages various caches, there's significant risk of storing the same memory both in
shared_buffers,and in file cache.
>
> There are other tweaks the tool probably needs, but I think this, more than anything else, needs to be updated. Until
PGsolves the issue of double-buffering (which is somewhat in progress since they're somewhat involved with the Linux
kerneldevs) you can actually give it too much memory.
>
>
> ______________________________________________
>
> 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
>
Several months ago I asked question in this channel "Why shared_buffers max is 8GB?". Many persons said, what this is
apocrypha,what 8GB is maximum value for shared_buffers. This is archive of this chat:
http://www.postgresql.org/message-id/1395836511.796897979@f327.i.mail.ru
What is why so hard to understand what to do with pgtune calculation.
--
Alexey Vasiliev