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
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
