On 2/12/16 9:55 AM, Robert Haas wrote:
I think it's important to spend time and energy figuring out exactly what the problems with our current algorithm are. We know in general terms that usage counts tend to converge to either 5 or 0 and therefore sometimes evict buffers both at great cost and almost
Has anyone done testing on the best cap to usage count? IIRC 5 was pulled out of thin air. Actually, I don't recall ever seeing a clock sweep that supported more than a single bit, though often there are multiple 'pools' a buffer could be in (ie: active vs inactive in most unix VMs).
If you have a reasonable amount of 1 or 0 count buffers then this probably doesn't matter too much, but if your working set is significantly higher than shared buffers then you're probably doing a LOT of full sweeps to try and get something decremented down to 0.
randomly. But what's a lot less clear is how much that actually hurts us given that we are relying on the OS cache anyway. It may be that we need to fix some other things before or after improving the buffer eviction algorithm before we actually get a performance benefit. I suspect, for example, that a lot of the problems with large shared_buffers settings have to do with the bgwriter and checkpointer behavior rather than with the buffer eviction algorithm; and that others have to do with cache duplication between PostgreSQL and the operating system. So, I would suggest (although of course it's up to
It would be nice if there was at least an option to instrument how long an OS read request took, so that you could guage how many requests were coming from the OS vs disk. (Obviously direct knowledge from the OS is even better, but I don't think those APIs exist.)
you) that you might want to focus on experiments that will help you understand where the problems are before you plunge into writing code to fix them.
+1 -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
