pg.ddx.io pgsql-performance@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Alexey Vasiliev <leopard_ne@inbox.ru>
To: Shaun Thomas <sthomas@optionshouse.com>
Cc: 'Josh Berkus' <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: [PERFORM] pgtune + configurations with 9.3
Date: Fri, 14 Nov 2014 19:40:19 +0300
Message-ID: <1415983219.686386092@f34.i.mail.ru> (raw)
In-Reply-To: <0683F5F5A5C7FE419A752A034B4A0B9797DCD287@sswchi5pmbx2.peak6.net>
References: <CAEaSS0bLy8=1yVVbAH6us3m5d1tQ9obCxeHHeTU6vrqkggcN+g@mail.gmail.com>
<1415975036.62330340@f358.i.mail.ru>
<0683F5F5A5C7FE419A752A034B4A0B9797DCD287@sswchi5pmbx2.peak6.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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 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.796897979@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
view thread (14+ messages) latest in thread
Message-ID: <1415983219.686386092@f34.i.mail.ru> Permalink: ../1415983219.686386092@f34.i.mail.ru/ Also on: postgresql.org/message-id/1415983219.686386092@f34.i.mail.ru ·
reply
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Reply to all the recipients using the --to and --cc options: reply via email To: pgsql-performance@postgresql.org Cc: leopard_ne@inbox.ru, sthomas@optionshouse.com, josh@agliodbs.com Subject: Re: [PERFORM] pgtune + configurations with 9.3 In-Reply-To: <1415983219.686386092@f34.i.mail.ru> * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox
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