On 03/17/2011 11:13 AM, Jeff wrote:
three boxes:
A: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (Runs query
fastest)
4MB cache
B: Quad-Core AMD Opteron(tm) Processor 2352 (2.1GHZ) (Main
production box, currently, middle speed)
512k cache
C: Quad-Core AMD Opteron(tm) Processor 2378 (2.4GHZ)
512k cache
It's possible that transfer speed between the CPU and memory are very
different between these systems when running a single-core operation.
Intel often has an advantage there; I don't have any figures on this
generation of processors to know for sure though. If you can get some
idle time to run my stream-scaling tool from
https://github.com/gregs1104/stream-scaling that might give you some
insight.
Now here's where some odd stuff starts piling up: explain analyze
overhead on said queries:
20ms on A, 50ms on B and 85ms on C(!!)
I found an example in my book where EXPLAIN ANALYZE took a trivial
COUNT(*) query from 8ms to 70ms. It's really not cheap for some sorts
of things.
I know we're running an old kernel, I'm tempted to upgrade to see what
will happen, but at the same time I'm afraid it'll upgrade to a kernel
with a broken [insert major subsystem here] which has happened before.
Running a production server on Fedora Core is a scary operation pretty
much all the time. That said, I wouldn't consider 2.6.27 to be an old
kernel--not when RHEL5 is still using 2.6.18. The kernel version you
get for FC10 is probably quite behind on updates, though, relative to a
kernel.org one that has kept getting bug fixes.
--
Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
