We have a web-server designed using select() that never really saw much load until last week and always used to work fine for our 500-1000 conn/s load. However, we recently started seeing much higher load (and spikes) and ran into the issue of select() going crazy after seeing a socket handle > FD_SETSIZE. This would just freeze up the server with select going into an unbreakable loop after timing out repeatedly if it had anything > FD_SETSIZE in its FD_SET. The option of switching to poll (or epoll) is not there right now and we have to stick with select. The way I fixed it for now is by increasing the listen queue and stop accepting new connections when I see a new one in return of accept() to be >= FD_SETSIZE and go back to select() on the listening socket. This works because the os recycles the file handles and always try to give the smallest available one. But the downside is I end up sending RST to some connections when calling accept() if the socket handle is >= FD_SETSIZE. This is still acceptable for now since it keeps the server running and connection drops are ~ 5%. Is there a way I can do it without dropping those connections. I don’t want to be keeping a count of all used handles and things which makes it too complicated. Is creating a bogus socket, checking its handle and closing it before calling accept will be fairly accurate estimation of what handle os is going to give me next.
while(max_conn_to_accept--){
SOCKET a_s = accept(..);
if(a_s >= FD_SETSIZE){
close(a_s);
return;
}
Just raise
FD_SETSIZE. Specify-DFD_SETSIZE=16384on the compiler command line.I think your version is recent enough that there are no other issues. If you get an error in a header file, you may need to tweak a line or two.
For example, if you see something like this:
Change it to this:
Or if you see:
Change it to:
But, again, I think you won’t need to change anything.