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

Re: stuck spin lock with many concurrent users

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
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:38:36
Message-ID: 26511.994203516@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:

> 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 ?

Yes, it sure is, but remember that the guy getting useful work done
(DeadLockCheck) is having to share the CPU with 999 other processes
that are waking up on every clock tick for just long enough to fail
to get the spinlock.  I think it's those useless process wakeups that
are causing the problem.

If you estimate that a process dispatch cycle is ~ 10 microseconds,
then waking 999 useless processes every 10 msec is just about enough
to consume 100% of the CPU doing nothing useful... so what should be
a few-millisecond check takes a long time, which makes things worse
because the 999 wannabees are spinning for that much more time.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-04 00:58:42
Subject: Re: UNDO and partially commited transactions
Previous:From: Hiroshi InoueDate: 2001-07-03 23:30:16
Subject: Re: stuck spin lock with many concurrent users

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