Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53167
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 58246 invoked from network); 7 Jun 2011 17:49:22 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 7 Jun 2011 17:49:22 -0000
Authentication-Results: pb1.pair.com header.from=mike.vanriel@naenius.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=mike.vanriel@naenius.com; spf=pass; 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:48027] helo=linux35.webawere.nl)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 7F/71-50253-1A46EED4 for <internals@lists.php.net>; Tue, 07 Jun 2011 13:49:22 -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 1QU0Ox-0000vP-ED; Tue, 07 Jun 2011 19:49:15 +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: <1307468695.2671.7.camel@chronos>
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>
	 <1307468695.2671.7.camel@chronos>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 07 Jun 2011 19:49:08 +0200
Message-ID: <1307468948.2671.9.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)

Before I forget; without gc_collect_cycles I get the following output
using memory_get_usage instead of memory_get_peak_usage:

    int(634640)
    int(635392)

Mike

On Tue, 2011-06-07 at 19:44 +0200, Mike van Riel wrote:
> I have ran the script that you provided and got the following results:
>=20
>     int(635192)
>     int(635944)
>=20
> Which is far less than the peak memory result.
>=20
> 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).
>=20
> Is my assertion about the meaning of memory_get_peak_usage incorrect?
>=20
> Mike =20
>=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 ac=
curate results anymore when looking at memory usage.
> >=20
> > If the above gives the same numbers you got initially, then there's a m=
emleak 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 mem=
ory.
> > >=20
> > > FYI: When I change the argument of memory_get_peak_usage to 'true', I=
 get the following results:
> > >=20
> > >    int(262144)
> > >    int(262144)
> > >=20
> > > This amount is astoundingly less than the previous conclusions and le=
ss 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 ca=
lculations?
> > >=20
> > > I assume it is a good thing to at least try to create an easy way to =
reproduce the issue (cannot include my test file) and create a bug report a=
bout 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
>=20