php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36755 Initial memory usage unpredictably jumps
Submitted: 2006-03-16 02:16 UTC Modified: 2008-10-30 15:45 UTC
From: tif at avatartechnology dot com Assigned:
Status: Not a bug Package: Performance problem
PHP Version: 4.4.2 OS: Suse Linux
Private report: No CVE-ID: None
 [2006-03-16 02:16 UTC] tif at avatartechnology dot com
Description:
------------
We have a webapp which works flawlessly for months at a time, and then suddenly has memory usage problems.  We've debugged this enough to know that this is not a gradual growing of memory usage, but a sudden jump.  We have put in a check using get_memory_usage that runs on the startup of each page and the returned number stays very steady (around 16K), then it will suddenly start returning a large number (around 4M seems to be a number I see alot).  We even wrote a 1-line php script which prints the number and monitored it.  It remains unchanged until this problem occurs and then it remains at the high number until apache is restarted.  Searching the logs, I find no unusual activity at the time of the change.

I lied about the PHP version because we have seen this on many versions of PHP4, different linux distros, and different Apache versions, with and without Zend.  I'll be happy to perform most any debug steps you can think of.  We are unfortunately unable to install random versions of PHP since these are production servers.  We are currently running 4.3.10.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-16 08:40 UTC] tony2001@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.


 [2006-03-17 19:38 UTC] tif at avatartechnology dot com
I understand the whole "this might be fixed already" thing, but I don't think debugging this bug is going to fit the normal model.  Even if I do upgrade, it could be months before I see the problem again.  Heck, you'll probably have a new version I need to upgrade to by then.  I want to help you find this bug but I'm out of ideas.  How about some suggestions for what to monitor, or what to look at next time it happens, or what might count as an unusual condition that could cause this?
 [2008-10-30 15:45 UTC] tif at avatartechnology dot com
I think I've finally made a major discovery regarding this bug.  Our 
webapp uses some unconventional techniques and operates on some 
rather large datasets.  By logging apache process IDs that exhibit 
the problem and tracking exactly what the history of that process 
was, I believe I have located the problem although I haven't reduced 
it to a trivial reproduction.  My theory is:

  There is a specific kind of out-of-memory condition that corrupts 
the PHP process.

When we have encountered this problem the script dies without 
outputting any error message.  Apache logs the request as outputting 
5 bytes.  Future requests that use the same process do not have all 
of the usual memory available to them.

The "unconventional techniques" that our webapp uses are an intense 
combination of "eval" statements, functions using "var args", array 
operations, output buffering, and error capturing.  I understand that 
reducing this to a small script that causes the problem is the right 
way to proceed but my gut says that I could spend a week trying to 
create it and still not succeed.

Hopefully, this additional information will be useful to someone even 
if the PHP team chooses not to address the problem.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 03:01:30 2024 UTC