Re: [HACKERS] Parallel Select query performance and shared buffers

On 2013-12-04 14:27:10 -0200, Claudio Freire wrote:
> On Wed, Dec 4, 2013 at 9:19 AM, Metin Doslu <metin(at)citusdata(dot)com> wrote:
> >
> > Here are the results of "vmstat 1" while running 8 parallel TPC-H Simple
> > (#6) queries: Although there is no need for I/O, "wa" fluctuates between 0
> > and 1.
> >
> > procs -----------memory---------- ---swap-- -----io---- --system--
> > -----cpu-----
> > r b swpd free buff cache si so bi bo in cs us sy id wa st
> > 0 0 0 30093568 84892 38723896 0 0 0 0 22 14 0 0 100 0 0
> > 8 1 0 30043056 84892 38723896 0 0 0 0 27080 52708 16 14 70 0 0
> > 8 1 0 30006600 84892 38723896 0 0 0 0 44952 118286 43 44 12 1 0
> > 8 0 0 29986264 84900 38723896 0 0 0 20 28043 95934 49 42 8 1 0
> > 7 0 0 29991976 84900 38723896 0 0 0 0 8308 73641 52 42 6 0 0
> > 0 0 0 30091828 84900 38723896 0 0 0 0 3996 30978 23 24 53 0 0
> > 0 0 0 30091968 84900 38723896 0 0 0 0 17 23 0 0 100 0 0
>
>
> Notice the huge %sy

My bet is on transparent hugepage defragmentation. Alternatively it's
scheduler overhead, due to superflous context switches around the buffer
mapping locks.

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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services