From nobody Fri Jun 27 02:17:18 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bSzhy455kz606dc for ; Fri, 27 Jun 2025 02:17:22 +0000 (UTC) (envelope-from ben@benhutton.com.au) Received: from mail.myuniquemail.com (mail.myuniquemail.com [115.70.107.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bSzhx4tHWz3HB2 for ; Fri, 27 Jun 2025 02:17:21 +0000 (UTC) (envelope-from ben@benhutton.com.au) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ben@benhutton.com.au designates 115.70.107.139 as permitted sender) smtp.mailfrom=ben@benhutton.com.au; dmarc=pass (policy=reject) header.from=benhutton.com.au Received: from [10.128.2.107] (unknown [10.128.10.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail.myuniquemail.com (Postfix) with ESMTPSA id D80D81CC614 for ; Fri, 27 Jun 2025 10:17:18 +0800 (AWST) Content-Type: multipart/alternative; boundary="------------D0LyLSPxwh5Dk0Azmz1vag8f" Message-ID: <8255b0b9-c9df-4af9-bbb2-94140edf189c@benhutton.com.au> Date: Fri, 27 Jun 2025 10:17:18 +0800 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: freebsd-net@freebsd.org From: Ben Hutton Subject: Network Tuning - mbuf X-Spamd-Result: default: False [0.20 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DMARC_POLICY_ALLOW(-0.50)[benhutton.com.au,reject]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:10143, ipnet:115.70.104.0/21, country:AU]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEFALL_USER(0.00)[ben]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4bSzhx4tHWz3HB2 X-Spamd-Bar: / This is a multi-part message in MIME format. --------------D0LyLSPxwh5Dk0Azmz1vag8f Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm currently having an issue with a spring-boot application (with nginx  in front on the same instance) running on FreeBSD 14.1 in AWS. Two of our instances at present have had the application go offline with the following appearing in the /var/log/messages: Jun 26 07:57:47 freebsd kernel: [zone: mbuf_jumbo_page] kern.ipc.nmbjumbop limit reached Jun 26 07:57:47 freebsd kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Jun 26 07:59:34 freebsd kernel: sonewconn: pcb 0xfffff8021bd74000 (0.0.0.0:443 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (104 occurrences), euid 0, rgid 0, jail 0 Jun 26 08:01:51 freebsd kernel: sonewconn: pcb 0xfffff8021bd74000 (0.0.0.0:443 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (13 occurrences), euid 0, rgid 0, jail 0 Each time this has occurred I have increased the nmbjumbop and nmbclusters values. The last time by a huge amount to see if we can mitigate the issue. Once I adjust the values the application starts responding to requests again. My question is, is just increasing this the correct course of action or should I be investigating something else, or adjusting other settings accordingly? Also if this is due to an underlying issue and not just network load how would I get to the root cause? Note the application streams allot of files in rapid succession which I'm suspecting is what is causing the issue. Thanks Ben --------------D0LyLSPxwh5Dk0Azmz1vag8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi,

I'm currently having an issue with a spring-boot application (with nginx  in front on the same instance) running on FreeBSD 14.1 in AWS. Two of our instances at present have had the application go offline with the following appearing in the /var/log/messages:

Jun 26 07:57:47 freebsd kernel: [zone: mbuf_jumbo_page] kern.ipc.nmbjumbop limit reached
Jun 26 07:57:47 freebsd kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
Jun 26 07:59:34 freebsd kernel: sonewconn: pcb 0xfffff8021bd74000 (0.0.0.0:443 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (104 occurrences), euid 0, rgid 0, jail 0
Jun 26 08:01:51 freebsd kernel: sonewconn: pcb 0xfffff8021bd74000 (0.0.0.0:443 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (13 occurrences), euid 0, rgid 0, jail 0

Each time this has occurred I have increased the nmbjumbop and nmbclusters values. The last time by a huge amount to see if we can mitigate the issue. Once I adjust the values the application starts responding to requests again.

My question is, is just increasing this the correct course of action or should I be investigating something else, or adjusting other settings accordingly? Also if this is due to an underlying issue and not just network load how would I get to the root cause? Note the application streams allot of files in rapid succession which I'm suspecting is what is causing the issue.

Thanks
Ben


--------------D0LyLSPxwh5Dk0Azmz1vag8f--