Kenneth Marshall would like me to post this:
I agree that in order to manage today's large memory machines, we
need to have less contention in our buffer management strategies.
The two main main choke points are in the buffer hash table routines
and in the buffer management linked lists. Unfortunately most of the
code depends on holding the bufmgr lock on entry which eliminates
many chances for parallelism.

The number of buffer pools should at the very minimum be equal to
the number of processors in the system. This can allow us to greatly
reduce the number of cache-sync cycles if each processor has its
own lock structures for T1-cpuN, T2-cpuN. Now when we allocate a new
buffer, preferentially grab a buffer from the cpu specific queue before
looking in the other queues. Now we have already decreased the amount
of contention by approximately (1/numberCPUs).

The next item to address is the buf_table concurrency. It appears that
the same code that was used in the hash index update by Tom Lane could
be used to split the buf_table accesses into a per-bucket access using
a per-bucket lock and not a global lock. Modifying the current dyn_hash
search and update code would make it look effectively like Mr. Lane's
new hash index code.

The final issue is the churn in the MRU/LRU positions on the buffer
management lists. Currently, we always remove a buffer from the list
(T1, T2,...) and then add it to the new list in the MRU position. On
a busy system, for a given query mix a subset of the buffers will be
very busy and compete for the MRU position. What we want to do is
avoid moving a buffer near the top of the list for some definition
of top. One idea, is to have a "per-CPU per-T* counter" which is
incremented as buffers are added to the MRU position. The key is to
store the counter value in the header. Now when we access the buffer
in the list, if the counter is within a value (settable by a GUC)
the buffer is not moved. This would reduce the MRU churn for the
busy buffers near the top of the lists.

These ideas are very similar to your own speculations. I hope that
their slightly different slant can contribute to this discussion.
Thank you for your time.

Yours truly,
Kenneth Marshall

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 15 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 30, '03 at 4:15a
activeFeb 23, '04 at 2:33p
posts15
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase