Memory leak refers to the phenomenon that memory is applied for during the running of the program, but is not released in time after the use is completed. For ordinary programs with short running time, the problem may not be so obvious, but for long-running programs This is more obvious for programs such as web servers, background processes, etc. As the system runs, the memory occupied will continue to rise, and may crash due to excessive memory usage, or be killed by the system (OOM).

Memory leaks in PHP

PHP is a high-level language. There is no concept of memory at the language level. There is no need to actively apply for or release memory during use, so at the PHP user code level it is There is no concept of memory leak anymore.

If your PHP program has a memory leak, or large variables are not released in time, then there is a problem with the implementation of the third-party extension itself.

Memory leak caused by PHP-FPM

Here is a brief introduction to the working principle of nginx+php-fpm mode:

1. The nginx server forks out n child processes (workers), and the php-fpm manager forks out n child processes.

2. When there is a user request, a worker of nginx receives the request and throws the request into the socket.

3. php-fpm The idle sub-process listens to requests in the socket, receives and processes the requests.

Here we should focus on the third step. The third step involves the php-fpm process life cycle. The life cycle of a php-fpm is roughly like this: module initialization (MINIT) -> module activation (RINIT) -> request processing -> module deactivation (RSHUTDOWN) -> module activation (RINIT) -> Request processing -> Module deactivation (RSHUTDOWN)...... Module activation (RINIT) -> Request processing -> Module deactivation (RSHUTDOWN) -> Module shutdown (MSHUTDOWN). In the life cycle of a php-fpm process, there will be multiple module activation (RINIT) -> request processing -> module deactivation (RSHUTDOWN) processes. The general process of this "request processing" is as follows: PHP reads the corresponding PHP file, performs lexical analysis on it, generates opcode, and the zend virtual machine executes the opcode.

The memory_limit in the PHP configuration file actually limits only the memory of this "request processing". Therefore, this parameter has nothing to do with the memory occupied by the php-fpm process.

So, is there any way to prevent this problem?
There is a parameter pm.max_requests in php-fpm.conf, which is equivalent to PHP_FCGI_MAX_REQUESTS. This value means how many requests an fpm process handles before it is automatically killed and a new process is started.

Memory leak debugging and tools

Memory leaking programs are usually easy to find, because the symptoms are manifested as continuous growth of memory usage. After discovering that memory continues to grow, we need to determine what is causing it. If a memory leak occurs, you often need to use some tools to help trace it. We can use two tools: PHP built-in memory leak detection and valgrind memory leak analysis.

Related recommendations:

Example sharing of JavaScript memory leak handling methods

##PHP kernel-picture of memory leak and new garbage collection mechanism Article introduction

What is a memory leak and the causes and prevention methods of memory leaks

The above is the detailed content of Detailed explanation of PHP memory leak. For more information, please follow other related articles on the PHP Chinese website!