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
Re: stuck spin lock with many concurrent users |
Список | 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 по дате отправления: