On Sat, 27 Jan 2001, Rasmus Lerdorf wrote:
> > It is not a leak exactly but more of a greed. It seems to be a
> > semi-intentional but not necessary thing. It seems that the way Zend/PHP is
> > allocating memory is not allowing it to be returned to the system. Once PHP
> > has some memory it will not let it go, but it will reuse it. So, if a
> > script takes up a good chunk of memory, it is never returned to the system
> > unless that httpd process is killed or dies.
>
> Right, this is standard. But this does not explain incremental memory
I have not said anything about _incremental_ memory usage. I try to
put your attention to that _standard_ problem.
> usage. Memory is marked as free and re-used. It does not need to be
> returned to the system for it to be re-used. So the memory usage for any
> one process should never exceed the memory usage of your most memory
> hungry script.
Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory
hungry script" happens from time to time and there's no chance to prevent
httpd processes from keeping memory (which is not used again in most
cases). Maybe it is not a problem for you, but it is for us.
And now I can say quite exactly, why this happens and how to correct this.
For exemple, see the algorithms implemented in emalloc and efree.
After many uses of emallocs (standard situation when executing script),
the cache (i simplify a little, but we can say that it works like a LIFO
queue of "freed" memory blocks) is empty. And than there comes a time for
freeing memory, which usually goes like this: last allocated block is
beeing freed first. So it goes to the cache.
Advantage: during normal execution, where emallocs and efrees are
going next to each other, this mechanism guarantees high performance
- there are only a few blocks allocated and they are reused very
frequently.
Disadvantage: we can expect such situation (cache size=1)
M1
M2
M3
M4
M5
F5 -> this goes to cache (which is empty)
F4 -> this is freed normally
F3 -> normally
F2 -> ...
F1 -> ...
At the end of execution there stays M5 block in the cache and it
prevents the memory of ALL blocks from beeing returned to the system.
The last allocated block goes ALWAYS to the cache. This is
horrible...
I know, the model is much simplified, the shown order of freeing
blocks may be different. But ...
I think, some simple solutions should be clear now.
I haven't been analising the ZEND FAST CACHE yet, but I think
the problem is similar.
--
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]
