Re: Patch: fix lock contention for HASHHDR.mutex
Вложения
В списке pgsql-hackers по дате отправления:
| От | Aleksander Alekseev |
|---|---|
| Тема | Re: Patch: fix lock contention for HASHHDR.mutex |
| Дата | |
| Msg-id | 20151217190342.07e4533a@fujitsu обсуждение исходный текст |
| Ответ на | Re: Patch: fix lock contention for HASHHDR.mutex (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Patch: fix lock contention for HASHHDR.mutex
Re: Patch: fix lock contention for HASHHDR.mutex |
| Список | pgsql-hackers |
> It'd really like to see it being replaced by a queuing lock > (i.e. lwlock) before we go there. And then maybe partition the > freelist, and make nentries an atomic. I believe I just implemented something like this (see attachment). The idea is to partition PROCLOCK hash table manually into NUM_LOCK_ PARTITIONS smaller and non-partitioned hash tables. Since these tables are non-partitioned spinlock is not used and there is no lock contention. On 60-core server we gain 3.5-4 more TPS according to benchmark described above. As I understand there is no performance degradation in other cases (different CPU, traditional pgbench, etc). If this patch seems to be OK I believe we could consider applying the same change not only to PROCLOCK hash table.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера