Re: [Fastcgipp-users] Internal server error - the nfds value exceeds the RLIMIT_NOFILE value

[Eddie Carle]

On Fri, 2011-03-25 at 12:38 +0100, Aurélien Geay wrote:
> Im currently develop an web app based on fastcgi++ library + lighttpd.
> 
> I have some problems when the server is load : I have  an “500 -  
> Internal Server Error“ and this log trace from my fcgi app :
> 
> “ The nfds value exceeds the RLIMIT_NOFILE value. “
> 
> I have no idea on what’s cause this error …
> 
> Can you give some clue ? 

Interesting. I remember worrying about this happening when I was first
writing the low level part of the code. The error is generate at
transceiver.cpp:77. It would seem as though the system is trying to
allocate more file descriptors than the operating system wants to
allows.

        RLIMIT_NOFILE is a number one greater than the maximum value
        that the  system may assign to a newly-created descriptor. If
        this limit is exceeded, functions that allocate a file
        descriptor shall fail with errno set to [EMFILE]. This limit
        constrains the number of file descriptors that a process may
        allocate.

It appears you could use getrlimit() and setrlimit() int your main()
function to up this number.

This does raise an interesting question though as what should be done
when this error happens. Right now the system crashes, but perhaps this
is not the best behaviour? Maybe it should deny new requests?

This also brings back another point that I was quite strong on before.
Lighttpd, nginx, apache; They all do something really stupid as far as I
am concerned. The fastcgi protocol allows for all connections to be
shared on a single file descriptor or connection. The fastcgi++ library
should handle this very efficiently (unfortunately never tested because
no webservers do it). Instead though, they are open a new connection for
every single incoming client request. This creates (as you can see) a
lot of overhead when there are many concurrent connections. Maybe I'll
go whine to the lighttpd guys again about this.
-- 
        Eddie Carle