Re: How to tune TCP for heavily loaded sendmail box
On Thu, Apr 19, 2001 at 07:49:45AM +0800, Andrew Chan wrote: > Greetings, > > I am running a relaying sendmail box and I would like it to be able to > handle up to 600 or so concurrent (incoming or outgoing) connections. > > I tried that and discovered that TONS of incoming connections are stuck at > SYNC_RECV state. It is like the sendmail box received these port 25 > connection attempts and then didn't know what to do with them. Such sockets don't make it to accept() -- the TCP connection setup is a three-way handshake, and SYN_RECV is just indication of the reception of the first part of it: 1) local <--- SYN -- remote 2) local ACK,SYN -> remote 3) local <--- ACk,ACK -- remote Each of those SYN_RECV sockets have done 2, but have never heard back. In normal case the state 3 is reached by 1.5 times the roundtrip time between the two systems. (Presuming symmetric delays.) There is finite size queue of sockets that can sit in this particular state waiting for full open (3), after which the user programs can then get the sockets with accept(). It may be so called 'SYN-attack', although it might just as well be routing blackhole somewhere. Look for documents regarding SYN-Cookies, and how to enable them. ( I.e. what values mean what at: /proc/sys/net/ipv4/tcp_syncookies ) > I suspect I need to tune some of the TCP parameters so that the system can > handle many short lived TCP connections in an efficent manner. Any pointer > to this specific issue or general TCP tunning under Linux (2.4.2-ac28 > kernel) will be most appreciated. > > Thanks. > > Andrew /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to tune TCP for heavily loaded sendmail box
On Thu, Apr 19, 2001 at 07:49:45AM +0800, Andrew Chan wrote: Greetings, I am running a relaying sendmail box and I would like it to be able to handle up to 600 or so concurrent (incoming or outgoing) connections. I tried that and discovered that TONS of incoming connections are stuck at SYNC_RECV state. It is like the sendmail box received these port 25 connection attempts and then didn't know what to do with them. Such sockets don't make it to accept() -- the TCP connection setup is a three-way handshake, and SYN_RECV is just indication of the reception of the first part of it: 1) local --- SYN -- remote 2) local ACK,SYN - remote 3) local --- ACk,ACK -- remote Each of those SYN_RECV sockets have done 2, but have never heard back. In normal case the state 3 is reached by 1.5 times the roundtrip time between the two systems. (Presuming symmetric delays.) There is finite size queue of sockets that can sit in this particular state waiting for full open (3), after which the user programs can then get the sockets with accept(). It may be so called 'SYN-attack', although it might just as well be routing blackhole somewhere. Look for documents regarding SYN-Cookies, and how to enable them. ( I.e. what values mean what at: /proc/sys/net/ipv4/tcp_syncookies ) I suspect I need to tune some of the TCP parameters so that the system can handle many short lived TCP connections in an efficent manner. Any pointer to this specific issue or general TCP tunning under Linux (2.4.2-ac28 kernel) will be most appreciated. Thanks. Andrew /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
