On Thu, Jun 28, 2007 at 10:47:43AM +0100, Adrian wrote:
> I figured that the new machine being about 10 times faster
> and with 4 times the RAM and a gigabit NIC instead of 100mb maybe it was just
> showing the problem faster ( maybe flawed logic there! ).
That's flawed logic I'd say. TCP and IP are designed to run over flakey
networks, and a 33.6kbps dial-up modem will happily carry multiple IMAP
sessions, albeit slowly.
Even if your 100Mbps switched network were totally saturated with traffic,
this would manifest itself as slowness or timeouts. What you're observing,
according to your report, is getting "connection was refused". That is,
either the kernel or the application is actively rejecting an inbound
connection. This may take the form of:
TCP SYN -->
TCP RST <--
Use tcpdump or wireshark (on client and/or server) if you wish to confirm or
disprove this at the IP layer (*). Note that your switches will never
generated TCP RST packets; only the end hosts participate in TCP. And hence
if this is happening, it's nothing to do with your network infrastructure,
and throwing money at your LAN won't help.
Use netstat to monitor the concurrent network sockets on the server. It's
also conceivable that you've reached your system-wide file descriptor limit,
which under Linux I think is 'sysctl fs.file-max', although generally that
limit is very high. I'm afraid I don't know how to monitor the actual FD
usage, other than
ls /proc/*/fd
Of course, it's worth checking under exactly what conditions your client
generates the message you're seeing, e.g. by looking at the source code.
Perhaps you're getting occasional authentication failures, but these are
displayed to the client confusingly as "connection was refused". In that
case, you need to look at your authentication daemon setup.
The most unambiguous client to use is:
telnet x.x.x.x 143
a login username password
a logout
If you can capture the problem with that, and copy-paste the full transcript
with the *exact* responses returned by the server, that would most likely be
able to pinpoint the problem.
Regards,
Brian.
(*)
tcpdump -i eth0 -n -s0 -w imap.pcap tcp port 143 or icmp
will record all the relevant packets into a file, which you can later
analyse using
tcpdump -r imap.pcap -nX | less
Make sure the clock is accurate on your systems, e.g. using ntp. Then if
someone reports they saw this problem at a particular time, then you can
look into the problem.
As long as the IMAP connection is not encrypted using SSL, this file will
also show all the commands sent to and responses from the server. Hence if
the server itself is sending an IMAP response for authentication failure,
say, then this will be recorded too. Beware that your users' passwords will
be captured in this file though.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
