Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Jan 2004 15:33:45 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        silby@silby.com
Cc:        cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c   tcp_subr.ctcp_usrreq.c tcp_var.h
Message-ID:  <3FFEBBC9.A42EDC25@freebsd.org>
References:  <200401081740.i08He8J9063202@repoman.freebsd.org> <3FFEAFC2.8070303@freebsd.org> <36749.158.6.15.27.1073658317.squirrel@webmail.pair.com>

next in thread | previous in thread | raw e-mail | index | archive | help
silby@silby.com wrote:
> 
> > David Xu wrote:
> >>
> >> I got following messages when I am running mysql stress test suite,
> >> and the test can not be completed.
> >>
> >> "too many small tcp packets from 128.0.0.1:20672, av. 91byte/packet,
> >> dropping connection"
> >
> > You can set net.inet.tcp.minmssoverload to a higher value than the
> > default of 1,000.  I suggest trying with 2,000 as next step and see if
> > it still overloads.
> >
> > Appearently my default of 1,000 pps is fine for normal use but too low
> > for some edge cases.
> >
> > Could you check the MySQL source code if it has a setsockopt() setting
> > the TCP_NODELAY option?  That would help to explain a lot.
> >
> > --
> > Andre
> 
> This might nerf the protection a bit, but could reduce the packet counter
> once for each socket write the local machine does?  That should protect
> chatty applications, but still detect those that are just flooding data to
> a bulk service like ftp or smtp.

It doesn't help in this case as we don't have any control over the sender
and thus don't know whether he has set TCP_NODELAY.

I suspect that the database(s) are setting TCP_NODELAY and do a write()
for every record they have retrieved from the query result.  Yet one more
who has been fooled by the name "TCP_NODELAY".  The database would be
better off and have more performance not using nodelay and let Nagle do
its work.

-- 
Andre



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFEBBC9.A42EDC25>