Re: stuck spin lock with many concurrent users

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: stuck spin lock with many concurrent users
Дата
Msg-id 26511.994203516@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: stuck spin lock with many concurrent users  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Ответы Re: stuck spin lock with many concurrent users  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: stuck spin lock with many concurrent users  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: [OT] Any major users of postgresql?
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: stuck spin lock with many concurrent users