Re: mosbench revisited
От | Jim Nasby |
---|---|
Тема | Re: mosbench revisited |
Дата | |
Msg-id | E5EE8D60-F035-4474-95CC-9124D88F0C67@nasby.net обсуждение исходный текст |
Ответ на | mosbench revisited (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: mosbench revisited
Re: mosbench revisited |
Список | pgsql-hackers |
On Aug 3, 2011, at 1:21 PM, Robert Haas wrote: > 1. "We configure PostgreSQL to use a 2 Gbyte application-level cache > because PostgreSQL protects its free-list with a single lock and thus > scales poorly with smaller caches." This is a complaint about > BufFreeList lock which, in fact, I've seen as a huge point of > contention on some workloads. In fact, on read-only workloads, with > my lazy vxid lock patch applied, this is, I believe, the only > remaining unpartitioned LWLock that is ever taken in exclusive mode; > or at least the only one that's taken anywhere near often enough to > matter. I think we're going to do something about this, although I > don't have a specific idea in mind at the moment. This has been discussed before: http://archives.postgresql.org/pgsql-hackers/2011-03/msg01406.php (which itself references2 other threads). The basic idea is: have a background process that proactively moves buffers onto the free list so that backends should normallynever have to run the clock sweep (which is rather expensive). The challenge there is figuring out how to get stuffonto the free list with minimal locking impact. I think one possible option would be to put the freelist under it'sown lock (IIRC we currently use it to protect the clock sweep as well). Of course, that still means the free list lockcould be a point of contention, but presumably it's far faster to add or remove something from the list than it is torun the clock sweep. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: