RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
I was kinda hoping the fast-cgi version would enable the best of both worlds; however, I have been unable to get it to work under apache at this point. Any comments ? -Original 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 to build PHP for both modules and CGI, but if they are willing to do that... Works for me. Brian On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote: Couldn't one just run a cgi and module version simultaneously? Set an add type directive to pass an extension, say .cphp, to the cgi instead of the module. Then those scripts that use extensive memory could be extended with .cphp??? -Original Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 11:56 PM To: Andi Gutmans; Brian Moon; John Hamlik; [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), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: 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
RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
Do you know what is causing it to grow so much? Andi At 06:42 PM 4/30/2001 -0700, John Hamlik wrote: 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] -- 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]
RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
You can mail the author: Ben Mansell [EMAIL PROTECTED] Andi At 11:22 PM 4/30/2001 -0700, John Hamlik wrote: I was kinda hoping the fast-cgi version would enable the best of both worlds; however, I have been unable to get it to work under apache at this point. Any comments ? -Original 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 to build PHP for both modules and CGI, but if they are willing to do that... Works for me. Brian On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote: Couldn't one just run a cgi and module version simultaneously? Set an add type directive to pass an extension, say .cphp, to the cgi instead of the module. Then those scripts that use extensive memory could be extended with .cphp??? -Original Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 11:56 PM To: Andi Gutmans; Brian Moon; John Hamlik; [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), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: 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
Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
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 callable in PHP that
will cause the parent apache process to exit (if it doesn't
exist already) It will be immediately replaced by another much smaller
version ready to handle the remaining 299 web hits.
like:
// expesive memory processing
function cleanup()
{
posix_kill (posix_getpid(), 15) || posix_kill (posix_getpid(), 9);
}
register_shutdown_function(cleanup);
eventually, in a auto_apend file, if all the scripts are eating much mem.
IIRC, Posix support is compiled by default, so it looks like a nice
workarround for the memory problem...
I was wondering, could a SIGHUP to the current child make it to release
the memory? TERM is a bit harsh.
-- teodor
--
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]
Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
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: [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 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 scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory manager
holds a memory cache, but we're talking at around 1MB per process max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory
is
growing by the minute. If I start a separate server on another port and
serve only static pages and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can `gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
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 is to write your scripts in a way that if it deals with
many SQL queries free a query before you do the next. This way the maximum
size of your scripts memory space will hopefully be smaller.
Andi
At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
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: [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 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 scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory manager
holds a memory cache, but we're talking at around 1MB per process max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory
is
growing by the minute. If I start a separate server on another port and
serve only static pages and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can `gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
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.
I guess we will continue to use MaxRequestsPerChild until one day the people
that wrote that memory allocation system get a clue.
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 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 is to write your scripts in a way that if it deals with
many SQL queries free a query before you do the next. This way the maximum
size of your scripts memory space will hopefully be smaller.
Andi
At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
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: [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 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 scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes
with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory
manager
holds a memory cache, but we're talking at around 1MB per process
max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to
turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes
memory
is
growing by the minute. If I start a separate server on another port
and
serve only static pages and files through it, those process do not
grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can
`gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
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]
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]
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), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: 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] -- 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]
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 2001 23:53:16 -0400, Rod K wrote: Couldn't one just run a cgi and module version simultaneously? Set an add type directive to pass an extension, say .cphp, to the cgi instead of the module. Then those scripts that use extensive memory could be extended with .cphp??? -Original Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 11:56 PM To: Andi Gutmans; Brian Moon; John Hamlik; [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), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: 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] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
[PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which contains a hacked
up solution. It looks like it should be able to turn into a usable end solution.
Previous Comments:
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory is growing by
the minute. If I start a separate server on another port and serve only static pages
and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with anything. I know I
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.
How can I get some info for you guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
