Why do lmtpd processes accumulate?

[Ken Murchison]

Have you done an strace on one of the lmtpd on the backend to see what 
it is doing?


Gary Mills wrote:
> We have a fairly conventional Cyrus server with one front-end and one
> back-end.  Recently, I've noticed that when the number of lmtpd
> processes on the back-end server increases to the 400 range,
> performance drops to a crawl, including local deliveries.  When I put
> an upper limit of 128 or 64 to these processes on the front-end, which
> requires a Cyrus restart, all of the local deliveries succeed in a
> short time.  Performance also comes back to normal.
> 
> I can't tell if it's the restart that fixes the problem or if it's
> the limit on lmtpd children.  I'm wondering, though, if the lmtpd
> processes are all waiting on some Cyrus database, so that more of
> them just makes it worse.  These are the databases, from imapd.conf:
> 
>     annotation_db:          skiplist
>     duplicate_db:           berkeley-nosync
>     mboxkey_db:             skiplist
>     mboxlist_db:            skiplist
>     quota_db:               quotalegacy
>     seenstate_db:           skiplist
>     subscription_db:        flat
>     tlscache_db:            berkeley-nosync
> 
> I believe those are current recommendations.  Which ones might be
> causing the problem?  Is there tuning that can be done on them?
> 

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University