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

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 (view raw, whole thread or download thread mbox)
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?

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


pgsql-performance by date

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

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