Re: Speed up Clog Access by increasing CLOG buffers
От | Tomas Vondra |
---|---|
Тема | Re: Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | 3cc206fa-7d36-f020-3856-12ed405e2535@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
|
Список | pgsql-hackers |
Hi, After collecting a lot more results from multiple kernel versions, I can confirm that I see a significant improvement with 128 and 192 clients, roughly by 30%: 64 128 192 ------------------------------------------------ master 62482 43181 50985 granular-locking 61701 59611 47483 no-content-lock 62650 59819 47895 group-update 63702 64758 62596 But I only see this with Dilip's workload, and only with pre-4.3.0 kernels (the results above are from kernel 3.19). With 4.5.5, results for the same benchmark look like this: 64 128 192 ------------------------------------------------ master 35693 39822 42151 granular-locking 35370 39409 41353 no-content-lock 36201 39848 42407 group-update 35697 39893 42667 That seems like a fairly bad regression in kernel, although I have not identified the feature/commit causing it (and it's also possible the issue lies somewhere else, of course). With regular pgbench, I see no improvement on any kernel version. For example on 3.19 the results look like this: 64 128 192 ------------------------------------------------ master 54661 61014 59484 granular-locking 55904 62481 60711 no-content-lock 56182 62442 61234 group-update 55019 61587 60485 I haven't done much more testing (e.g. with -N to eliminate collisions on branches) yet, let's see if it changes anything. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: