Subject | Re: [ib-support] Unusual server lockup 10061 |
---|---|
Author | Artur Anjos |
Post date | 2001-12-21T22:10:26Z |
(a little long, but...)
Jason, did a net search on this and get:
"An operation on a socket could not be performed because the system lacked
sufficient buffer space or because a queue was full."
It matches your feeling, so I keep on:
"Once a port is closed, it takes 4 minutes (240 seconds) before the system
will reuse it. You can alter this behavior if you Add Value name
TcpTimedWaitDelay as a type REG_DWORD and set it to some decimal number in
the range of 30 - 300 seconds"
I really don't know about this, and it seems very important if you
connect/disconnect a lot.
(Is this your case? Your users connect do the job and disconnect?)
-----
Now a 'small private note': (I do network administration to a few
medium-size networks, and I really like this TCP problems....)
If this is network related, I will also try do replace the network card (try
a cheap one, just for testing) with a chip different from the one you have:
just to be shure to use completely different drivers. Buffer overrun could
be caused by a faulty driver, and this is an operation that takes no more
than 10 minutes and keep the 'could be hardware?' question out. Don't try to
update the driver, just pick a network card with a different chip.
----
And continuing the net search:
"WSAENOBUFS should occur when the system has not enough memory or other
system resources to open new TCP/IP socket or to handle socket data. It
looks like that in most cases the problem occurs when total count of opened
sockets reaches some magical number. MS writes that this limit is 3976
simultaneously opened sockets but it seems that on Win9x systems the real
limit is much lower."
I like magic numbers from Microsoft. So it seems that the problem you have
could be "easily port" to other systems...
So, look at Microsoft Knowledge Base:
Windows NT/2000:
http://support.microsoft.com/support/kb/articles/Q196/2/71.ASP
Windows 95: http://support.microsoft.com/support/kb/articles/Q170/7/91.ASP
And...
"Some users reported to us there is another solution for Windows 95/98/Me
which solved the problem at all. Windows 95/98/Me allows up to 100 (default
value) of concurrent TCP connections. It looks like when the number of
connection reaches the limit 10055 error is reported. The solution is to
increase the limit of simultaneous connections. You can do it by
changing/creating value of the key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\MaxConnection
s
If you will create the MaxConnections variable key use STRING type for it
(early Windows 95 used DWORD probably). Set the value to 300 for example,
restart the Windows and check whether 10055 problem disappeared."
Can you please check this on NT? I have here a Netware Server, a Linux
Server, W98 and W2K machines, but no NT ones....
"You can obtain a list of opened sockets (including sockets in close state)
using netstat utility: Run DOS Prompt and then type:
netstat -an | more
when you will press the Enter key you see a list of opened sockets (you will
see big number in *_WAIT state probably)."
You can log this to a file automatically, to see if the number increases.
Continuing searching I found also: "The problem is with low memory (memory
below 640k), not overall memory. Try to free up more conventional memory."
This is not documented, and I'm figthing to myself imagine that 'this could
not be true': will Microsoft use the conventional memory for buffering? Can
you imagine this?!?!?! I found the explanation a few minutes (sites) latter:
"According to Qualcomm's web-site (12/13/1996): "The buffers the error
message is referring to are TCP buffers. TCP/IP stacks need buffers where
they can store data that goes to/from the network. Since at a low level the
data has to be sent to a hardware device, the buffers generally have to be
in low memory (i.e., 1MB). This is valuable space for most users, so most
TCP/IP stacks have a way of controlling how many of these buffers the user
wants allocated."
(And back to my feeling of a bad NIC... If the hardware it's not fast
enough, or the driver is doing a bad job...)
Ok, I will finish my 'hobby' here. I think that this email could help you
somewere. Could you please reply to me if you found the solution?
Artur Anjos
Jason, did a net search on this and get:
"An operation on a socket could not be performed because the system lacked
sufficient buffer space or because a queue was full."
It matches your feeling, so I keep on:
"Once a port is closed, it takes 4 minutes (240 seconds) before the system
will reuse it. You can alter this behavior if you Add Value name
TcpTimedWaitDelay as a type REG_DWORD and set it to some decimal number in
the range of 30 - 300 seconds"
I really don't know about this, and it seems very important if you
connect/disconnect a lot.
(Is this your case? Your users connect do the job and disconnect?)
-----
Now a 'small private note': (I do network administration to a few
medium-size networks, and I really like this TCP problems....)
If this is network related, I will also try do replace the network card (try
a cheap one, just for testing) with a chip different from the one you have:
just to be shure to use completely different drivers. Buffer overrun could
be caused by a faulty driver, and this is an operation that takes no more
than 10 minutes and keep the 'could be hardware?' question out. Don't try to
update the driver, just pick a network card with a different chip.
----
And continuing the net search:
"WSAENOBUFS should occur when the system has not enough memory or other
system resources to open new TCP/IP socket or to handle socket data. It
looks like that in most cases the problem occurs when total count of opened
sockets reaches some magical number. MS writes that this limit is 3976
simultaneously opened sockets but it seems that on Win9x systems the real
limit is much lower."
I like magic numbers from Microsoft. So it seems that the problem you have
could be "easily port" to other systems...
So, look at Microsoft Knowledge Base:
Windows NT/2000:
http://support.microsoft.com/support/kb/articles/Q196/2/71.ASP
Windows 95: http://support.microsoft.com/support/kb/articles/Q170/7/91.ASP
And...
"Some users reported to us there is another solution for Windows 95/98/Me
which solved the problem at all. Windows 95/98/Me allows up to 100 (default
value) of concurrent TCP connections. It looks like when the number of
connection reaches the limit 10055 error is reported. The solution is to
increase the limit of simultaneous connections. You can do it by
changing/creating value of the key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\MaxConnection
s
If you will create the MaxConnections variable key use STRING type for it
(early Windows 95 used DWORD probably). Set the value to 300 for example,
restart the Windows and check whether 10055 problem disappeared."
Can you please check this on NT? I have here a Netware Server, a Linux
Server, W98 and W2K machines, but no NT ones....
"You can obtain a list of opened sockets (including sockets in close state)
using netstat utility: Run DOS Prompt and then type:
netstat -an | more
when you will press the Enter key you see a list of opened sockets (you will
see big number in *_WAIT state probably)."
You can log this to a file automatically, to see if the number increases.
Continuing searching I found also: "The problem is with low memory (memory
below 640k), not overall memory. Try to free up more conventional memory."
This is not documented, and I'm figthing to myself imagine that 'this could
not be true': will Microsoft use the conventional memory for buffering? Can
you imagine this?!?!?! I found the explanation a few minutes (sites) latter:
"According to Qualcomm's web-site (12/13/1996): "The buffers the error
message is referring to are TCP buffers. TCP/IP stacks need buffers where
they can store data that goes to/from the network. Since at a low level the
data has to be sent to a hardware device, the buffers generally have to be
in low memory (i.e., 1MB). This is valuable space for most users, so most
TCP/IP stacks have a way of controlling how many of these buffers the user
wants allocated."
(And back to my feeling of a bad NIC... If the hardware it's not fast
enough, or the driver is doing a bad job...)
Ok, I will finish my 'hobby' here. I think that this email could help you
somewere. Could you please reply to me if you found the solution?
Artur Anjos
----- Original Message -----
From: "Jason Chapman" <jason@...>
Subject: Re: [ib-support] Unusual server lockup 10061
> Everything is fine and then kerboom. I think the key is the INET10055
error
> (Buffer out of space), but I can't see what is causing it other than lots
of
> small Blobs being retrieved by clients.
>
> Cheers,
>
> JAC.