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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
Следующее
От: Rajkumar Raghuwanshi
Дата:
Сообщение: Re: Declarative partitioning - another take