On Wed, Mar 23, 2011 at 1:53 PM, Jim Nasby <j...@nasby.net> wrote: > When we started using 192G servers we tried switching our largest OLTP > database (would have been about 1.2TB at the time) from 8GB shared buffers to > 28GB. Performance went down enough to notice; I don't have any solid metrics, > but I'd ballpark it at 10-15%. > > One thing that I've always wondered about is the logic of having backends run > the clocksweep on a normal basis. OS's that use clock-sweep have a dedicated > process to run the clock in the background, with the intent of keeping X > amount of pages on the free list. We actually have most of the mechanisms to > do that, we just don't have the added process. I believe bg_writer was > intended to handle that, but in reality I don't think it actually manages to > keep much of anything on the free list. Once we have a performance testing > environment I'd be interested to test a modified version that includes a > dedicated background clock sweep process that strives to keep X amount of > buffers on the free list.
It looks like the only way anything can ever get put on the free list right now is if a relation or database is dropped. That doesn't seem too good. I wonder if the background writer shouldn't be trying to maintain the free list. That is, perhaps BgBufferSync() should notice when the number of free buffers drops below some threshold, and run the clock sweep enough to get it back up to that threshold. On a related note, I've been thinking about whether we could make bgwriter_delay adaptively self-tuning. If we notice that we overslept, we don't sleep as long the next time; if not much happens while we sleep, we sleep longer the next time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
