pg.ddx.io pgsql-performance@postgresql.org mailing list archive help / color / mirror / Atom feed From: Andres Freund <andres@2ndquadrant.com>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Metin Doslu <metin@citusdata.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Parallel Select query performance and shared buffers
Date: Wed, 4 Dec 2013 17:33:50 +0100
Message-ID: <20131204163350.GA5756@awork2.anarazel.de> (raw )
In-Reply-To: <CAGTBQpbRNt7oK9Z9dJpN_ChV4TqBZpYD+634Zm1wg4NjC_Zx2w@mail.gmail.com >
References: <CAL1dPcfZJFO2gr+53mU14VrrHxT-Bs6QOYgzQNV_VgxnkKUaZA@mail.gmail.com >
<CAA4eK1+RaLg9dfici05QL_r=G5uZ3Zi=BGJ8C0pVCJ9o9V_s+A@mail.gmail.com >
<CAGTBQpZCtDHhifv6m3EJrB5CZu3bnyqYHweM8-0G=cVm-n9V0A@mail.gmail.com >
<CAL1dPce3Fe6nPwKwSe_2njOBHPp5qkLYHJzCBUqE-cfFGy9ctA@mail.gmail.com >
<CAGTBQpbRNt7oK9Z9dJpN_ChV4TqBZpYD+634Zm1wg4NjC_Zx2w@mail.gmail.com >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 2013-12-04 14:27:10 -0200, Claudio Freire wrote:
> On Wed, Dec 4, 2013 at 9:19 AM, Metin Doslu <metin@citusdata.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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
view thread (37+ messages) latest in thread
Message-ID: <20131204163350.GA5756@awork2.anarazel.de>
Permalink: ../20131204163350.GA5756@awork2.anarazel.de/
Also on: postgresql.org/message-id/20131204163350.GA5756@awork2.anarazel.de
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andres@2ndquadrant.com, klaussfreire@gmail.com, metin@citusdata.com, amit.kapila16@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Parallel Select query performance and shared buffers
In-Reply-To: <20131204163350.GA5756@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox