On Wed, Oct 1, 2008 at 10:28 AM, Sridhar Samudrala <sri@xxxxxxxxxx> wrote:
>
> On Wed, 2008-10-01 at 16:55 +0300, Pekka Savola wrote:
> > On Wed, 1 Oct 2008, Vitaly Ivanov wrote:
> > > We have solved this problem. We had tuned TCP/IP stack in Linux Kernel
> > > but it hadn't helped us because there was very law value backlog in
> > > listen function
> > > int listen(int sockfd, int backlog);
> > > This function is used in nginx and lighttp demons. In nginx this value
> > > had been set to 511 and in lighttp to 1024. We set both value to 65535
> > > or -1 and solve our problem. Now we have about 700Mbit per second
> > > instead 70.
> >
> > Good catch. I wonder if there is any way to figure out the listen
> > backlog (except using strace) for a socket, e.g. using a system level
> > tool?
>
> Yes. The max listen backlog and the current listen backlog values
> for listening sockets are available via Recv-Q and Send-Q fields
> in 'netstat' and 'ss' output as well as tx_queue and rx_queue
> under cat /proc/net/tcp
>
How do you get the max value reached, it seems to only give the
current value, which is very instantaneous.
Also, is this the number of connections waiting to be accepted by the
user program or the number of bytes on an already accepted connection
not copied to the user program ?
according to netstat man page:
Recv-Q
The count of bytes not copied by the user program connected to
this socket.
-- Pranav
> Thanks
> Sridhar
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
