Re: strange case of kernel performance regression (4.3.x and newer)

Поиск
Список
Период
Сортировка
От Catalin Iacob
Тема Re: strange case of kernel performance regression (4.3.x and newer)
Дата
Msg-id CAHg_5grw4zHvfnnE8VfhjSdbazHbH7U+p5icPrp4v-vDJdgenA@mail.gmail.com
обсуждение исходный текст
Ответ на strange case of kernel performance regression (4.3.x and newer)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> Over the past couple of days I've been doing a bit of benchmarking for the
> "group clog" patch [1], and I've ran into what I suspect might be a fairly
> serious performance regression on newer kernels (essentially 4.3.0 and
> newer). I got to a point where I need help with further investigation,
> testing on other systems etc.
>
> The workload tested in the patch [1] is quite simple - a transaction with 3
> x SELECT FOR UPDATE queries and 2 x SAVEPOINT on unlogged tables. The
> results (average tps from 5 x 5 minute runs, for 32 and 64 clients) on
> multiple kernels look like this:
>
>     kernel          32           64
>    ---------------------------------
>     3.19.8       48524        59291
>     4.1.33       47193        59574
>     4.2.8        48901        59877
>     4.3.0        32187        38970
>     4.3.6        31889        38815
>     4.4.0        31946        37702
>     4.4.23       31498        37724
>     4.5.5        31531        37351
>     4.7.6        32859        38490

Just stumbled upon this old thread.

Since the regression is very clear and reproduceable and on a vanilla
kernel I don't think you need more testing. The kernel devs or at
least Linus take regressions (including performance) very seriously,
even if it's theoretically not the kernel's fault (so in this case
regardless what Postgres is doing).

I think you should just report it to lkml. If you have time to do a
bisection between 4.2.8 and 4.3.0 and find the offending commit that
would be even better, then email the author and CC lkml and Linus,
that should be enough to get it fixed.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Add support for restrictive RLS policies