fastcgipp-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eddie Carle
Subject: Re: [Fastcgipp-users] Internal server error - the nfds value exceeds the RLIMIT_NOFILE value
Date: Sun, 27 Mar 2011 11:21:34 -0600

On Fri, 2011-03-25 at 12:38 +0100, Aurélien Geay wrote:
Hello,

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
ERC Technical Services
address@hidden
+1.780.934.9509

This message has been signed with an RFC4880 signature. It is guaranteed to have originated from Eddie Carle and its contents can be validated against its signature.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]