Re: stuck spin lock with many concurrent users

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


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: stuck spin lock with many concurrent users
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: UNDO and partially commited transactions