On Thu, Sep 08, 2005 at 09:20:16PM +0200, oneman wrote: > > I've got a problem with cyrus getting slower over time when checking > mail, up to a point where clients start timing out... First cyrus > works flawlessly, then it starts responding slower to mailchecking > and eventually becomes unusable. After some hours of non use, the > problem disappears by itself, so it seems something simply times out > after a while, I just can't see what that might be. > (...) > I've been looking at top and tailing mail.log but can't find anything > else but cyrus processes starting, sitting idle for a very long time > and exiting > > I don't know where to look next to find out where the problem lies.
You could attach strace or ltrace to one or several of the cyrus processes, to find out what system calls they're making (ltrace would also trace shared library calls in addition to system calls -- in case the strace info doesn't seem fine-grained enough). This way, you might find out, _just as an example_, that the process is spending lots of time waiting on a socket that isn't ready for reading/writing, or something. In that case you'd most likely see select(2) calls on a socket handle in the strace output. You would then lookup what socket that handle corresponds to, et voila, with a bit of luck you'd be one step closer to where the problem is originating... Just do a "strace -p <PID-of-process-to-trace>", possibly adding other useful options like -o, -f, -e (see the manpage for details). And, if you should need help interpreting the output you get, don't hesitate to report back here. Of course, this approach isn't guaranteed to get you anywhere, but in the absence of any better ideas, it's at least worth a try... :) Good luck, Almut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]