httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject another project: memory mgmt
Date Sat, 20 Dec 1997 10:10:01 GMT
Here's something else for someone interested. 

Apache's pools are a nice way to manage memory... but their performance
hasn't ever been evaluated.  They work quite well, but there's a few
things that can probably be improved:

- Nobody has checked to see if 8k is a good pool allocation size, it may
be that 16k is better... or even a staggered 16k initial allocation with
8k followons.  The actual number is going to depend on the modules in use
and the site's traffic.  But maybe we can instrument a few sites to find
out what the average requirements for a request are ... we may be able to
avoid a little extra work.

- We could malloc() in larger chunks so that we can do 4k aligned (or 8k,
whatever the native page size is) allocations.  We end up having to throw
away some memory doing this, because we need to round malloc returns up to
the next page boundary.  But that's why we'd allocate extra memory.  The
advantage to doing this is that it can improve the behaviour across

- Similar to last: use mmap() anon mappings instead of malloc() because
they're already 4k aligned (this is how malloc() is implemented on freebsd
and linux for example)... this wouldn't be portable so there'd need to be
another option to fall back on. 

- Given page aligned pools, we can improve performance on systems like
Solaris which do pessimistic memory allocation.  We change configuration
such that the pool passed around to all the config time routines is a pool
that will be considered constant after config time.  By contrast, the pool
passed to the init() functions is considered non-constant. 

Note, this does not violate the current API -- however it's possibly
something that some modules may have wrong.  In particular, the merging
functions are supposed to be idempotent.  The config structures are
shared, and it's generally not safe to go about mucking in them because
you could mess up further requests in the same child.

Given this constant pool, using mprotect() we mark it as read-only after
config time.  Thus when Solaris forks it doesn't have to allocate space
for it.  Er, well, there's a PR on this and a thread about it earlier this
summer... I think there's a bit more than just mprotect() that you need to
do on Solaris. 


View raw message