Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXqxe-0005rK-Te for pgsql-performance@arkaria.postgresql.org; Wed, 09 Apr 2014 11:46:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WXqxe-0006iF-E1 for pgsql-performance@arkaria.postgresql.org; Wed, 09 Apr 2014 11:46:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXqxd-0006i8-9z for pgsql-performance@postgresql.org; Wed, 09 Apr 2014 11:46:33 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WXqxZ-0006sC-6A for pgsql-performance@postgresql.org; Wed, 09 Apr 2014 11:46:31 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1WXqxX-00018T-52; Wed, 09 Apr 2014 07:46:27 -0400 Date: Wed, 9 Apr 2014 07:46:27 -0400 From: Bruce Momjian To: Alexey Klyukin Cc: Alexey Vasiliev , pgsql-performance@postgresql.org Subject: Re: Why shared_buffers max is 8GB? Message-ID: <20140409114627.GA8686@momjian.us> References: <1395836511.796897979@f327.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.2 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Wed, Apr 2, 2014 at 11:38:57AM +0200, Alexey Klyukin wrote: > In most cases 8GB should be enough even for the servers with hundreds of GB of > data, since the FS uses the rest of the memory as a cache (make sure you give a > hint to the planner on how much memory is left for this with the > effective_cache_size), but the exact answer is a matter of performance testing. > > Now, the last question would be what was the initial justification for the 8GB > barrier, I've heard that there were a lock congestion when dealing with huge > pool of buffers, but I think that was fixed even in the pre-9.0 era. The issue in earlier releases was the overhead of managing more then 1 million 8k buffers. I have not seen any recent tests to confirm that overhead is still significant. A larger issue is that going over 8GB doesn't help unless you are accessing more than 8GB of data in a short period of time. Add to that the problem if potentially dirtying all the buffers and flushing it to a now-smaller kernel buffer cache, and you can see why the 8GB limit is recommended. I do think this merits more testing against the current Postgres source code. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance