Обсуждение: About “context-switching issue on Xeon” test case ？

RD黄永卫 wrote:
>
> Anybody have the test case of “ context-switching issue on Xeon” from
> Tm lane ？
>

That takes me back:
http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php

That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
7.4. I doubt it has much relevance nowadays, given a) that whole area of
the code was rewritten for PostgreSQL 8.1, and b) today's Xeons are
nothing like 2004's Xeons.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us

2010/4/9 Greg Smith <greg@2ndquadrant.com>:
> RD黄永卫 wrote:
>>
>> Anybody have the test case of “ context-switching issue on Xeon” from
>> Tm lane ？
>>
>
> That takes me back:
> http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
>
> That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
> 7.4. I doubt it has much relevance nowadays, given a) that whole area of
> the code was rewritten for PostgreSQL 8.1, and b) today's Xeons are
> nothing like 2004's Xeons.

It's important to appreciate that all improvements in scalability for
xeons, opterons, and everything else has mostly just moved further
along to the right on the graph where you start doing more context
switching than work, and the performance falls off.  The same way that
(sometimes) throwing more cores at a problem can help.  For most
office sized pgsql servers there's still a real possibility of having
a machine getting slammed and one of the indicators of that is that
context switches per second will start to jump up and the machine gets
sluggish.

For 2 sockets Intel rules the roost.  I'd imagine AMD's much faster
bus architecture for >2 sockets would make them the winner, but I
haven't had a system like that to test, either Intel or AMD.

2010/4/9 Greg Smith <greg@2ndquadrant.com>:
> RD黄永卫 wrote:
>>
>> Anybody have the test case of “ context-switching issue on Xeon” from
>> Tm lane ？
>>
>
> That takes me back:
> http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
>
> That's a problem seen on 2004 era Xeon processors, and with PostgreSQL
> 7.4. I doubt it has much relevance nowadays, given a) that whole area of
> the code was rewritten for PostgreSQL 8.1, and b) today's Xeons are
> nothing like 2004's Xeons.

Note that I found this comment by some guy named Greg from almost a
year ago that I thought was relevant.  (I'd recommend reading the
whole thread.)

http://archives.postgresql.org/pgsql-performance/2009-06/msg00097.php

Scott Marlowe wrote:
> For 2 sockets Intel rules the roost.  I'd imagine AMD's much faster
> bus architecture for >2 sockets would make them the winner, but I
> haven't had a system like that to test, either Intel or AMD.
>

AMD has been getting such poor performance due to the RAM they've been
using (DDR2-800) that it really doesn't matter--Intel has been thrashing
them across the board continuously since the "Nehalem" processors became
available, which started in volume in 2009. Intel systems with 3
channels of DDR3-1066 or faster outperform any scale of AMD deployment
on DDR2, and nowadays even Intel's chapter desktop processors have 2
channels of DDR3-1600 in them.

That's been the situation for almost 18 months now anyway. AMD's new
"Magny-Cours" Opterons have finally adopted DDR3-1333, and closed the
main performance gap with Intel again. Recently I've found the "Oracle
Calling Circle" benchmarking numbers that Anand runs seem to match what
I see in terms CPU-bound PostgreSQL database workloads, and the latest
set at
http://it.anandtech.com/show/2978/amd-s-12-core-magny-cours-opteron-6174-vs-intel-s-6-core-xeon/8
show how the market now fits together. AMD had a clear lead when it was
Xeon E5450 vs. Opteron 2389, Intel pulled way ahead with the X5570 and
later processors. Only this month did the Opteron 6174 finally become
competitive again. They're back to being only a little slower at two
sockets, instead of not even close. A 4 socket version of the latest
Opterons with DDR3 might even unseat Intel on some workloads, it's at
least possible again.

Anyway, returning to "context switching on Xeon", there were some
specific issues with the older PostgreSQL code that conflicted badly
with the Xeons of the time, and the test case Tom put together was good
at inflicting the issue. There certainly are still potential ways to
have the current processors and database code run into context switching
issues. I wouldn't expect that particular test case would be the best
way to go looking for them though, which is the reason I highlighted its
age and general obsolescence.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us

2010/4/10 Greg Smith <greg@2ndquadrant.com>:
> Scott Marlowe wrote:
>> For 2 sockets Intel rules the roost.  I'd imagine AMD's much faster
>> bus architecture for >2 sockets would make them the winner, but I
>> haven't had a system like that to test, either Intel or AMD.
>>
>
> AMD has been getting such poor performance due to the RAM they've been
> using (DDR2-800) that it really doesn't matter--Intel has been thrashing
> them across the board continuously since the "Nehalem" processors became
> available, which started in volume in 2009.

Considering the nehalems are only available (or were at least) in two
socket varieties, and that opterons have two channels per socket
wouldn't the aggregate performance of 8 sockets x 2 channels each beat
the 2 sockets / 3 channels each?