Skip site navigation (1) Skip section navigation (2)

Re: Wierd context-switching issue on Xeon

From: Robert Creager <Robert_Creager(at)LogicalChaos(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Joe Conway <mail(at)joeconway(dot)com>,"scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, lutzeb(at)aeccom(dot)com,pgsql-performance(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: Wierd context-switching issue on Xeon
Date: 2004-04-20 03:47:02
Message-ID: 20040419214702.70e5c9b6@thunder.mshome.net (view raw or flat)
Thread:
Lists: pgsql-performance
When grilled further on (Mon, 19 Apr 2004 20:53:09 -0400),
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> confessed:

> I wrote:
> > Here is a test case.
> 
> Hmmm ... I've been able to reproduce the CS storm on a dual Athlon,
> which seems to pretty much let the Xeon per se off the hook.  Anybody
> got a multiple Opteron to try?  Totally non-Intel CPUs?
> 
> It would be interesting to see results with non-Linux kernels, too.
> 

Same problem on my dual AMD MP with 2.6.5 kernel using two sessions of your
test, but maybe not quite as severe. The highest CS values I saw was 102k, with
some non-db number crunching going on in parallel with the test.  'Average'
about 80k with two instances.  Using the anticipatory scheduler.

A single instance pulls in around 200-300 CS, and no tests running around
200-300 CS (i.e. no CS difference).

A snipet:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 3  0    284  90624  93452 1453740    0    0     0     0 1075 76548 83 17  0  0
 6  0    284 125312  93452 1470196    0    0     0     0 1073 87702 78 22  0  0
 3  0    284 178392  93460 1420208    0    0    76   298 1083 67721 77 24  0  0
 4  0    284 177120  93460 1421500    0    0  1104     0 1054 89593 80 21  0  0
 5  0    284 173504  93460 1425172    0    0  3584     0 1110 65536 81 19  0  0
 4  0    284 169984  93460 1428708    0    0  3456     0 1098 66937 81 20  0  0
 6  0    284 170944  93460 1428708    0    0     8     0 1045 66065 81 19  0  0
 6  0    284 167288  93460 1428776    0    0     0     8 1097 75560 81 19  0  0
 6  0    284 136296  93460 1458356    0    0     0     0 1036 80808 75 26  0  0
 5  0    284 132864  93460 1461688    0    0     0     0 1007 76071 84 17  0  0
 4  0    284 132880  93460 1461688    0    0     0     0 1079 86903 82 18  0  0
 5  0    284 132880  93460 1461688    0    0     0     0 1078 79885 83 17  0  0
 6  0    284 132648  93460 1461688    0    0     0   760 1228 66564 86 14  0  0
 6  0    284 132648  93460 1461688    0    0     0     0 1047 69741 86 15  0  0
 6  0    284 132672  93460 1461688    0    0     0     0 1057 79052 84 16  0  0
 5  0    284 132672  93460 1461688    0    0     0     0 1054 81109 82 18  0  0
 5  0    284 132736  93460 1461688    0    0     0     0 1043 91725 80 20  0  0


Cheers,
Rob

-- 
 21:33:03 up 3 days,  1:10,  3 users,  load average: 5.05, 4.67, 4.22
Linux 2.6.5-01 #5 SMP Tue Apr 6 21:32:39 MDT 2004

In response to

pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2004-04-20 04:02:24
Subject: Re: Why will vacuum not end?
Previous:From: Shea,Dan [CIS]Date: 2004-04-20 03:37:47
Subject: Why will vacuum not end?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group