high Traffic setup problem, module status don't deliver data

[Valentin V. Bartenev]

On Tuesday 11 February 2014 20:29:25 Maxim Dounin wrote:
> Hello!
> 
> On Tue, Feb 11, 2014 at 07:28:43PM +0400, Valentin V. Bartenev wrote:
> 
> > On Tuesday 11 February 2014 19:06:37 Maxim Dounin wrote:
> > > Hello!
> > > 
> > > On Tue, Feb 11, 2014 at 06:16:48PM +0400, Valentin V. Bartenev wrote:
> > > 
> > > > On Tuesday 11 February 2014 18:06:38 Maxim Dounin wrote:
> > > > [..]
> > > > > > >(As for backlog size, I usually set it to something big enough to
> > > > > > >accomodate about 1 or 2 seconds of expected peek connection rate.
> > > > > > >That is, 1024 is good enough for about 500 connections per second.
> > > > > > >But with deferred on Linux, it looks like deferred connection are
> > > > > > >sitting in the same queue as normal ones, and this may drastically
> > > > > > >change things.)
> > > > > > 
> > > > > > OK. That means with deferred I should double or divide the listening value?
> > > > > 
> > > > > With deferred, it looks like all (potential) deferred connection 
> > > > > should be added to the value.  And it's very hard to tell how many 
> > > > > there will be.
> > > > > 
> > > > 
> > > > Deferred connections stay in syn backlog which controlled
> > > > by tcp_max_syn_backlog.
> > > 
> > > You mean they aren't counted to listen socket's backlog, right?  
> > 
> > Yes.
> > 
> > > Is there any way to see how many such connections are queued then?
> > 
> > They all stay in SYN_RECV state.  If I understand right, something
> > like this will show:
> > 
> >  # netstat -n | grep SYN_RECV | grep :80 | wc -l
> 
> How these connections are different from ones in real SYN_RECV 
> state then?  I.e., how one is expected to distinguish them from 
> connections not yet passed 3-way handhake?
> 

AFAIK, there is no way to distinguish them.

  wbr, Valentin V. Bartenev