On Jan 8, 8:21pm, George Toft wrote:
> > For your application, it sounds to me like you need to increase your
> > per-process open file limit. (You may need to increase the overall
> > system limit too.) I notice that as root, I'm able to do
> > ``ulimit -n 2048'' and then ``ulimit -a'' actually shows that the limit
> > has been increased.
>
> But if you exit that shell and open another, you will find your change
> is gone - ulimit only affects the current and child shells.
True. This means that you either need to change this ulimit value
on a global scale or else find a way to change it in the shell that
invokes apache.
On a Red Hat like system, you may want to take a look at the
invocation of ulimit in /etc/rc.d/init.d/functions. I haven't tried
it, but I think if you change the ulimit command at this point to have
a "-n 2048" (or some such) argument, you'll effectively change the
ulimit for most of the processes on the system.
Of course, there's likely a more subtle way of doing this too.
> > I've done some tests (using calls to pipe()) and have determined that
> > I'm able to create more than 1024 open files when I do this. However,
> > it seems to me that not all functions implemented by glibc will
> > support more than 1024 files. In particular, the select() function
> > relies on the fd_set data structure to know which file descriptors to
> > wait for. It appears to me that you can't use this function for file
> > descriptor numbers past 1023. In /usr/include/bits/types.h (which is
> > included by /usr/include/sys/types.h), I see the following:
> >
> > /* Number of descriptors that can fit in an `fd_set'. */
> > #define __FD_SETSIZE 1024
> >
> > I think you're okay if your application uses poll() instead of
> > select() though.
>
> I'm not into rewriting Apache :)
Hmmm... I just took a look at the Apache source and am quite surprised
to see that it doesn't contain any code to use poll() for those systems
which support it. I would've thought that this would be at least
be a configuration option.
The other approach that you could take is to rebuild glibc with a
different __FD_SETSIZE value. Then rebuild Apache with the new header
files and linked against your rebuilt glibc...
(Yes, this would be a bit of work too.)
Kevin
(text/plain)