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
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
