LI Xin wrote, On 20.9.2006 17:36:
Taras Savchuk wrote: [snip]
What if you get some output from ktrace/kdump? Additionally, try to force the process to save a coredump and investigate its .core with gdb would help tracking down the issue...
Note that because when using kqueue the process should get a "kqread" if it is waiting for kqueue event. If the process is stuck in "RUN" state then a coredump would be more helpful.
Cheers,
~20000 calls to gettimeofday() per second. Is it normall?
No! What's more, gettimeofday() is much more expensive on FreeBSD than its Linux counterpart, as it provides higher resolution time which is not useful for many applications. True.
My guess is that your imap instance is stuck in a state where either kevent() is called with a zero ts structure (which is effectively a poll) every time, or some other weird thing happend.
Yes, thats exactly what happens. I tried to debug this, once.
But first some introduction. There are two kqueues. One for directory change notification, that is the descriptor 5. And the second is for polling for events on other handles, including the kqueue for directory change notification, descriptor 4. Now, two strange things happen when you see the 100% load. The time to next timer run is always zero or close to zero, and the second is that the descriptor 5 seems to be always signaling some event. I never found out why either of the two things happens.
mail2# cat k.dov.l.txt | grep CALL | grep gettimeofday | wc -l 1195552 mail2# head -n 1 k.dov.l.txt 20910 imap 0.000000 CALL gettimeofday(0x80c2c60,0x80c2c68) mail2# tail -n 1 k.dov.l.txt 20910 imap 51.826065 RET gettimeofday 0
Are these gettimeofday() calls called one by one? Or is there any other calls between gettimeofday's?
Cheers,
-- VH