Using asynchronous sockets in Windows Server 2008 R2 results in 100% CPU utilization

I have a pretty common socket server in C # that uses asynchronous methods of socket classes - BeginAccept (), BeginReceive (), etc. This server has been working fine for the past 4 years on many client sites running Win Server 2003. Recently, I installed it on a 64-bit Windows Server 2008 R2 server. Everything looks fine until the first client connects and calls BeginReceive () and BeginAccept () in the accept handler. When this happens, the CPU utilization reaches 100% and stays that way until I close the socket for listening.

Not sure if this is important, but the server is running on a virtual machine.

We have done many tests, but nothing helps. Using the Process Explorer, I see that two of the two threads are deployed immediately after the calls to BeginReceive () / BeginAccept (), and they are the ones that consume the processor. Unfortunately, I cannot reproduce this problem on my 64-bit Win7 workstation.

I have done a lot of research, and all I have found so far is the following two KB articles, which imply that Server 2008 R2 may have problems with TCP / IP components, but they are only available as hot fixes: KB2465772 and KB2477730. I do not want my client to install them until I am sure that they will fix the problem.

Has anyone else had this problem? If so, what did you need to do to solve this problem?

Here is a way that I think causes the situation:

private void AcceptCallback(IAsyncResult result) { ConnectionInfo connection = new ConnectionInfo(); try { // Finish accept. Socket listener = (Socket)result.AsyncState; connection.Socket = listener.EndAccept(result); connection.Request = new StringBuilder(256); // Start receive and a new accept. connection.Socket.BeginReceive(connection.Buffer, 0, connection.Buffer.Length, SocketFlags.None, new AsyncCallback(ReceiveCallback), connection); _serverSocket.BeginAccept(new AsyncCallback(AcceptCallback), listener); // CPU usage spikes at 100% shortly after this... } catch (ObjectDisposedException /*ode*/) { _log.Debug("[AcceptCallback] ObjectDisposedException"); } catch (SocketException se) { connection.Socket.Close(); _log.ErrorFormat("[AcceptCallback] Socket Exception ({0}: {1} {2}", connection.ClientAddress, se.ErrorCode, se.Message); } catch (Exception ex) { connection.Socket.Close(); _log.ErrorFormat("[AcceptCallback] Exception {0}: {1}", connection.ClientAddress, ex.Message); } } 
+4
source share
2 answers

The problem was caused by the presence of more than one BeginAccept () call when setting up the receiving socket. I don’t know why the problem only occurs on 64-bit servers, but changing the code, as shown below, fixes the problem.

Source:

 public SetupServerSocket() { IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, _port); // Create the socket, bind it, and start listening. _serverSocket = new Socket(myEndPoint.Address.AddressFamily, SocketType.Stream, ProtocolType.Tcp); _serverSocket.Bind(myEndPoint); _serverSocket.Listen((int)SocketOptionName.MaxConnections); for (int i = 0; i < 10; i++) { _serverSocket.BeginAccept(new AsyncCallback(AcceptCallback), _serverSocket); } } 

To the next:

 public SetupServerSocket() { IPEndPoint myEndPoint = new IPEndPoint(IPAddress.Any, _port); // Create the socket, bind it, and start listening. _serverSocket = new Socket(myEndPoint.Address.AddressFamily, SocketType.Stream, ProtocolType.Tcp); _serverSocket.Bind(myEndPoint); _serverSocket.Listen((int)SocketOptionName.MaxConnections); //for (int i = 0; i < 10; i++) { _serverSocket.BeginAccept(new AsyncCallback(AcceptCallback), _serverSocket); //} } 
+1
source

I know the article “Wire Performance” where you found SetupServerSocket () - the source 10x loop for support supports 10 listening threads if you have fast new client connections. You changed it to one listener. Perhaps the only possible solution if Win2k8r2 has such an error. You might want to make sure that you have a reliable connection retry code on your client.

Get closer to the wire with high-performance sockets in .NET. http://msdn.microsoft.com/en-us/magazine/cc300760.aspx

+1
source

All Articles