Date: Tue, 30 Mar 2021 20:06:08 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 254333] [tcp] sysctl net.inet.tcp.hostcache.list hangs Message-ID: <bug-254333-7501-U5r1NLYDFF@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254333-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-254333-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254333 --- Comment #17 from Richard Scheffenegger <rscheff@freebsd.org> --- net.inet.tcp.hostcache.count: 4294966447 is -849 (decimal). tcp_hc_purge_internal decrements hostcache.count unconditionally, and would= be=20 the most likely candidate where that counter can rapidely go negative (beco= ming a huge uint32). All the adjustments to hch_length, cache_count and actual add/dels from hashbuckets appear to be symmetric. One more hint (more operationally): if you have high "hostcache buffer-overflows" in 'netstat -snp tcp' you my want to tweak the bucket size rather than the hashsize. Unfortunately, the hostcache does not currently provide insight if a wider hashsize, or a deeper bucketlimit would be preferrential for your workload.= .. (you would probably want a histogram of #buckets of length "n". If that histogram shows few deeply used buckets, but most buckets empty or sparsely used, a narrower hashsize with deeper buckets may be more optimal space use. If most buckets are mostly used, a wider hashsize may be preferrably over deeper buckets... --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254333-7501-U5r1NLYDFF>