Re: Reducing contention for the LockMgrLock
От | Simon Riggs |
---|---|
Тема | Re: Reducing contention for the LockMgrLock |
Дата | |
Msg-id | 1134034701.2906.1056.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Reducing contention for the LockMgrLock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reducing contention for the LockMgrLock
|
Список | pgsql-hackers |
On Wed, 2005-12-07 at 22:46 -0500, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Is hashtable overhead all that large? Each table could be made > > initially size-of-current-table/N entries. One problem is that > > currently the memory freed from a hashtable is not put back into shmem > > freespace, is it? > > Yeah; the problem is mainly that we'd have to allocate extra space to > allow for unevenness of usage across the multiple hashtables. It's hard > to judge how large the effect would be without testing, but I think that > this problem would inhibit us from having dozens or hundreds of separate > partitions. The imbalance across partitions would be a major issue because of the difficulty of selecting a well-distributed partitioning key. If you use the LOCKTAG, then operations on the heaviest hit tables would go to the same partitions continually for LockRelation requests. The frequency of access per table usually drops off dramatically in rank order: look at TPC-B (pgbench) and TPC-C; my own experience would be that you seldom have as many even as 16 heavy hit tables. My guess would be that doing all of that would do little more than reduce contention to ~50%, and that this would show quickly diminishing returns for N > 4. Also, the more sharply defined your application profile, the worse this effect will be. Having said that, I think this *is* the best way forward *if* we continue to accept the barrage of lock requests. So I've reopened the debate on the earlier thread: [HACKERS] Reducing relation locking overhead and am reviewing thoughts/requirements on that thread to avoid the necessity of altering the lock manager in this way. pgbench is the right workload to expose this effect and measure worst case contention, so at least performance gains are easy to measure. > A possible response is to try to improve dynahash.c to make its memory > management more flexible, but I'd prefer not to get into that unless > it becomes really necessary. A shared freespace pool would create a > contention bottleneck of its own... ...but a less frequently accessed one. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: