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
