We are not using tcp wrappers. Plain old Solaris inetd.
We have excellent response time throughout normal load. It is only during high load that port 143 lags. I can even telnet localhost 143 and have a delay upward of 50 seconds before getting any kind of imapd banner. If it were network related, I would think localhost would be exempt. Any other ideas?
Sniffing the traffic coming in during a problem state shows the initial SYN reaching the port, but absolutely no response going back. This type of evidence is what's leading me to some kind of kernel related queue that is backloged or dropping new attempts.
=============================
Ken Koch
Information Systems
314.935.8315
=============================
| Mark Sirota <[EMAIL PROTECTED]>
01/09/2006 01:16 PM |
|
--On January 9, 2006 11:02:12 AM -0600 [EMAIL PROTECTED] wrote:
> During high load (about 18 imapd logins/second from a webmail system) we
> start to get long delays when connecting to port 143. Sometimes, even a
> connection refused when attempted from outside localhost. Delays
> possibly range from 20 seconds to 2 minutes. When telneting to port 143
> from localhost, the delays are evident before the IMAP capabilities logo
> splashes. After IMAP's banner is shown, everything seems fine. It's
> before getting the banner that lags.
Are you using tcp wrappers (tcpd) for imap? Might it be configured to do
either ident or reverse DNS lookups? I'm guessing that either a firewall
is dropping the ident queries rather than sending a TCP reset, or
something's funky about the reverse lookup.
The quickest way to test this theory is to eliminate tcp wrappers from
inetd.conf on the imap line, and see if the problem instantly goes away.
The quickest non-disruptive way to test this theory is to sniff the
traffic.
Mark
_______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
