I put up two reports (load, iostat, queue, ps ax) at http://195.70.33.28/~algernon/exim-stuff/
The first one was made shortly before enabling maildir_use_size_file, the second one was made 1.5 minutes after, using the same command line. There are quite a few exims stuck in D, indeed, as expected. The question remains, though - why? Why is it taking that long to process a maildir, when my quickly hacked up perl script finished even the largest directory within 10 seconds (and most others in one). Delivery times raised from <1 sec to >1 minute during the test, due to the exims getting stuck in D. Anyway, time for more testing. Gonna try isolate the maildir(s) that cause the problem. However, there's one idea I was thinking of: whether it is possible to give a transport a timeout, so if it does not finish within N seconds, it aborts, logs an error, and will get retried later on? That'd make debugging a lot easier for me. -- Gergely Nagy <[EMAIL PROTECTED]> -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
