RE: having problem serving multitude virtualhosts
Hi!
I can imagine setting up logging wisely one could use less descriptors for
logging but at some stage it doest help any more. At cerntain point we
have to increase descriptors available for apache or making apache to use
more descriptors than the default (1024)?
Oh, and i found from httpd.apache.org list archives interesting hint about
using instead <VirtualHost> directive the mod_rewrite! That way one needs
not to restart apache after adding virtual host or so it says :)
Imre
On Wed, 8 Jan 2003, Narins, Josh wrote:
> Instead of a single file, log to a single process, which can handle any
> variety of situations.
>
> For instance, it could cache 100 hits to each virtual server before it
> rights to the log, and it also flushes to disk when the server produces
> error log output.
>
> HTH
>
>
> -----Original Message-----
> From: Imre Oolberg [mailto:imre@eenet.ee]
> Sent: Wednesday, January 08, 2003 2:46 PM
> To: debian-user@lists.debian.org
> Subject: having problem serving multitude virtualhosts
>
>
> Hi!
>
> I am thinking of serving some hundreds virtualhosts
> each with separate log and errorlog on PC having 768 MB RAM and 2 GB swap
> using Debian Woody and debian package kernel 2.4.18.
>
> >From some point apache didnt start, giving error like
>
> Too many open files: unable to open a file descriptor above 15, you may need
> to increase the number of descriptors
>
> Obviously it helped to insert into the /etc/init.d/apache
>
> ulimit -S -n 8192
>
> And after some time we discovered that CGI scripts started to behave
> strangely, giving only headers or just hanging. Anyway, in the errorlog was
> different message
>
> [Sat Jan 4 21:49:08 2003] [warn] send body: filedescriptor (1137) larger
> than FD_SETSIZE (1024) found, you probably need to rebuild Apache with a
> larger FD_SETSIZE
>
> I searched the web and found out one recommendation of compiling apache with
> rised DF_SETSIZE. So i added in the debian/rules the following value to the
> CONFLAGS
>
> -DFD_SETSIZE=4096
>
> And while building deb source package i recieved those warnings
>
> gcc -c -I../os/unix -I../include -DLINUX=22 -DTARGET=\"apache\"
> -I/usr/include/db1 -DDEV_RANDOM=/dev/random -DUSE_HSREGEX
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -DFD_SETSIZE=4096 `../apaci`
> ap_slack.c In file included from /usr/include/sys/types.h:215,
> from ../include/ap_config.h:86,
> from ../include/httpd.h:72,
> from ap_slack.c:67:
> /usr/include/sys/select.h:77: warning: `FD_SETSIZE' redefined
> *Initialization*:1: warning: this is the location of the previous definition
>
> At the beginnging it seemed, these manipulations have taken care of the
> problem, but before too long i noticed the same FD_SETSIZE warnings again.
>
> Please, could you give me some advice what to do besides to distribute
> virtual hosts between to servers :)
>
> Also, i found hints from the internet that changing FD_SETSIZE aint easy
> matter and actually one needs to change it systemwide?
>
> Searching lists around httpd.apache.org i found a suggestion of writing all
> logs into one place (pipe?) and sepatating them afterwards. Althought it
> could be somewhat solution, is there some other (preferrably counfigurable)
> way of doing it?
>
>
> Best Regards, Imre Oolberg
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> ------------------------------------------------------------------------------
> This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
>
>
>
>
Reply to: