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
