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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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