On a dual xeon with HTT enabled:
I tried increasing the NUM_SPINS to 1000 and it works better.
NUM_SPINLOCKS CS ID pgbench
100 250K 59% 230 TPS
1000 125K 55% 228 TPS
This is certainly heading in the right direction ? Although it looks
like it is highly dependent on the system you are running on.
On Wed, 2004-04-21 at 22:53, Josh Berkus wrote:
> > As far as I can tell, this does reduce the rate of semop's
> > significantly, but it does so by bringing the overall processing rate
> > to a crawl :-(. I see 97% CPU idle time when using this patch.
> > I believe what is happening is that the select() delay in s_lock.c is
> > being hit frequently because the spin loop isn't allowed to run long
> > enough to let the other processor get out of the spinlock.
> Also, I tested it on production data, and it reduces the CSes by about 40%.
> An improvement, but not a magic bullet.
519 939 0336
ICQ # 14675561
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2004-04-22 04:15:13|
|Subject: Re: 225 times slower |
|Previous:||From: Tom Lane||Date: 2004-04-22 03:10:43|
|Subject: Re: Wierd context-switching issue on Xeon |