On 2013-12-04 14:27:10 -0200, Claudio Freire wrote: > On Wed, Dec 4, 2013 at 9:19 AM, Metin Doslu <me...@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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers