Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20040906190949.40523.qmail@pb1.pair.com>
To: internals@lists.php.net
Date: Mon, 06 Sep 2004 20:12:09 +0100
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
References: <20040905193319.91641.qmail@pb1.pair.com> <20040905211921.39505.qmail@pb1.pair.com> <Pine.LNX.4.58.0409051509200.1473@t42p> <20040905223229.41761.qmail@pb1.pair.com>
In-Reply-To: <20040905223229.41761.qmail@pb1.pair.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Really odd PHP problem
From: russ@last.fm (Russ Garrett)

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