Hi Thomas,
On Wed, 26 Jan 2000, James G Smith wrote:
> Thomas Corte <[EMAIL PROTECTED]> wrote:
>>So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect
>>to decrease top's values above significantly?
>
> I don't think so. My understanding of DSOs in Apache was to allow
> inclusion of code without recompiling the whole thing. This allows
> for third-party proprietary modules. The DSOs can, in general,
> share code across binaries, not processes. All processes sharing a
> binary don't have separate copies of the binary, or shouldn't.
> However static libraries cannot be shared between binaries. Only
> DSOs. Your biggest savings could come from making the perl core a
> DSO so the perl binary and Apache share the same core perl
> interpreter code.
James is quite right, but I'm told that even making the perl core a
DSO won't give the savings that I think you are hoping for.
In a mod_perl box, as far as memory consumption is concerned, the
processes of concern are usually the Apache children. They are fairly
big, and there can be a lot of them. Because of the way that Apache
tries to preempt incoming requests by pre-forking a pool of children
`just in case', you may not always know how many! They share a good
chunk of their memory when they are forked, but then as a result of
copy-on-write (two or more processes share a page of memory, one wants
to change it, the others don't, so a copy has to be made just for that
process) the memory gradually (or otherwise) becomes unshared. When
they grab some memory to store a large object, the children have a
habit of hanging on to it until they die. In addition there have been
memory leakage and similar problems which have sometimes caused the
Apache children to do antisocial things like growing without bound and
refusing to die. Some of these problems are being dealt with as new
releases come out and I'm sure that a lot of us have high hopes for
mod_perl 1.22.
Running a second server (a `proxy', not mod_perl enabled, and which
listens normally on port 80 but always on a _different_ port from the
mod_perl enabled server) to serve static documents, tweaking the
server configuration variables such as MaxRequestsPerChild to limit
child growth, the use of modules designed to limit the processes'
resource consumption, and faster networks, clients and servers can all
offer partial solutions, but I feel that memory footprint is going to
remain an issue with mod_perl until memory is much cheaper per byte
(happening as we write) or until Doug and friends make it use less, or
until something unthinkable happens - like the technology becoming
obsolete overnight because of a breakthrough elsewhere.
In the meantime, some people are using Gigabytes of RAM to cope with
their mod_perl children.
I hope this isn't too depressing:)
73,
Ged.
