On Mon, Feb 05, 2007 at 10:29:25PM +0000, Stephen Gran wrote:
> This one time, at band camp, Pierre HABOUZIT said:
> > I also have a hard time understanding why having 1000+ virtualhosts in
> > apache would create such problems (except if you listen of 1000+
> > different ports btw, but I don't think it would be a very clever setup
> > anyway :])
>
> Because you have an open fd per virtual host for logfiles. Whether
> apache has all the fd's open itself, or it pushes the logs to a named
> pipe that does the splitting for apache, something still has all those
> fd's open and you can run into this fairly quickly.
Oh, good point. Though I suppose it's iff you have one logfile per
virtualhost, which is not necessarily true.
Anyway , in that case, raising __FD_SETSIZE won't help, as it's a
kernel limitation that forbids a usual process to open more than
getdtablesize() process open, except if you performed a setrlimit
before.
TTBOMK __FD_SETSIZE is only used for fd_set's (so select, FD_* macros,
...), and redefining it won't work (I tried already in another life)
without recompiling the libc at least -- if not the kernel too, I'm less
sure about that one -- and that would be obvioulsy binary incompatible
with the rest of the linuxes around the globe :)
Another possibility here, is that apache:
1. did the setrlimit
2. opened a lot of fd's for the logfiles (or anything else)
3. does not have <1024 available fd's anymore, hence cannot use select
over them => you're screwed.
If you need to use more than 1024 file descriptors in a program for
this or that reason, you should not use select at all, this is a POSIX
limitation.
So if the submitter really cares about that problem, I'd suggest him
to reassign the bug to apache, asking for a poll()-based implemenation
(that has no 1024-fd's limitations AFAICT).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgp4tr4J7WcEF.pgp
Description: PGP signature