From: Duane Hill (no email)
Date: Tue Feb 27 2007 - 17:27:15 EST
On Wed, 28 Feb 2007, Andrew McNamara wrote:
>>> Are you using an SMP machine and kernel? Maybe try without SMP? Might also
>>> be worth trying with a 32 bit kernel.
>> The server uses SMP as it has four processors. The server would
>> drastically take a performance hit if I were to drop in a non-SMP kernel.
> Yes, I realise this - I suggest it in an effort to narrow the source of the
> problem down.
>> I could try dropping to a 32 bit kernel, however, the other server I have
>> is running a 32 bit kernel and gets a few of these same errors.
> Okay, that suggests it isn't a 32 bit vs 64 bit issue.
> Is the other server SMP also?
>>> I have a vague memory of some old versions of Linux doing something like
>>> this when the socket was closed by the remote end between userspace being
>>> notified that listening socket was ready, and the accept being performed.
>>> If you're feeling keen, you could create a stress test that rapidly opened
>>> and closed sockets (or use a port scanning tool to do the same - nmap?)
>> I'm going to see if I can get a stress on my local computer to see if I
>> can get the error to show.
> Yes - but it may well be something that the big, bad internet is doing
> to your servers (either a deliberate or accidental attack). Being able to
> duplicate it in a controlled environment would be a big step forward.
I will see if I can find out. The server is behind a hardware firewall. I
also have IPFilter loaded on both FreeBSD servers. I will change the
IPFilter rules to pass in and out all traffic to see if that clears the
issue up. If not, recompile the kernel without IPFilter and then proceed
with inquiring our colo facility on the hardware firewall part.