Skip site navigation (1)Skip section navigation (2)
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>