Re: Excessive context switching on SMP Xeons - Mailing list pgsql-performance

A few quick random observations on the Xeon v. Opteron comparison:

-  running a dual Xeon with hyperthreading turned on really isn't the
same as having a quad cpu system.   I haven't seen postgresql specific
benchmarks, but the general case has been that HT is a benefit in a few
particular work loads but with no benefit in general.

- We're running postgresql 8 (in production!) on a dual Opteron 250,
Linux 2.6, 8GB memory, 1.7TB of attached fiber channel disk, etc.   This
machine is fast.    A dual 2.8 Ghz Xeon with 512K caches (with or
without HT enabled) simlpy won't be in the same performance league as
this dual Opteron system (assuming identical disk systems, etc).  We run
a Linux 2.6 kernel because it scales under load so much better than the
2.4 kernels.

The units we're using (and we have a lot of them) are SunFire v20z.  You
can get a dualie Opteron 250 for $7K with 4GB memory from Sun.  My
personal experience with this setup in a mission critical config is to
not depend on 4 hour spare parts, but to spend the money and install the
spare in the rack.   Naturally, one can go cheaper with slower cpus,
different vendors, etc.


I don't care to go into the whole debate of Xeon v. Opteron here.   We
also have a lot of dual Xeon systems. In every comparison I've done with
our codes, the dual Opteron clearly outperforms the dual Xeon, when
running on one and both cpus.


-- Alan



Josh Berkus wrote:

>Bill,
>
>
>
>>I'd be thrilled to test it too, if for no other reason that to determine
>>whether what I'm experiencing really is the "CS problem".
>>
>>
>
>Hmmm ... Gavin's patch is built against 8.0, and any version of the patch
>would require linux 2.6, probably 2.6.7 minimum.   Can you test on that linux
>version?   Do you have the resources to back-port Gavin's patch?
>
>
>
>>Fair enough. I never see nearly this much context switching on my dual
>>Xeon boxes running dozens (sometimes hundreds) of concurrent apache
>>processes, but I'll concede this could just be due to the more parallel
>>nature of a bunch of independent apache workers.
>>
>>
>
>Certainly could be.  Heavy CSes only happen when you have a number of
>long-running processes with contention for RAM in my experience.  If Apache
>is dispatching thing quickly enough, they'd never arise.
>
>
>
>>Hence my desire for recommendations on alternate architectures ;-)
>>
>>
>
>Well, you could certainly stay on Xeon if there's better support availability.
>Just get off Dell *650's.
>
>
>
>>Being a 24x7x365 shop, and these servers being mission critical, I
>>require vendors that can offer 24x7 4-hour part replacement, like Dell
>>or IBM. I haven't seen 4-way 64-bit boxes meeting that requirement for
>>less than $20,000, and that's for a very minimally configured box. A
>>suitably configured pair will likely end up costing $50,000 or more. I
>>would like to avoid an unexpected expense of that size, unless there's
>>no other good alternative. That said, I'm all ears for a cheaper
>>alternative that meets my support and performance requirements.
>>
>>
>
>No, you're going to pay through the nose for that support level.   It's how
>things work.
>
>
>
>>tps = 369.717832 (including connections establishing)
>>tps = 370.852058 (excluding connections establishing)
>>
>>
>
>Doesn't seem too bad to me.   Have anything to compare it to?
>
>What's in your postgresql.conf?
>
>--Josh
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faqs/FAQ.html
>
>