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@xxxxxxxxxxxxx] 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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@xxxxxxxxxx, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83
