i can confirm it. it's the problem of cacher. mmcache is rather complex and NOT stable, although many ppl is running happily, they're not under heavy load. 1 hours to 1days after apache is restarted, mmcache end up with all page randomly crash (share mem courpo
APC works with apache2 DSO, and the optimizer is stable ONLY with my patches check it out here: http://pecl.php.net/bugs/search.php?cmd=display&status=Open&bug_type[]=APC i've used APC from the time my last patch posted till now, having 0 crash. (if i clear the cache after long time running, about 1/10 chance will get crash) FYI: my script seems never beyond cache size phpa, is quite stable untill the author stopped releasing new version even i installed the phpa "which can't work with my lastest php", my page is still ok. this is because: it has "crash recover" scheme: mark the share memory to "reset" on crash, and reset it when it get write lock of share mem. phpa fall back to non-caching whenever it failed to operate on the share mem, thus no hanging. phpa stopped itself but won't let php down/hang if the share memory is dead locked or messed up or even can't be recovered. (i know it by reading the log when phpa crash, some of the above is base on guessing) both mmcache and apc does not have "crash recover" does Zend products implement it? ----- Original Message ----- From: "Russ Garrett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 06, 2004 3:35 AM Subject: [PHP-DEV] Really odd PHP problem > OK, first of all I apologise for not posting this in the "right place", > but this is an unreproducable bug (the worst kind...), and I need some > educated guesses as to what is causing it. This thing has me at my wits' > end... > > The situation is this: Apache on our main dynamic web server keeps on > suddenly eating all 3+GB of available virtual memory. When this happens, > the server stops responding to all requests, and basically freezes until > the kernel OOM killer gets around to killing enough httpd processes so > we can get in to kill the rest and restart it. This happens every couple > of minutes to couple of hours - there's no pattern to it. You can see an > attractive graph of the occurence here: > > http://static.last.fm/phpbug/mem.gif > > As you can see, the memory usage shoots up suddenly - it doesn't appear > to be a conventional memory leak. This is accompanied by a similar spike > in the number of apache processes - right up to the MaxClients limit. > > We've been running PHP with debug support enabled for the last couple of > days, and we've noticed that a series of errors is always logged just > before the spike in memory usage. A log snippet is available here (note > that these errors carry on for several pages - although I suspect the > first one is the only relevant one - this is only the first page or so): > > http://static.last.fm/phpbug/log.txt > > The error doesn't just happen with that script, however the initial > error always occurs in the same place (zend_variables.c:44). > > This machine serves around 500,000 hits daily, and 99% of them are > PHP-parsed. It's running Debian 3.0 with backported kernel 2.6.7. The > bug manifests itself with both Apache 1.3 and 2, and both PHP 4.3.8 and > 4.3.9RC2. Compile options are as follows: > > './configure' '--with-apxs2=/web/apache2/bin/apxs' '--without-mysql' > '--with-zlib-dir=/usr' '--enable-gd-native-ttf' '--with-gettext' > '--enable-mbstring' '--with-pgsql=/usr/local/pgsql' '--enable-sysvmsg' > '--with-gd' '--with-jpeg-dir=/usr' '--enable-debug' > > The only third-party module we're using is Turck mmcache - removing it > is kind of difficult since running without any cache brings the machine > to its knees :). > > Sorry about the length of this message, I had to fit all the details > in... I'd appreciate it if you have any suggestions at all, this is > really annoying me now. It's problems like this with PHP which make me > consider moving to Java ;)... Anyhow. > > Thanks in advance, > > Russ Garrett > [EMAIL PROTECTED] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >