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