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

Re: stuck spin lock with many concurrent users

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: stuck spin lock with many concurrent users
Date: 2001-07-03 23:30:16
Message-ID: 3B425588.1B21E00A@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > I added some codes into HandleDeadLock to measure how long
> > LockLockTable and DeadLOckCheck calls take. Followings are the result
> > in running pgbench -c 1000 (it failed with stuck spin lock
> > error). "real time" shows how long they actually run (using
> > gettimeofday). "user time" and "system time" are measured by calling
> > getrusage. The time unit is milli second.
> 
> >  LockLockTable: real time
> 
> >  min |  max   |        avg
> > -----+--------+-------------------
> >    0 | 867873 | 152874.9015151515
> 

[snip]

> 
> >  DeadLockCheck: real time
> 
> >  min |  max  |       avg
> > -----+-------+-----------------
> >    0 | 87671 | 3463.6996197719
> 
> >  DeadLockCheck: user time
> 
> >  min | max |      avg
> > -----+-----+---------------
> >    0 | 330 | 14.2205323194
> 
> >  DeadLockCheck: system time
> 
> >  min | max |     avg
> > -----+-----+--------------
> >    0 | 100 | 2.5095057034
> 
> Hm.  It doesn't seem that DeadLockCheck is taking very much of the time.

Isn't the real time big ?
Isn't 14.22msec big enough for the spinlocking process to
pass the time slice to other processes ?

regards,
Hiroshi Inoue

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-07-03 23:38:36
Subject: Re: stuck spin lock with many concurrent users
Previous:From: Nathan MyersDate: 2001-07-03 22:59:34
Subject: Re: Buffer access rules, and a probable bug

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