Fri, 14 Nov 2014 16:28:16 +0000 от Shaun Thomas <stho...@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 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@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.796897...@f327.i.mail.ru
What is why so hard to understand what to do with pgtune calculation.
--
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
