Re: One suggestion to PHP-FPM

On 26.04.2010 19:20, looyao teng wrote: > 2. The PHP's management of memory can't give the occupied memory > back to the system by itself. This is simply not true. It does cache some blocks, but usually the memory is simply free()d. > 3.Though the idea is good,it cannot acquiret the actual state of > the memory usage of the process for PHP. Meanwhile,the other > methods are not good enough in a way,such as cannot run on > multi-platform.So we hope to try to monitor and manage the heap > memory.After all,the used memory of PHP itself is relatively > stationary.And the memory_limit is ought to limit the heap memory. > So, when it go beyond the limit,kill the process in order to release > the memory. What do you mean by "the idea"? Your initial idea? "Other methods"? Multi-platform? Yes, surely mallinfo() is not multiplatform. But it shows the real memory usage, not Zend MM stats. So what's your point? > 4. I'm agree that it's not necessary to realize this feature in > SAPI, but it may be not easy to realize in other pleaces, because > it must check after current task execute, and SAPI is not all like > FPM that is independent process existing. Erm.. Come again? > 6. I do not install memtrack, according to the README, I think it's > not my really want , the focus of my requirement is not to log or > throw exception, because I know my problem is what, I need to solve > it, and the solution is to exit. I repeat: you can add another limit to memtrack and another action. And this time it might be exit(), not warning. But after looking at your patch, I believe that this problem is NULL since the very beginning. You're checking Zend MM stats and that number is always 0 after request shutdown and before request startup, no matter what. If you have any problems with third-party libs leaking memory not accounted by Zend MM, you can always lower the max_requests parameter in your config file. That's all. Problem solved. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP