Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Greg Smith wrote:
On Fri, 15 Feb 2008, Peter Schuller wrote:

Or is it a matter of PostgreSQL doing non-direct I/O, such that
anything cached in shared_buffers will also be cached by the OS?

PostgreSQL only uses direct I/O for writing to the WAL; everything else goes through the regular OS buffer cache unless you force it to do otherwise at the OS level (like some Solaris setups do with forcedirectio). This is one reason it still make not make sense to give an extremely high percentage of RAM to PostgreSQL even with improvements in managing it. Another is that shared_buffers memory has to be reconciled with disk at every checkpoint, where OS buffers do not. A third is that your OS may just be more efficient at buffering--it knows more about the underlying hardware, and the clock-sweep method used internally by PostgreSQL to simulate a LRU cache is not extremely sophisticated.

However, don't feel limited by the general 25% rule; it's certainly worth exploring whether 50% or more works better for your workload. You'll have to benchmark that yourself though, and I'd suggest using pg_buffercache: http://www.postgresql.org/docs/8.3/static/pgbuffercache.html to get an idea just what the pages are being used for.


As per the test that I have done mostly with forcedirectio on Solaris, I have seen gains with increasing the buffercache to about somewhere between 10GB and thats when thing seem to take a turn...

So in my case I am generally comfortable for Postgres to use about 8-10GB beyond which I am cautious.

Also with tests with UFS buffered for table/index and forcedirectio it seems to perform better with forcedirectio .. However if you do want to exploit the extra RAM with UFS then you have to do some tunings for UFS in Solaris.. Now with machines with 32GB becoming common this is something worth pursuing depending on the storage if it can handle the directio load or not.


Regards,
Jignesh




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux