I'm flooded with this warning when my system is under a high load and uses
a lot of sockets/file descriptors. I get it in stream_select:
"E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with
a larger value of FD_SETSIZE.
It is set to 1024, but you have descriptors numbered at least as high as
--enable-fd-setsize=2048 is recommended, but you may want to set it
to equal the maximum number of open files supported by your system,
in order to avoid seeing this error again at a later date."
Why would you even have a limit for this? Having your application suddenly
crash because of some undocumented arbitrary internal PHP limit is a real
punch-in-the-face for people trying to build robust PHP-CGI applications.
Can someone explain to me why I need to be bothered about this?
~Hannes
I'm flooded with this warning when my system is under a high load and uses
a lot of sockets/file descriptors. I get it in stream_select:"E_WARNING:
E_WARNINGcaught:stream_select(): You MUST recompile PHP with
a larger value of FD_SETSIZE.
It is set to 1024, but you have descriptors numbered at least as high as
--enable-fd-setsize=2048 is recommended, but you may want to set it
to equal the maximum number of open files supported by your system,
in order to avoid seeing this error again at a later date."Why would you even have a limit for this? Having your application suddenly
crash because of some undocumented arbitrary internal PHP limit is a real
punch-in-the-face for people trying to build robust PHP-CGI applications.
Can someone explain to me why I need to be bothered about this?
FD_SETSIZE is a system limit on the number of open files a single
process can have. From a bash shell type: ulimit -n
and you will probably see this magical 1024 number pop up. This means
that the default is 1024 on your system, so raising it in PHP won't
actually do anything unless you also raise it on your system. We try to
match the limit in order to give you a sensible error message instead of
your program just breaking quietly, or with a warning that doesn't tell
you that it is due to hitting a system limit.
So, in order to raise this you have to both tell your operating system
that you want to allow individual processes to open more than 1024 files
each and you have to recompile PHP with this higher limit.
Now, having said that, I don't quite understand why a single PHP cgi
process would ever need more than 1024 open files at the same time. What
exactly are you doing that needs this many descriptors? Sounds like you
have a descriptor leak there somehow.
-Rasmus
Am 13.01.2012 17:36, schrieb Rasmus Lerdorf:
FD_SETSIZE is a system limit on the number of open files a single
process can have. From a bash shell type: ulimit -n
and you will probably see this magical 1024 number pop up. This means
that the default is 1024 on your system, so raising it in PHP won't
actually do anything unless you also raise it on your system. We try to
match the limit in order to give you a sensible error message instead of
your program just breaking quietly, or with a warning that doesn't tell
you that it is due to hitting a system limit.So, in order to raise this you have to both tell your operating system
that you want to allow individual processes to open more than 1024 files
each and you have to recompile PHP with this higher limit.Now, having said that, I don't quite understand why a single PHP cgi
process would ever need more than 1024 open files at the same time. What
exactly are you doing that needs this many descriptors? Sounds like you
have a descriptor leak there somehow.
on "old" sysv-systems it was easy to raise this number
with "modern" systemd-units "LimitNOFILE=30000" as example is
ONE simple line to raise this limit
it is not the job of PHP try to GUESS system-limits and
define them on compile-time
Am 13.01.2012 17:36, schrieb Rasmus Lerdorf:
FD_SETSIZE is a system limit on the number of open files a
single process can have. From a bash shell type: ulimit -n and
you will probably see this magical 1024 number pop up. This
means that the default is 1024 on your system, so raising it in
PHP won't actually do anything unless you also raise it on your
system. We try to match the limit in order to give you a sensible
error message instead of your program just breaking quietly, or
with a warning that doesn't tell you that it is due to hitting a
system limit.So, in order to raise this you have to both tell your operating
system that you want to allow individual processes to open more
than 1024 files each and you have to recompile PHP with this
higher limit.Now, having said that, I don't quite understand why a single PHP
cgi process would ever need more than 1024 open files at the same
time. What exactly are you doing that needs this many
descriptors? Sounds like you have a descriptor leak there
somehow.on "old" sysv-systems it was easy to raise this number with
"modern" systemd-units "LimitNOFILE=30000" as example is ONE simple
line to raise this limitit is not the job of PHP try to GUESS system-limits and define them
on compile-time
It isn't a guess. FD_SETSIZE isn't set by PHP, but all sorts of
underlying things need to know what FD_SETSIZE is in order to work
correctly so unfortunately when you increase it you are going to need
to recompile. This isn't unique to PHP. There are some ways to hack
around this, but they are all ugly.
-Rasmus