The silly qmail syndrome with EXTERNAL TODO

Hi:



I am experiencing the silly qmail syndrome with a qmail-ldap-1.03 and it is
really disturbing, since the EXTERNAL TODO patch is obviously applied. What
I observe is as follows:



During a high peak, our qmail system can receive 3000-6000 mails from a
user. The system can handle the delivery to 255 remote connections without
any problem (thoroughly increasing the CPU load). But in the meanwhile, the
todo queue begins to fill. This is exactly the expected behavior: qmail-todo
takes control about the new arrivals while qmail-send perform the deliveries
through qmail-rspawn (there is no local delivery in our system).

After the peak, with no remote or local connections,(/var/log/qmail/current:
…status: local 0/30 remote 2/300)  the todo queue remains stable or growing
for rather more than 1500 seconds (the qmail-send.c and qmail-todo.c
SLEEP_TODO parameter). Whilst most of the new messages go through in a
matter of seconds, some of them fall down at the todo queue. In less than
half an hour,- with just the usual traffic,- we go from



qmail-qstat

messages in queue: 1361

messages in queue but not yet preprocessed: 1310



to



qmail-qstat

messages in queue: 2978

messages in queue but not yet preprocessed: 2919



like if at least one of every five messages got stuck in the todo queue.



After some hours, usually matching the low traffic time, the todo queue
starts to decrease and finally it get to a normal status.

I know this is the description of the silly qmail syndrome, but the external
todo is applied.

I have verified the patched source code, there is a qmail-todo process and
all the other external signs of the EXTERNAL_TODO.

Te compiler options are as follows:

LDAPFLAGS=-DEXTERNAL_TODO -DQUOTATRASH -DBIGTODO



I have dived into several mailing lists and googled all the words, cases and
situations I could imagine. It looks like this kind of problem died with the
EXTERNAL TODO patch, but not in my case.



I would thank any help.



Regards:



Javier