On 9/26/09 8:19 AM, Greg Smith wrote: > This means that the question you want an answer to is "if the OS cache > isn't really available, where does giving memory to shared_buffers > becomes less efficient than not caching things at all?" My guess is > that this number is much larger than 10GB, but I don't think anyone has > done any tests to try to quantify exactly where it is. Typically when > people are talking about systems as large as yours, they're dedicated > database servers at that point, so the OS cache gets considered at the > same time. If it's effectively out of the picture, the spot where > caching still helps even when it's somewhat inefficient due to buffer > contention isn't well explored.
It also depends on the filesystem. In testing at Sun and on this list, people have found that very large s_b (60% of RAM) plus directIO was actually a win on Solaris UFS, partly because UFS isn't very agressive or smart about readahead and caching. On Linux/Ext3, however, it was never a win. I don't know what AIX's filesystems are like. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
