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 <gergely.nagy@???>
