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- ---- 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