You are going to have to narrow this down further for us to have any chance to help you. Put your stuff on a development server and hit your various pages looking for that error or the request that causes your httpd to grow to 200M (use Apache1, not Apache2 for this). Or if all else fails replay the log to it to recreate the situation. Then replay it slower without an opcode cache and get it down to a single script and then a specific part of that script.
-Rasmus On Mon, 6 Sep 2004, Russ Garrett wrote: > OK, the situation seems a lot more stable with Zend Accelerator instead > of mmcache, and we're regularly getting quite a few "checksum failed" > errors in the logs, which does tend to indicate that shared memory > corruption was (and still is) happening. But now I don't have to restart > the damn thing every hour, at least for the duration of the 30-day trial ;). > > However, now we've eliminated this problem, another becomes obvious. > Namely that there does seem to be a small amount of memory leaking - > likely due to the crashes which are still occurring (i.e. those detailed > here: http://static.last.fm/phpbug/log.txt). > > This results in some Apache children taking up 200MB+ of RAM and > lingering there, not serving any requests, until they're killed or the > server is restarted. Regrettably I can't be more specific because the > location in our code that the crashes happen is random (the location in > PHP always appears to be zend_variables.c line 44). > > Since the httpd processes appear to just hang, the Apache > MaxRequestsPerChild setting is useless against this. > > Thanks *so much* for your help so far, it is most appreciated. We seem > to be ridiculously unlucky when it comes to these sorts of things... > > Cheers, > > Russ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
