From: "Lewis G Rosenthal" Received: from [50.73.8.217] (account lgrosenthal@2rosenthals.com HELO [192.168.200.28]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 13711841 for ecs-isp@2rosenthals.com; Tue, 29 Jul 2025 09:21:01 -0400 Subject: Re: [eCS-ISP] socket - no buffer space availble To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <6888CABC.80809@2rosenthals.com> Date: Tue, 29 Jul 2025 09:21:00 -0400 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Good morning from the East Coast... On 07/29/25 02:43 am, Steven Levine wrote: > In , on 07/29/25 > at 10:15 AM, "Peter Moylan" said: > > Hi all, > >> Just because Apache was the one to report the problem, that doesn't mean >> that Apache caused the socket starvation. You have to use Lewis's >> approach of closing one application at a time, to see which "close" >> fixed the problem. > Agreed. > > Another useful took for tracking down the source of this kind of issue is > > netstat -s > > There's often enough information in the port numbers to track down the > offending application. > This got me thinking that if there seem to be multiple apps holding connections open, it might be good to look at lingertime (which will affect blocking sockets only; non-blocking sockets may remain open for an indefinite period). Another option - again, if you find that this problem is systemic on that system, and may not be consistently application-specific - is realslow, which may help with stubborn connections which remain stuck in TIME_WAIT. Good reference for implications of changing things system-wide: https://www.rfc-editor.org/rfc/rfc1337 But again, try to narrow it down to a specific application, first. Only after you have eliminated that should you look at making global changes, and when you do, the rule of thumb is "smaller is better," meaning, the smaller the change you make, the less harm you are likely to do. It's also a good reminder that the venerable OS/2 IPv4 stack was tuned for connections of the day (100Mbps LANs were not all that common, let alone the broadband widths we see today). Many default settings - particularly for servers - will be inadequate to today's environments. At Arca Noae, we have looked at better optimizing the defaults, but it's a very hard thing to do, so applying the above principle of "smaller is better," we have changed very little. Good luck with this, Max. Looking forward to hearing how you solve the problem. And thanks to Steve and Peter for bolstering my recommended approach. It's always good to get concurrence from colleagues. (It also helps confirm that my wife didn't slip something funny in my morning coffee, just for fun.) -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------