Re: slow IMAP connection
Bob Atkins <[email protected]>
| Newsgroups | gmane.mail.imap.uw.c-client |
|---|---|
| Organization | DigiLink, Inc. |
| Message-ID | <[email protected]> |
The only way to fix the slow I/O problem, especially with large mail boxes is to convert to mix format. mbx format is only marginally better than mbox from a performance standpoint. This is from my personal experience of having mail boxes with 40,000+ messages and >2GB in size. Today's users have no idea how much space their mail is consuming, nor would they care if they did. Our only option as administrators is to implement the fastest and most scalable solution that we can. We converted our systems to mix format about a year ago and oh what a different it made. Much happier users and even happier admins ;-) --- Bob Mabry Tyson wrote: > Mark may correct me, but here's how I understand what we've > experienced. It may bear some resemblance to your situation. > > You will also see the Connection Reset messages if your users are > using multiple mail clients (for instance, iPhone, home machine, work > machine) simultaneously and they have mbox formatted mailboxes. > Especially if their inboxes are large, users will notice delays. > > In such a case, the imap server is trying to rewrite the inbox (in > response to, say, reads of new messages). It has a lock for the > duration of the writing (so the larger the file, the longer the time > to rewrite). Other mail clients for the same user will eventually lose > their lock and then opportunistically grab the lock later, which means > the mail client currently in use by the user will have to wait for the > lock (resulting in reports of slow access). > > The high I/O wait time is consistent with writing large mbox files > repeatedly. > > If that's your situation, changing the mailbox format is the easiest > way to improve the situation. We moved users to mbx format. It also > helps to educate your users to avoid multiple simultaneous clients and > to keep the size of their mailboxes down. It helps to have the mail > files on the IMAP server (rather than mounted remotely, which only > makes the I/O wait time worse). > > > > On 3/15/10 3:48 PM, Mark Crispin wrote: >> On Mon, 15 Mar 2010, Troy Campbell wrote: >>> I recently installed the 2007e of UW IMAP and seeing high I/O wait on >>> the server. >> >> What, specifically, do you mean by "high I/O wait"? >> >>> I have about 50 users. >> >> That is a very small facility that even modest server hardware should >> handle with aplomb. >> >>> Mar 15 14:42:47 request1 imapd[1445]: Connection reset by peer, >>> while reading line user=xxxxx host=f.q.d.n[11.22.33.44] >> >> This message simply means that a client disconnected from the server >> without first issuing a proper LOGOUT command, and that this was >> detected >> while the server was reading a new IMAP command line. >> >> The only time this message is at all interesting is if a user complains >> about being disconnected from the server. This message is evidence that, >> from the server's viewpoint, the client disconnected. This means that >> you >> can dismiss the server as a possible cause of the problem, and look >> elsewhere. When both client and server point fingers at each other, a >> common cause is an intermediate router (especially a NAT). >> >>> Mar 15 14:42:49 request1 imapd[3250]: imap service init from >>> 192.123.45.77 >>> Mar 15 14:42:49 request1 imapd[3250]: Login user=nnnn host=x.y.z >>> [192.31.97.142] >>> Mar 15 14:42:52 request1 imapd[30847]: Logout user=zzzz host=c.d.e >>> [1.2.3.4] >> >> None of these messages are remarkable. They are all indications of >> normal >> operation. >> >> Your /etc/xinetd.d/imap file looks OK as well >> >>> My initial build was like this: >>> make lr5 SSLTYPE=none >> >> Why are you using SSLTYPE=none? I hope that this is strictly for >> in-house >> use, and not exported over the Internet; as it will result in >> confidential >> traffic (including passwords) being sent in the clear. >> >> -- Mark -- >> >> http://panda.com/mrc >> Democracy is two wolves and a sheep deciding what to eat for lunch. >> Liberty is a well-armed sheep contesting the vote. >> _______________________________________________ >> Imap-uw mailing list >> [email protected] >> http://mailman2.u.washington.edu/mailman/listinfo/imap-uw > > _______________________________________________ > Imap-uw mailing list > [email protected] > http://mailman2.u.washington.edu/mailman/listinfo/imap-uw > _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw