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 по дате отправления: