On Mon, 2005-02-21 at 18:45 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > ...but do you agree with my comments on the lack of scalability in cache > > miss situations? > > No. Grabbing a lock during a cache miss is the least of your worries; > you're going to do I/O, or at least a kernel call, so it hardly matters > as long as you're not holding the lock for a time that's long in > comparison to that overhead.
The I/O does alleviate contention to a certain extent, but if you have a well laid out system that can soak up the I/O you're throwing AND you have multiple CPUs trying to get at blocks, then you have contention. The other problem is the OS cache. A PostgreSQL cache miss isn't necessarily an I/O. If PostgreSQL more easily supported very large shared_buffers then I would be more in agreement. > The only test case I've seen that exposes a significant amount of bufmgr > contention is one that involves zero I/O (100% cache hit rate), so that > the fraction of time spent holding the BufMgrLock is a significant part > of the total time. As soon as you move off 100%, the bufmgr isn't the > critical path anymore. So I think the fact that this redesign is able > to reduce the contention at all in that case is just gravy. (It does > reduce contention because ReleaseBuffer doesn't take a global lock > anymore, and because BufMappingLock and BufFreelistLock are separate > locks.) Let's talk about Mark's TPC-C like tests. As soon as the cache is full, the response times go to hell. (see http://www.osdl.org/projects/dbt2dev/results/dev4-010/264/) Once the cache is full, each dirty cache miss costs two BufMgrLock calls. On larger caches, very roughly 80% of the cache is dirty, so the overall rise in contention is around 1.6 times what it was before. I see that as a possible indicator of the effects of BufMgrLock contention. (It does > reduce contention because ReleaseBuffer doesn't take a global lock > anymore, and because BufMappingLock and BufFreelistLock are separate > locks.) Yes, understood. > If testing shows that we still have contention issues with this design > then we can try subdividing the BufFreelistLock --- but right now my > guess is that we'd just be giving up more cache management efficiency > in return for not much. OK to that. [and please remember, all, that I'm discussing the very highest end of performance architecture...] Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])