On 5/13/09 11:21 PM, "Arjen van der Meijden" <acmmailing@xxxxxxxxxxxx> wrote: > On 13-5-2009 20:39 Scott Carey wrote: >> Excellent! That is a pretty huge boost. I'm curious which aspects of this >> new architecture helped the most. For Postgres, the following would seem >> the most relevant: >> 1. Shared L3 cache per processors -- more efficient shared datastructure >> access. >> 2. Faster atomic operations -- CompareAndSwap, etc are much faster. >> 3. Faster cache coherency. >> 4. Lower latency RAM with more overall bandwidth (Opteron style). > > Apart from that, it has a newer debian (and thus kernel/glibc) and a > slightly less constraining IO which may help as well. > >> Can you do a quick and dirty memory bandwidth test? (assuming linux) >> On the older X5355 machine and the newer E5540, try: >> /sbin/hdparm -T /dev/sd<device> > > It is in use, so the results may not be so good, this is the best I got > on our dual X5355: > Timing cached reads: 6314 MB in 2.00 seconds = 3159.08 MB/sec > > But this is the best I got for a (also in use) Dual E5450 we have: > Timing cached reads: 13158 MB in 2.00 seconds = 6587.11 MB/sec > > And here the best for the (idle) E5540: > Timing cached reads: 16494 MB in 2.00 seconds = 8256.27 MB/sec > > These numbers are with hdparm v8.9 Thanks! My numbers were with hdparm 6.6 (Centos 5.3) -- so they aren't directly comparable. FYI When my systems are in use, the results are typically 50% to 75% of the idle scores. But, yours probably are roughly comparable to each other -- you're getting more than 2x the memory bandwidth between those systems. Without knowing the exact chipset and RAM configurations, this is definitely a factor in the performance difference at higher concurrency. > > Best regards, > > Arjen > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
