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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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