Date: Thu, 24 Nov 2011 11:53:24 -0600 From: Kris Bauer <kristoph.bauer@gmail.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: TCP Reassembly Issues Message-ID: <CAPNZ-Wo3q7BiMRspQAibQTcSwQYNcfj-_e8XUBguQ8Hc%2ByrN5w@mail.gmail.com> In-Reply-To: <jalrkt$41n$1@dough.gmane.org> References: <CAPNZ-Wq38=F3o2hYuYF_unBj3SZQ52XhVhdcwQ8PE_vU9xc2YA@mail.gmail.com> <jalrkt$41n$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 24, 2011 at 10:33 AM, Ivan Voras <ivoras@freebsd.org> wrote: > On 24.11.2011. 8:02, Kris Bauer wrote: > >> Hello, >> >> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 where >> the >> net.inet.tcp.reass.curesegments value is constantly increasing (and not >> descreasing when there is nominal traffic with the box). It is causing >> tcp >> slowdowns as described with kern/155407: >> >> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session (for >> this socket and any other socket waiting for retransmited packets). After >> exhausted net.inet.tcp.reass.maxsegments allocation new entry in tcp_reass >> failed (for this socket and any other socket waiting for retransmited >> packets). >> >> I have increased the reass.maxsegments value to 16384 to temporarily avoid >> the problem, but the cursegments number keeps rising and it seems it will >> occur again. >> >> Is this an issue that anyone else has seen? I can provide more >> information >> if need be. >> > > Is your configuration different than the default in some way? Do you use a > firewall? Multithreaded netisr? One of the new TCP congestion control > modules? > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I don't believe that my configuration is anything out of the usual. Just some standard LFN tuning. sysctl.conf net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 kern.geom.eli.threads=2 kern.ipc.maxsockbuf=16777216 net.inet.tcp.cc.algorithm=htcp net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_inc=262144 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 net.inet.tcp.hostcache.expire=1 net.inet.tcp.delayed_ack=0 boot/loader.conf vm.kmem_size_max="5120M" vm.kmem_size="5120M" geom_mirror_load="YES" vfs.zfs.arc_max="4096M" vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout="15" vfs.zfs.write_limit_override="268435456" kern.ipc.nmbclusters="65536" cc_htcp_load="YES" net.inet.tcp.reass.maxsegments=16384 With the exception of the CC H-TCP and Reass maxsegments tunables, this is exactly what I was use with 8.2 with no issues. I have also seen the issue crop up (although I hadn't yet identified the source) while booting the box entirely with defaults (including using NewReno). The box is a 2 x Xeon E5405 Supermicro X7DCX with 8gb of RAM. Thanks, Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPNZ-Wo3q7BiMRspQAibQTcSwQYNcfj-_e8XUBguQ8Hc%2ByrN5w>