> I'm trying to use "SINGLE_LISTEN_UNSERIALIZED_ACCEPT"
> ...
> Is having the "UNSERIALIZED" and "FNCTL" stuff together
> a bad combination? Not sure where the FNCTL is defined.
SINGLE_LISTEN_UNSERIALIZED_ACCEPT and USE_FCNTL_SERIALIZED_ACCEPT can
coexist. The former means it's safe for different Apache child
processes to accept() simultaneously from the same socket at the same
time if there is only one socket (e.g., zero or one Listen directives).
The latter means, if there is more than one socket, Apache must
serialize accept() calls and fcntl() is the way to do it. See
htdocs/manual/misc/perf-tuning.html#acceptserialization
in your patched Apache tree for an explanation of all this.
> When I add "-ldl"
> to the build options (EXTRA_CFLAGS) then the compilation
> complains that dl isn't used for most objects, except
> now httpd finally builds clean (this appears to use dl).
Try moving the "-ldl" from the compiler flags (EXTRA_CFLAGS) to the list
of libraries the linker needs (EXTRA_LIBS). It's really a linker
option.
> -D USE_QSC
> -D QSC_HASH_SIZE=32768
> -D QSC_MAX_SIZE=4194304
> -D QSC_HEADER_GRAIN=32
> ...
> -D USE_STAT_CACHE
> -D STAT_CACHE_SIZE=32768
> -D STAT_CACHE_TIME=300
> -D STAT_CACHE_PATHLEN=128
>
> My webserver has 2GByte memory (Linux 2.2.13+bigmem)
> so I'm not sure whether the above QSC/STAT_CACHE
> settings are appropriate?
> ...
> I have ~40k active objects
With that much memory and that many files to cache you could stand to
increase QSC_MAX_SIZE. Watch the "Memory use / total" line on the
server-status page. You should probably double QSC_HASH_SIZE too,
although for diminishing returns -- but again only if you're using the
QSC for all of them. Read
htdocs/manual/qsc.html
(especially at #status) in your patched Apache tree for what all the
stats mean, how to see them, and how to tune your server to make the QSC
run smoother.
Your STAT_CACHE_SIZE seems big. The stat cache is really meant to be
small, and if most of the files are in the QSC the stat cache isn't
doing much anyway. See
htdocs/manual/misc/perf-mja.html#statcache
The rest look OK.
> Another idea I wanted to bring up is the possiblity
> for an automatic or auto-adapting MMAP function aka boa
> seems to have, in that you don't need to explicitly
> mmapfile (which is a major pain with >40k objects,
> and the object pool changing quite often.)
You're not the only one. There is a tradeoff though, as always:
Maintaining the cache in software slows things down. An adaptive
mod_cache is available in
ftp://ftp.apache.org/dist/contrib/modules/1.3/apache-contrib-1.0.8.tar.gz
but I have not used it and I'm told it's buggy.
> Finally is there a way to run 10x-patched Apache
> with the mod_ssl add-ons? Someone on this list
> mentioned they'd had "limited" success on this?
A few people, including myself, have applied both the 10x patches and
the mod_ssl patches. Apply 10x first, then mod_ssl. There are
conflicts you must resolve manually. I don't know of a good way to help
everyone who wants to use both: I don't want to distribute a combined
patch because that might ruffle feathers over in mod_ssl land, but there
are a couple of places in the combined tree that need special attention.
Anyone have any ideas?
> ursus@xxxxxxx
--
Michael J. Abbott mja@xxxxxxx http://reality.sgi.com/mja/
|