Re: Profiling PostgreSQL

Поиск
Список
Период
Сортировка
От Dimitris Karampinas
Тема Re: Profiling PostgreSQL
Дата
Msg-id CAC_Q3Ny1hfnOSXJfU76D4-H5o2TgQB2emC=zChneiH+mr01+nQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Profiling PostgreSQL  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Profiling PostgreSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Profiling PostgreSQL  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
Thanks for your answers. A script around pstack worked for me.

(I'm not sure if I should open a new thread, I hope it's OK to ask another question here)

For the workload I run it seems that PostgreSQL scales with the number of concurrent clients up to the point that these reach the number of cores (more or less).
Further increase to the number of clients leads to dramatic performance degradation. pstack and perf show that backends block on LWLockAcquire calls, so, someone could assume that the reason the system slows down is because of multiple concurrent transactions that access the same data.
However I did the two following experiments:
1) I completely removed the UPDATE transactions from my workload. The throughput turned out to be better yet the trend was the same. Increasing the number of clients, has a very negative performance impact.
2) I deployed PostgreSQL on more cores. The throughput improved a lot. If the problem was due to concurrecy control, the throughput should remain the same - no matter the number of hardware contexts. 

Any insight why the system behaves like this ?

Cheers,
Dimitris


On Fri, May 23, 2014 at 1:39 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, May 22, 2014 at 10:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Call graph data usually isn't trustworthy unless you built the program
> with -fno-omit-frame-pointer ...
This page is full of ideas as well:
https://wiki.postgresql.org/wiki/Profiling_with_perf
--
Michael

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

Предыдущее
От: "Huang, Suya"
Дата:
Сообщение: Re: same query different execution plan (hash join vs. semi-hash join)
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Profiling PostgreSQL