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

Re: Wierd context-switching issue on Xeon patch for 7.4.1

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Paul Tuckfield <paul(at)tuckfield(dot)com>, Anjan Dave <adave(at)vantage(dot)com>,Neil Conway <neilc(at)samurai(dot)com>,Dirk Lutzeb├Ąck <lutzeb(at)aeccom(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1
Date: 2004-04-22 03:18:47
Message-ID: 1082603927.1558.279.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
More data....

On a dual xeon with HTT enabled:

I tried increasing the NUM_SPINS to 1000 and it works better.


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:
> Tom,
> > 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.
Dave Cramer
519 939 0336
ICQ # 14675561

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2004-04-22 04:15:13
Subject: Re: 225 times slower
Previous:From: Tom LaneDate: 2004-04-22 03:10:43
Subject: Re: Wierd context-switching issue on Xeon

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