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