I too have experienced this problem and can reproduce, I just changed to
the cgi version instead to eliminate the problem, which I would agree,
it is. I have one page on a site of hundreds of pages that produces the
large process, 30MB+ and this is on a heavily used server with more than
300 processes. So if I don't run the cgi-version the server will crash
in a matter of time as the memory is not freed and eventually will swap
itself to death. So while the cgi-version is slightly slower, I have
reliability.
John Hamlik
-----Original Message-----
From: Brian Moon [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 3:20 PM
To: [EMAIL PROTECTED]; Andi Gutmans
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
But the reverse side of this is that I might have one script out of 1000
that needs that much memory. But since 20 of my httpd processes have
run
that script, they all have that much memory and are not going to let it
go
no matter what.
I basically sounds like a flaw that memory can not be freed. Reuse in
the
same process is not free memory, it is reused memory. And it sounds
like
there is nothing that the PHP team can do about it.
Brian Moon
------------------------------------------------------------------------
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
------------------------------------------------------------------------
-
Look for my presentation at ApacheCon 2001.
"Caching Dynamic Web Content to Increase Dependability and Performance"
http://www.apachecon.com/
----- Original Message -----
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 5:02 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
> >This is the answer I had previously received. IMHO, this sucks. We
don't
> >do SQL queries on our production site. It is all cached. So, SQL is
not
> >the problem. It is most likely because of the storage of large
arrays or
> >something of that nature.
>
> Well maybe you should try and see what in your script is taking up
lots of
> memory.
>
>
> >I guess we will continue to use MaxRequestsPerChild until one day the
people
> >that wrote that memory allocation system get a clue.
>
> They are very clue full. A program which uses X MB of memory is very
likely
> to use X MB of memory again at a later time. For example, how does it
help
> you if your 14 MB were shrunk back to 10 MB on each request. The next
> request would probably make it grow back to 14 MB.
> There might be some memory management libraries that shrink the memory
back
> but I doubt you can gain much from it especially as memory
fragmentation
> can severally limit the amount of memory you can reclaim and because
of
the
> point I made before, it's probably just not worth it.
>
> If you can find a case where you really think PHP is using much too
much
> memory let me know and we can try and check together if there's a way
to
> improve the situation.
> Andi
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
