On Wednesday, July 03, 2013 12:27 PM Simon Riggs wrote: On 28 June 2013 05:52, Amit Kapila <amit.kap...@huawei.com> wrote: >> As per my understanding Summarization of points raised by you and Andres >> which this patch should address to have a bigger win:
>> 1. Bgwriter needs to be improved so that it can help in reducing usage count >> and finding next victim buffer >> (run the clock sweep and add buffers to the free list). >>2. SetLatch for bgwriter (wakeup bgwriter) when elements in freelist are >>less. >>3. Split the workdone globallock (Buffreelist) in StrategyGetBuffer >> (a spinlock for the freelist, and an lwlock for the clock sweep). >>4. Separate processes for writing dirty buffers and moving buffers to >>freelist >>5. Bgwriter needs to be more aggressive, logic based on which it calculates >>how many buffers it needs to process needs to be improved. >>6. There can be contention around buffer mapping locks, but we can focus on >>it later >>7. cacheline bouncing around the buffer header spinlocks, is there anything >>we can do to reduce this? >My perspectives here would be > * BufFreelistLock is a huge issue. Finding a next victim block needs to be an O(1) operation, yet it is currently much worse than that. Measuring > contention on that lock hides that problem, since having shared buffers lock up for 100ms or more but only occasionally is a huge problem, even if it > doesn't occur frequently enough for the averaged contention to show as an issue. To optimize finding next victim buffer, I am planning to run the clock sweep in background. Apart from that do you have any idea to make it closer to O(1)? With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
