Why do lmtpd processes accumulate?

[Gary Mills]

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?

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-