Fri, 14 Nov 2014 16:28:16 +0000 от Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx>: > Alexey, > > The issue is that the 1/4 memory suggestion hasn't been a recommendation in quite a while. Now that much larger amounts of RAM are readily available, tests have been finding out that more than 8GB of RAM in shared_buffers has diminishing or even worse returns. This is true for any version. Further, since PostgreSQL manages its own memory, and the Linux 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 PG solves the issue of double-buffering (which is somewhat in progress since they're somewhat involved with the Linux kernel devs) 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@xxxxxxxxxxxxxx) > 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@xxxxxxxxxxxxxx What is why so hard to understand what to do with pgtune calculation. -- Alexey Vasiliev -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
