RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-05-01 Thread John Hamlik
; Brian Moon; John Hamlik; [EMAIL PROTECTED]; Rod K Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. That sounds like it would work also. People would have to build PHP for both modules and CGI, but if they are willing to do that... Works for me. Brian On Mon, 30 Apr

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-05-01 Thread Andi Gutmans
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

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-05-01 Thread Andi Gutmans
Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 9:18 PM To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]; Rod K Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. That sounds like it would work also. People would have

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-05-01 Thread teo
Hi Brian! On Mon, 30 Apr 2001, Brian Foddy wrote: Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Brian Moon
] Sent: Monday, April 30, 2001 1:45 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. 14MB of memory in use isn't necessarily that much. Some of that memory might be in shared libraries (shared across the Apache processes). Are you doing any big SQL queries in those

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Andi Gutmans
and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 1:45 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. 14MB of memory in use isn't

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Brian Moon
2:54 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. Memory is never returned to the system with libc memory allocation. When you need memory it enlarges the address space it is using. Freeing memory won't make it shrink its address space. All I can suggest

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Andi Gutmans
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.

Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Brian Moon
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

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Brian Foddy
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

RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.

2001-04-30 Thread Brian Foddy
; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc