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

[Aleksandar Lazic]

Am 11-02-2014 18:56, schrieb Valentin V. Bartenev:
> On Tuesday 11 February 2014 16:44:57 Aleksandar Lazic wrote:
>> 
>> Am 11-02-2014 16:28, schrieb Valentin V. Bartenev:
>> > 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
>> 
>> We have a average from ~200 here.
>> 
>> Is this good/bad/not worth ?
>> 
> 
> Not a problem at all, till it's noticeable lower than 
> tcp_max_syn_backlog.

Ok thanks