On Tue, Jul 28, 2009 at 2:58 PM, Merlin Moncure<mmoncure@xxxxxxxxx> wrote: > On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt<dave@xxxxxxxxxxxxxxxxxxx> wrote: >> On 01/-10/-28163 11:59 AM, Greg Smith wrote: >>> On Tue, 21 Jul 2009, Doug Hunley wrote: >>> >>>> Just wondering is the issue referenced in >>>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php >>>> is still present in 8.4 or if some tunable (or other) made the use of >>>> hyperthreading a non-issue. We're looking to upgrade our servers soon >>>> for performance reasons and am trying to determine if more cpus (no >>>> HT) or less cpus (with HT) are the way to go. >>> >>> If you're talking about the hyperthreading in the latest Intel Nehalem >>> processors, I've been seeing great PostgreSQL performance from those. >>> The kind of weird behavior the old generation hyperthreading designs >>> had seems gone. You can see at >>> http://archives.postgresql.org/message-id/alpine.GSO.2.01.0907222158050.16713@xxxxxxxxxxx >>> that I've cleared 90K TPS on a 16 core system (2 quad-core >>> hyperthreaded processors) running a small test using lots of parallel >>> SELECTs. That would not be possible if there were HT spinlock >>> problems still around. There have been both PostgreSQL scaling >>> improvments and hardware improvements since the 2005 messages you saw >>> there that have combined to clear up the issues there. While true >>> cores would still be better if everything else were equal, it rarely >>> is, and I wouldn't hestitate to jump on Intel's bandwagon right now. >> >> Greg, those are compelling numbers for the new Nehalem processors. >> Great news for postgresql. Do you think it's due to the new internal >> interconnect, that bears a strong resemblance to AMD's hypertransport > [snip] > > as a point of reference, here are some numbers on a quad core system > (2xintel 5160) using the old pgbench, scaling factor 10: > > pgbench -S -c 16 -t 10000 > starting vacuum...end. > transaction type: SELECT only > scaling factor: 10 > query mode: simple > number of clients: 16 > number of transactions per client: 10000 > number of transactions actually processed: 160000/160000 > tps = 24088.807000 (including connections establishing) > tps = 24201.820189 (excluding connections establishing) > > This shows actually my system (pre-Nehalem) is pretty close clock for > clock, albeit thats not completely fair..I'm using only 4 cores on > dual core procs. Still, these are almost two years old now. > > EDIT: I see now that Greg has only 8 core system not counting > hyperthreading...so I'm getting absolutely spanked! Go Intel! > > Also, I'm absolutely dying to see some numbers on the high end > W5580...if anybody has one, please post! Just FYI, I ran the same basic test but with -c 10 since -c shouldn't really be greater than -s, and got this: pgbench -S -c 10 -t 10000 starting vacuum...end. transaction type: SELECT only scaling factor: 10 number of clients: 10 number of transactions per client: 10000 number of transactions actually processed: 100000/100000 tps = 32855.677494 (including connections establishing) tps = 33344.826183 (excluding connections establishing) With -s at 16 and -c at 16 I got this: pgbench -S -c 16 -t 10000 starting vacuum...end. transaction type: SELECT only scaling factor: 16 number of clients: 16 number of transactions per client: 10000 number of transactions actually processed: 160000/160000 tps = 32822.559602 (including connections establishing) tps = 33266.308652 (excluding connections establishing) That's on dual Quad-Core AMD Opteron(tm) Processor 2352 CPUs (2.2GHz) and 16 G ram. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
