Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53166
Return-Path: <mike.vanriel@naenius.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 54478 invoked from network); 7 Jun 2011 17:45:04 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 7 Jun 2011 17:45:04 -0000
Authentication-Results: pb1.pair.com smtp.mail=mike.vanriel@naenius.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=mike.vanriel@naenius.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain naenius.com designates 83.96.159.14 as permitted sender)
X-PHP-List-Original-Sender: mike.vanriel@naenius.com
X-Host-Fingerprint: 83.96.159.14 linux35.webawere.nl Linux 2.6
Received: from [83.96.159.14] ([83.96.159.14:42991] helo=linux35.webawere.nl)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 46/A0-50253-F936EED4 for <internals@lists.php.net>; Tue, 07 Jun 2011 13:45:03 -0400
Received: from 212-127-174-68.cable.quicknet.nl ([212.127.174.68] helo=[192.168.1.109])
	by linux35.webawere.nl with esmtpsa (TLSv1:AES256-SHA:256)
	(Exim 4.76)
	(envelope-from <mike.vanriel@naenius.com>)
	id 1QU0Kl-0000lS-Ot; Tue, 07 Jun 2011 19:44:58 +0200
To: David =?ISO-8859-1?Q?Z=FClke?= <david.zuelke@bitextender.com>
Cc: Julien Pauli <jpauli@php.net>, internals@lists.php.net
In-Reply-To: <1C32E9BA-4858-4E24-89DA-0F36DFED352B@bitextender.com>
References: <ff98f4d70b6306710582b9debdbb667f@naenius.com>
	 <73A0E06E-55E0-4C48-B8F8-BCAFA3216892@bitextender.com>
	 <f2ca38728993c1c1c581566c2dcc2b6b@naenius.com>
	 <DCF7D272-575F-4463-97BD-6EDF3B823055@bitextender.com>
	 <BANLkTikHceMABMur_Ais7A02JwjZ2Rvnmw@mail.gmail.com>
	 <33db85fd3ebaa4f330120da5fa6445e1@naenius.com>
	 <1C32E9BA-4858-4E24-89DA-0F36DFED352B@bitextender.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 07 Jun 2011 19:44:55 +0200
Message-ID: <1307468695.2671.7.camel@chronos>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: quoted-printable
X-Antivirus-Scanner: Seems clean.  You should still use an Antivirus Scanner
Subject: Re: [PHP-DEV] Trying to find out where the memory went
From: mike.vanriel@naenius.com (Mike van Riel)

I have ran the script that you provided and got the following results:

    int(635192)
    int(635944)

Which is far less than the peak memory result.

I use memory_get_peak_usage to measure what the worst case memory output
is in my application. I expect this to be the actual memory used (and
thus when the server starts swapping if this number exceeds the physical
memory).

Is my assertion about the meaning of memory_get_peak_usage incorrect?

Mike =20

On Tue, 2011-06-07 at 16:28 +0200, David Z=C3=BClke wrote:
> Please test the exact thing I suggested :)
>=20
> var_dump(memory_get_usage());
> token_get_all(file_get_contents(<FILE>));
> gc_collect_cycles();
> var_dump(memory_get_usage());
>=20
> memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accu=
rate results anymore when looking at memory usage.
>=20
> If the above gives the same numbers you got initially, then there's a mem=
leak in token_get_all().
>=20
> David
>=20
>=20
> On 06.06.2011, at 22:30, Mike van Riel wrote:
>=20
> > David and Pauli,
> >=20
> > When I change the test script to:
> >=20
> >    var_dump(memory_get_peak_usage());
> >    gc_collect_cycles();
> >    token_get_all(file_get_contents(<FILE>));
> >    gc_collect_cycles();
> >    var_dump(memory_get_peak_usage());
> >=20
> > And execute the following bash line preceding:
> >=20
> >    export USE_ZEND_ALLOC=3D0
> >=20
> > I get the following output:
> >=20
> >    int(8240)
> >    int(8240)
> >=20
> > When I remove the gc_collect_cycles I get the same result.
> > Even assigning the results to a variable do not increase the peak memor=
y.
> >=20
> > FYI: When I change the argument of memory_get_peak_usage to 'true', I g=
et the following results:
> >=20
> >    int(262144)
> >    int(262144)
> >=20
> > This amount is astoundingly less than the previous conclusions and less=
 than my own calculations would show.
> > Of course this leads me to the following questions:
> >=20
> > 1. Does it hurt to disable the Zend MM?
> > 2. Can it be done from inside a PHP Script?
> > 3. Why is the memory consumption so much lower, even lower than my calc=
ulations?
> >=20
> > I assume it is a good thing to at least try to create an easy way to re=
produce the issue (cannot include my test file) and create a bug report abo=
ut this :)
> >=20
> > Thank you for your assistance thus far.
> >=20
> > Mike
> >=20
> > On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote:
> >> Seems like leak.
> >>=20
> >> Try disabling ZendMM to see if something noticeable happens (memory
> >> peak should be lower).
> >> USE_ZEND_ALLOC=3D0
> >>=20
> >> Cheers,
> >> Julien
> >>=20
> >> On Sun, Jun 5, 2011 at 2:01 PM, David Z=C3=BClke
> >> <david.zuelke@bitextender.com> wrote:
> >>> Smells like a memory leak if gc_collect_cycles() doesn't fix it.
> >>>=20
> >>> David
> >=20
> >=20
> >=20
> > --=20
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >=20
> >=20
>=20