On Mon 19 Jan 2009, Michael Ludwig wrote: > > In fact, it is worse than fork()ing off unix processes because the > > interpreter data is completely copied while a new interpreter is > > created. On the other hand a forked process copies only those pages > > that are written to. > > Thanks. If I'm understanding correctly and this is true (and not > considering SEGVs), the total memory cost for a mod_perl on a worker > MPM should outweigh that for mod_perl on a prefork MPM, which seems > to not be aligned with what Craig has observed.
Of course it depends on your setup. If you configure only a small number of interpreters then the overall memory footprint can be lower then with prefork where each process runs its own interpreter. But the effect of the copied interpreters outweighs this very soon. Measuring memory consumption on Linux is not simple. You can't simply add up all RSS or VSZ figures or something like this. I know of 2 approaches that work more or less well. 1) call mlockall in the parent and then use /proc/PID/smaps (or Linux::Smaps) to measure shared memory 2) take a system with enough RAM and nothing else to do, start apache with different numbers of children and watch the free memory with vmstat while doing so. Then you can estimate the amount of memory that is consumed by one apache process. See the attached picture for example. > In order to be on the safe side as far as Berkeley DB is concerned, > you'd have to make sure up front that the environment is safe to use, > which is done by running recovery (DB_RECOVER flag, DB_RUNRECOVERY > error code) in a single thread or process that has exclusive access > to the environment. You can run recovery in a separate process spawned at startup by the parent. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
<<attachment: experiment-scrambled.png>>
