Timo Sirainen wrote:
I can see a large number of processes named "imap", some users have more than 12 such processes running. Is such a large number per user a "normal" behaviour ?
It's probably normal. Each connection is handled by a separate imap process currently, and many clients can create a lot of connections.
OK, Timo ! Many thanks for your help !
At the present time, I understand better what is happening here, causing problems.
At the present time, the maidirs are mounted via NFS v3 on a NetApp system. The index is on a local RAID file system. mboxes are not used. Incoming messages are inserted in the maildirs using sendmail and maildrop. The usual behavior is OK: the CPU usage and Load Average are moderate. There are many processes sleeping.
When a large number of messages for many different users arrive nearly at the same time (e.g. a message to all the users), a large number of sleeping processes become active, the CPU usage increases to more than 80 or 90 % and the LA can be many hundreds for a long time. The machine is not more really operational from user's point of view. NFS is probably a problem here, but some NFS tests have not allowed to discover problems at this level. Now, I'm trying to find a "solution" in the way to delay the delivery of the messages to the maildirs. I think, it is not really a nice solution.
I think that the large number of now running processes is the rebuilding of the index. I am right here, Timo ? Please note that many users have a large number of messages accumulated in the incoming maildir. Unfortunately, I cannot change that. In the past, this was the reason to migrate to maildirs. At the present time, the mailfilter language of maildrop (and Courier) is used here in place of procmail used in the past. I ignore if using dovecot's LDA could be a solution in this environment. But the mailfilter language could be a problem. A migration to sieve is not really a choice, in my opinion. I have never seen a good sieve script testing software.
Thanks a lot ! Claude