From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754560Ab3AVWBO (ORCPT ); Tue, 22 Jan 2013 17:01:14 -0500 Received: from g6t0185.atlanta.hp.com ([15.193.32.62]:15093 "EHLO g6t0185.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016Ab3AVWBL (ORCPT ); Tue, 22 Jan 2013 17:01:11 -0500 Message-ID: <50FF0C25.9000300@hp.com> Date: Tue, 22 Jan 2013 14:01:09 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Leandro Lucarella CC: Eric Dumazet , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Doubts about listen backlog and tcp_max_syn_backlog References: <20130122161038.GG4608@sociomantic.com> <1358873142.3464.3964.camel@edumazet-glaptop> <20130122165929.GH4608@sociomantic.com> <1358874800.3464.4002.camel@edumazet-glaptop> <50FED7CE.1030008@hp.com> <20130122184245.GJ4608@sociomantic.com> In-Reply-To: <20130122184245.GJ4608@sociomantic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/22/2013 10:42 AM, Leandro Lucarella wrote: > On Tue, Jan 22, 2013 at 10:17:50AM -0800, Rick Jones wrote: >>> What is important is the backlog, and I guess you didn't increase it >>> properly. The somaxconn default is quite low (128) >> >> Leandro - >> >> If that is being overflowed, I believe you should be seeing something like: >> >> 14 SYNs to LISTEN sockets dropped >> >> in the output of netstat -s on the system on which the server >> application is running. > > What is that value reporting exactly? Netstat is reporting the ListenDrops and/or ListenOverflows which map to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS. Those get incremented in tcp_v4_syn_recv_sock() (and its v6 version etc) if (sk_acceptq_is_full(sk)) goto exit_overflow; Will increment both overflows and drops, and drops will increment on its own in some additional cases. > Because we are using syncookies, and AFAIK with that enabled, all > SYNs are being replied, and what the listen backlog is really > limitting is the "completely established sockets waiting to be > accepted", according to listen(2). What I don't really know to be > honest, is what a "completely established socket" is, does it mean > that the SYN,ACK was sent, or the ACK was received back? I have always thought it meant that the ACK of the SYN|ACK has been received. SyncookiesSent SyncookiesRecv SyncookiesFailed also appear in /proc/net/netstat and presumably in netstat -s output. > Also, from the client side, when is the connect(2) call done? When the > SYN,ACK is received? That would be my assumption. In a previous message: > What I'm seeing are clients taking either useconds to connect, or 3 > seconds, which suggest SYNs are getting lost, but the network doesn't > seem to be the problem. I'm still investigating this, so unfortunately > I'm not really sure. I recently ran into something like that, which turned-out to be an issue with nf_conntrack and its table filling. rick