Re: High context switches occurring - Mailing list pgsql-performance

Hi there,

I see a very low performance and high context switches on our
dual itanium2 slackware box (Linux ptah 2.6.14 #1 SMP)
with 8Gb of RAM, running 8.1_STABLE. Any tips here ?

postgres@ptah:~/cvs/8.1/pgsql/contrib/pgbench$ time pgbench -s 10 -c 10 -t 3000 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 10
number of transactions per client: 3000
number of transactions actually processed: 30000/30000
tps = 163.817425 (including connections establishing)
tps = 163.830558 (excluding connections establishing)

real    3m3.374s
user    0m1.888s
sys     0m2.472s

output from vmstat 2

  2  1      0 4185104 197904 3213888    0    0     0  1456  673  6852 25  1 45 29
  6  0      0 4184880 197904 3213888    0    0     0  1456  673  6317 28  2 49 21
  0  1      0 4184656 197904 3213888    0    0     0  1464  671  7049 25  2 42 31
  3  0      0 4184432 197904 3213888    0    0     0  1436  671  7073 25  1 44 29
  0  1      0 4184432 197904 3213888    0    0     0  1460  671  7014 28  1 42 29
  0  1      0 4184096 197920 3213872    0    0     0  1440  670  7065 25  2 42 31
  0  1      0 4183872 197920 3213872    0    0     0  1444  671  6718 26  2 44 28
  0  1      0 4183648 197920 3213872    0    0     0  1468  670  6525 15  3 50 33
  0  1      0 4184352 197920 3213872    0    0     0  1584  676  6476 12  2 50 36
  0  1      0 4193232 197920 3213872    0    0     0  1424  671  5848 12  1 50 37
  0  0      0 4195536 197920 3213872    0    0     0    20  509   104  0  0 99  1
  0  0      0 4195536 197920 3213872    0    0     0  1680  573    25  0  0 99  1
  0  0      0 4195536 197920 3213872    0    0     0     0  504    22  0  0 100

processor  : 1
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 2
revision   : 2
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1600.010490
itc MHz    : 1600.010490
BogoMIPS   : 2392.06
siblings   : 1



On Mon, 19 Dec 2005, Anjan Dave wrote:


> Re-ran it 3 times on each host -
>
> Sun:
> -bash-3.00$ time pgbench -s 10 -c 10 -t 3000 pgbench
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
> number of transactions per client: 3000
> number of transactions actually processed: 30000/30000
> tps = 827.810778 (including connections establishing)
> tps = 828.410801 (excluding connections establishing)
> real    0m36.579s
> user    0m1.222s
> sys     0m3.422s
>
> Intel:
> -bash-3.00$ time pgbench -s 10 -c 10 -t 3000 pgbench
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
> number of transactions per client: 3000
> number of transactions actually processed: 30000/30000
> tps = 597.067503 (including connections establishing)
> tps = 597.606169 (excluding connections establishing)
> real    0m50.380s
> user    0m2.621s
> sys     0m7.818s
>
> Thanks,
> Anjan
>
>
>     -----Original Message-----
>     From: Anjan Dave
>     Sent: Wed 12/7/2005 10:54 AM
>     To: Tom Lane
>     Cc: Vivek Khera; Postgresql Performance
>     Subject: Re: [PERFORM] High context switches occurring
>
>
>
>     Thanks for your inputs, Tom. I was going after high concurrent clients,
>     but should have read this carefully -
>
>     -s scaling_factor
>                     this should be used with -i (initialize) option.
>                     number of tuples generated will be multiple of the
>                     scaling factor. For example, -s 100 will imply 10M
>                     (10,000,000) tuples in the accounts table.
>                     default is 1.  NOTE: scaling factor should be at least
>                     as large as the largest number of clients you intend
>                     to test; else you'll mostly be measuring update
>     contention.
>
>     I'll rerun the tests.
>
>     Thanks,
>     Anjan
>
>
>     -----Original Message-----
>     From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>     Sent: Tuesday, December 06, 2005 6:45 PM
>     To: Anjan Dave
>     Cc: Vivek Khera; Postgresql Performance
>     Subject: Re: [PERFORM] High context switches occurring
>
>     "Anjan Dave" <adave@vantage.com> writes:
>     > -bash-3.00$ time pgbench -c 1000 -t 30 pgbench
>     > starting vacuum...end.
>     > transaction type: TPC-B (sort of)
>     > scaling factor: 1
>     > number of clients: 1000
>     > number of transactions per client: 30
>     > number of transactions actually processed: 30000/30000
>     > tps = 45.871234 (including connections establishing)
>     > tps = 46.092629 (excluding connections establishing)
>
>     I can hardly think of a worse way to run pgbench :-(.  These numbers are
>     about meaningless, for two reasons:
>
>     1. You don't want number of clients (-c) much higher than scaling factor
>     (-s in the initialization step).  The number of rows in the "branches"
>     table will equal -s, and since every transaction updates one
>     randomly-chosen "branches" row, you will be measuring mostly row-update
>     contention overhead if there's more concurrent transactions than there
>     are rows.  In the case -s 1, which is what you've got here, there is no
>     actual concurrency at all --- all the transactions stack up on the
>     single branches row.
>
>     2. Running a small number of transactions per client means that
>     startup/shutdown transients overwhelm the steady-state data.  You should
>     probably run at least a thousand transactions per client if you want
>     repeatable numbers.
>
>     Try something like "-s 10 -c 10 -t 3000" to get numbers reflecting test
>     conditions more like what the TPC council had in mind when they designed
>     this benchmark.  I tend to repeat such a test 3 times to see if the
>     numbers are repeatable, and quote the middle TPS number as long as
>     they're not too far apart.
>
>                             regards, tom lane
>
>
>     ---------------------------(end of broadcast)---------------------------
>     TIP 5: don't forget to increase your free space map settings
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

     Regards,
         Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83