You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Wilfredo Sanchez <ws...@apple.com> on 1999/12/04 03:19:15 UTC

HARD_SERVER_LIMIT

  Is there any reason why Windows has a larger HARD_SERVER_LIMIT  
than Unix?  Why not bump up the value to 1024 for Unix as well?

  Apparently the apple.com guys don't want to use Apache because  
they've run into this limit when they tried it out. I can build them  
one with a larger limit, but I'm wondering if I should just change  
this limit for the built-in Apache on OS X, since we have no reason  
to think the system will crap out, and in any case we'd fix it if it  
did.  Is that a reasonable thing to do?

	-Fred


--
       Wilfredo Sanchez, wsanchez@apple.com
Apple Computer, Inc., Core Operating Systems / BSD
          Technical Lead, Darwin Project
   1 Infinite Loop, 302-4K, Cupertino, CA 95014


Re: HARD_SERVER_LIMIT

Posted by Sam Talebbeik <sa...@ix.netcom.com>.
I am assuming that OS X is a Unix variant. Are you referring to
the 1024 file descriptor per process limit on Unix or something else?
If it is file descriptors per process limit then it can be bumped up
with getrlimit() and setrlimit() combinarions on Unix.

    ST.

Wilfredo Sanchez wrote:

>   Is there any reason why Windows has a larger HARD_SERVER_LIMIT
> than Unix?  Why not bump up the value to 1024 for Unix as well?
>
>   Apparently the apple.com guys don't want to use Apache because
> they've run into this limit when they tried it out. I can build them
> one with a larger limit, but I'm wondering if I should just change
> this limit for the built-in Apache on OS X, since we have no reason
> to think the system will crap out, and in any case we'd fix it if it
> did.  Is that a reasonable thing to do?
>
>         -Fred
>
> --
>        Wilfredo Sanchez, wsanchez@apple.com
> Apple Computer, Inc., Core Operating Systems / BSD
>           Technical Lead, Darwin Project
>    1 Infinite Loop, 302-4K, Cupertino, CA 95014


Re: HARD_SERVER_LIMIT

Posted by Wilfredo Sanchez <ws...@apple.com>.
  Dirk, thanks for the info.

	-Fred


--
       Wilfredo Sanchez, wsanchez@apple.com
Apple Computer, Inc., Core Operating Systems / BSD
          Technical Lead, Darwin Project
   1 Infinite Loop, 302-4K, Cupertino, CA 95014


Re: HARD_SERVER_LIMIT

Posted by Tony Finch <do...@dotat.at>.
Brian Behlendorf <br...@apache.org> wrote:
>
>It was nice to see locus.apache.org able to do 509 simultaneous
>deliveries, a number I could probably bump higher if I rebuilt the
>FreeBSD kernel with a larger FD_SET, need to ask about that...

On FreeBSD-3 and later the kernel and libc are independent of
FD_SETSIZE, so you can compile userland apps with it defined to
whatever value you like and expect it to work. This is mentioned in
the NOTES section of the select(2) manual page.

Tony.
-- 
how to dot at

Re: HARD_SERVER_LIMIT

Posted by Brian Behlendorf <br...@apache.org>.
Chiming in late...

I think it would make sense to look, at compile time, for FD_SET or
whatever the equivalent #define on a given OS is, and then define
HARD_SERVER_LIMIT to be the maximum number of processes that the OS can
support presuming everything is done to prevent unnecessary FD's (e.g., no
2000 vhosts each with their own different logfile FD, etc).  This is what
qmail does to determine how many concurrent deliveries can be performed at
the same time.  It was nice to see locus.apache.org able to do 509
simultaneous deliveries, a number I could probably bump higher if I
rebuilt the FreeBSD kernel with a larger FD_SET, need to ask about that...
anyways, someone might want to look at qmail's configure/build process to
see how that's done, it should be portable given DJB's affinity for
Posix.

	Brian




Re: HARD_SERVER_LIMIT

Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 3 Dec 1999, Wilfredo Sanchez wrote:

>   Is there any reason why Windows has a larger HARD_SERVER_LIMIT  
> than Unix?  Why not bump up the value to 1024 for Unix as well?
> 
>   Apparently the apple.com guys don't want to use Apache because  
> they've run into this limit when they tried it out. I can build them  
> one with a larger limit, but I'm wondering if I should just change  
> this limit for the built-in Apache on OS X, since we have no reason  
> to think the system will crap out, and in any case we'd fix it if it  
> did.  Is that a reasonable thing to do?

In that case you could, and propably should, bump up that value. Unlike on
windows, where it is just the # of threads, on unix it control's a few
more things. Apart from the # of processes, it also is a hard max for the
size of the shared whatever table it uses (usually shared memory) etc.

Setting it high could cause some corresponding kernel tables go bang. But
on a sensible OS, low values like 1024 are no issue. Note though that on a
lowly loaded server, it is a bit of a waste, resource footprint wise, to
set it that high, 256 fits for 95% of the cases in my experience. The
remaining 5% know what they are doing... and know why they upp. it.


Dw