Re: Wierd context-switching issue on Xeon

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Dirk_Lutzebäck <lutzeb(at)aeccom(dot)com>
Cc: ohp(at)pyrenet(dot)fr, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <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>, pgsql-performance(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: Wierd context-switching issue on Xeon
Date: 2004-04-21 15:05:31
Message-ID: 1082559931.1557.235.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

After some testing if you use the current head code for s_lock.c which
has some mods in it to alleviate this situation, and change
SPINS_PER_DELAY to 10 you can drastically reduce the cs with tom's test.
I am seeing a slight degradation in throughput using pgbench -c 10 -t
1000 but it might be liveable, considering the alternative is unbearable
in some situations.

Can anyone else replicate my results?

Dave
On Wed, 2004-04-21 at 08:10, Dirk_Lutzebäck wrote:
> It is intended to run indefinately.
>
> Dirk
>
> ohp(at)pyrenet(dot)fr wrote:
>
> >How long is this test supposed to run?
> >
> >I've launched just 1 for testing, the plan seems horrible; the test is cpu
> >bound and hasn't finished yet after 17:02 min of CPU time, dual XEON 2.6G
> >Unixware 713
> >
> >The machine is a Fujitsu-Siemens TX 200 server
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
>
>
> !DSPAM:40866735106778584283649!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Chris Hoover 2004-04-21 15:34:16 Help understanding stat tables
Previous Message Stephan Szabo 2004-04-21 14:31:27 Re: slow seqscan