Re: Parallel Select query performance and shared buffers
От | Claudio Freire |
---|---|
Тема | Re: Parallel Select query performance and shared buffers |
Дата | |
Msg-id | CAGTBQpb5_K-_YY96D-CRh=mKq6AQW45ztptV5akCNUuV7jxR_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Select query performance and shared buffers (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Parallel Select query performance and shared buffers
Re: Parallel Select query performance and shared buffers |
Список | pgsql-hackers |
On Wed, Dec 4, 2013 at 1:54 PM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-12-04 18:43:35 +0200, Metin Doslu wrote: >> > I'd strongly suggest doing a "perf record -g -a <wait a bit, ctrl-c>; >> > perf report" run to check what's eating up the time. >> >> Here is one example: >> >> + 38.87% swapper [kernel.kallsyms] [k] hypercall_page >> + 9.32% postgres [kernel.kallsyms] [k] hypercall_page >> + 6.80% postgres [kernel.kallsyms] [k] xen_set_pte_at > > All that time is spent in your virtualization solution. One thing to try > is to look on the host system, sometimes profiles there can be more > meaningful. You cannot profile the host on EC2. You could try HVM. I've noticed it fare better under heavy CPU load, and it's not fully-HVM (it still uses paravirtualized network and I/O).
В списке pgsql-hackers по дате отправления: