I was running a very big application on Windows 2003 server. It creates almost 900 threads and a single thread who is operating on a socket. It’s a C++ application which I had compiled with Visual Studio environment.
After almost 17-20 hours of testing, I get 10055 socket error while sending the data.
Apart from this error my application runs excellently without any error or issue. It’s a quad core system with 4 GiB of RAM and this application occupies around 30-40% CPU (on all 4 CPUs) in all of its running.
Can anyone here help me to pass through this. I had searched almost everything on google regarding this error but could not get anything relevant to my case.
Prof. Falken
23.9k19 gold badges100 silver badges169 bronze badges
asked Jun 16, 2011 at 6:21
I have seen this symptom before in an IOCP socket system. I had to throttle outgoing async socket sends so that not too much data gets queued in the kernel waiting to be sent on the socket.
Although the error text says this happens due to number of connections, that’s not my experience. If you write a tight loop doing async sends on a single socket, with no throttling, you can hit this very quickly.
Possibly @Len Holgate has something to add here, he’s my «goto guy» for Windows sockets problems.
answered Jun 16, 2011 at 14:52
Steve TownsendSteve Townsend
53.2k9 gold badges91 silver badges139 bronze badges
2
It creates almost 900 threads
That’s partially your problem. Each thread is likely using the default 1MB of stack. You start to approach a GB of thread overhead. Chances of running out of memory are high. The whole point of using IOCP is so that you don’t have to create a «thread per connection». You can just create several threads (from 1x — 4x the number of CPUs) to listen on the completion port handler and have each thread service a different request to maximize scalability.
I recall reading an article linked off of Stack Overflow that buffers you post for pending IOCP operations are setup such that the operating system WILL NOT let the memory swap out from physical memory to disk. And then you can run out of system resources when the connection count gets high.
The workaround, if I recall correctly, is to post a 0 byte buffer (or was it a 1 byte buffer) for each socket connection. When data arrives, your completion port handler will return, and that’s a hint to your code to post a larger buffer. If I can find the link, I’ll share it.
answered Jun 18, 2011 at 5:57
selbieselbie
96.2k14 gold badges103 silver badges171 bronze badges
- Информация о материале:
- Опубликовано: 2013-05-15
- Обновлено: 2015-09-19
- Автор: Олег Головский
Обломилось подключение к ICQ с сообщением о неизвестной ошибке. Process Explorer при запуске выдал «Insufficient system resources to get handle information». Tunnelier выдал «Socket: WSAGetOverlappedResult operation failed with error 10055. Windows error 10055: Невозможно выполнить операцию на сокете, т.к. буфер слишком мал или очередь переполнена.»
В большинстве случаев рекомендовалось шаманить с Tcpip в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters, менять MTU, менять саму сетевую карту и всё в таком духе, а некоторые даже шли на переустановку ОС Windows, что также не решало проблему.
Реальная проблема оказалась в настройке ОС Windows «Использование памяти — Оптимизировать работу — программ/системного кэша«, которая была установлена в «Оптимизировать работу — системного кэша«, возврат в «Оптимизировать работу — программ» решил проблему с ошибками «No buffer space available«, «Insufficient system resources to get handle information» и «Socket: WSAGetOverlappedResult operation failed with error 10055. Windows error 10055: Невозможно выполнить операцию на сокете, т.к. буфер слишком мал или очередь переполнена.«.
Такая настройка ОС Windows также чревата ошибками с «VMware Workstation» подобно этой:
VMware Workstation unrecoverable error: (vcpu-0)
NOT_IMPLEMENTED d:/build/ob/bora-744570/bora/vmcore/vmx/main/pshare.c:1477
A log file is available in «F:VIRTUALFreeBSDvmware.log». Please request support and include the contents of the log file.
To collect data to submit to VMware support, choose «Collect Support Data» from the Help menu.
You can also run the «vm-support» script in the Workstation folder directly.
We will respond on the basis of your support entitlement.
Если виртуальная машина вовсе не запускается, то временно решается выполнением C:Program FilesVMwareVMware Workstationvmware-vdiskmanager -R <path of the vmdk(virtual disk)>, где <path of the vmdk(virtual disk)> — это путь к каталогу (не файлу!) виртуальной машины.
Ссылки по теме:
- При попытке соединения через TCP-порты с номером более 5000 появляется сообщение об ошибке ‘WSAENOBUFS (10055)’
- Параметры конфигурации TCP/IP и NBT для Windows XP
- VMware KB: No buffer space available errors appear in Windows Event Log
- VMware KB: Troubleshooting a Workstation runVM failed unrecoverable error
- VMware KB: VMware product unexpectedly fails with an unrecoverable error
← →
yuravss
(2002-02-25 04:45)
[0]
Мой клиент делает безуспешные попытки соеденится к отсуствующему серверу каждые 3 сек (по таймеру). Если сервер запустить через некоторое время, он нормально подконектится, но если это время большое (>10 мин) то клиент тупо отказывается конектится к уже запущеному серверу. При отладке клиента я обнаружил, что при многочисленных ,безуспешных попытках подконектится, клиент вскорее генерирует exception в ответ на ClientSocket1.open. Код ошибки 10055, on API Connect. И потом при следующих попытках соединения (каждые 3 сек) через ClientSocket1.open это exception постоянно возникает. В чем дело ? Привожу фрагменты кода.
//Таймер — каждые 3 сек.
procedure TForm1.ConnectingTimerTimer(Sender: TObject);
begin
….
try
sleep(100);
ClientSocket1.open; //Генерирует ошибку через 10 мин.
except
//Вот тут происходит обработка ошибки 10055
ClientSocket1.close;
end;
end;
//Обработка ошибки, если сервер неактивен.
//Но через 10 мин. Этот код уже не будет выполнятся в ответ на ClientSocket1.open, поскольку возникает ошибка 10055.
procedure TForm1.ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
ClientSocket1.close;
ConnectingTimer.enabled:=true;
end;
procedure TForm1.ClientSocket1Connect(Sender: TObject;
Socket: TCustomWinSocket);
begin
ConnectingTimer.enabled:=false;
end;
———————
Почему ошибка возникает ? Такое ощущение что это вина Windows.
Я нашел исходники к компоненте FTP. Вот что там написано по поводу ошибки 10055:
For an unknown reason, winsock need time to send last data buffer. Without this delay, we may end with a partial file transfer. See comments in DoPutAppendAsync function. Normally using Linger option would handle this case. But many winsock implementations will end with a 10055 error after a lot of consecutive file transfers.
Что бы это значило ? Задержка то у меня стоит sleep(100)
← →
yuravss
(2002-02-25 12:30)
[1]
Кстати вот нашел описание этой ошибки:
10055 is an WinSock»s (Microsoft»s TCP/IP stack implementation) error code.
What causes this bug?
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.
Proxy+ uses permanently about 10-20 opened sockets (it depends on configuration, number of defined Mapped Links,…) and each client request allocates two sockets — one for client side and one for server side of connection. Because TCP/IP system doesn»t free sockets immediately when they are closed (socket remains allocated for 240 seconds after application closes it) it is possible that system will report WSAENOBUFS due to lack of free socket resources.
————-
Только я не пойму из-за чего у меня происходит переполнение сокетного буфера. Я ведь использую функцию close для сокета в случае неудачного конекта.
← →
yuravss
(2002-02-25 20:24)
[2]
Неужели никто не сталкивался с этой проблеммой ?
Я уже было потерял надежду.
Перекопал пол инет, но нашел в чем дело !
Оказывается в обработчике TForm1.ClientSocket1Error надо писать не ClientSocket1.close, а socket.close. Тогда все нормально. А доказательства о переполнении сокетного буфера я видел наочно
(команда: netstat -an )
Помоему проблема решена. Тему «10055 error» можно закрыть ИМХО.