Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

Three modes of process management

To conclude, there are three modes of process management for phP-fPM:

  1. ondemand

  2. static

  3. dynamic

This conclusion is drawn from the php-FPM configuration file, in which we can see the following:


; Choose how the process manager will control the number of child processes.

; Possible Values:

; static - a fixed number (pm.max_children) of child processes;

; dynamic - the number of child processes are set dynamically based on the

; following directives. With this process management, there will be

; always at least 1 children.

; pm.max_children - the maximum number of children that can

; be alive at the same time.

; pm.start_servers - the number of children created on startup.

; pm.min_spare_servers - the minimum number of children in 'idle'

; state (waiting to process). If the number

; of 'idle' processes is less than this

; number then some children will be created.

; pm.max_spare_servers - the maximum number of children in 'idle'

; state (waiting to process). If the number

; of 'idle' processes is greater than this

; number then some children will be killed.

; ondemand - no children are created at startup. Children will be forked when

; new requests will connect. The following parameter are used:

; pm.max_children - the maximum number of children that

; can be alive at the same time.

; pm.process_idle_timeout - The number of seconds after which

; an idle process will be killed.

; Note: This value is mandatory.

pm = dynamic

Copy the code

Configuration File Interpretation

From the above configuration file, we know that the PM parameter is responsible for the management mode of the process. There are three possible options: ondemand, static, and Dynamic. The value must be set.

  • Static: a fixed number of child processes (controlled by the pm.max_children argument);

  • Dynamic: The number of child processes is set dynamically according to the following instructions, but in this process management mode, there is at least one child process.

  • Pm. max_children: maximum number of worker child processes alive at the same time;

  • Pm.start_servers: Number of worker child processes created at startup;

  • Pm.min_spare_servers: Minimum number of idle worker child processes. If the idle worker child is smaller than this value, a number of child processes will be created until the value is reached.

  • Pm.max_spare_servers: Maximum number of idle worker child processes. If the idle worker child is larger than this value, some of the child processes will be killed until the value is reached.

  • Ondemand: No worker child processes are created at startup. New child processes are only forked when a new connection comes in (note: this trigger condition is the arrival of the connection, not the actual request. For example, a worker process will be created if only a connection is made, such as Telnet, and no request data is sent. The following two parameters are used in this mode:

  • Pm. max_children: maximum number of worker child processes alive at the same time;

  • Pm.process_idle_timeout: How long before an idle child process is killed.

Other parameters are set as follows:

  • Pm. max_children: When PM is set to static, indicates the number of worker processes that can be created. When PM is set to Dynamic or ondemand, indicates the maximum number of worker processes that can be created.

  • Pm.start_servers: Sets the number of worker child processes created at startup, only used when PM is set to Dynamic.

  • Pm.min_spare_servers: Sets the minimum number of idle worker processes. This is only used when PM is set to dynamic.

  • Pm. max_spare_servers: Sets the maximum number of idle worker processes. This is only used when PM is set to dynamic.

  • Pm.process_idle_timeout: How long to end idle worker processes. This parameter is used only when PM is set to ondemand.

Advantages and disadvantages and limitations

ondemand

advantages

  1. Create according to traffic requirements, do not waste the source of the system

disadvantages

  1. Since phP-FPM is a short connection, each request will be established first. The process of establishing a connection will cost the system resources. When there is a lot of traffic, the frequent creation and destruction process is expensive and is not suitable for deployment in a heavy traffic environment.

Limiting conditions

  1. The number of worker processes is limitedpm.max_childrenConfiguration, also limited to global configurationprocess.max(To be precise, all three modes are limited by global configuration.)

static

advantages

  1. Simple method;

  2. Avoid the overhead of frequently opening and closing processes;

disadvantages

  1. If set to static, you only need to consider the number of max_children, which depends on the number of cpus and the response time of the application. Starting fixed-size processes at once wastes system resources.

Limiting conditions

  1. The number of worker processes is limited by the global configurationprocess.max(To be precise, all three modes are limited by global configuration.)

dynamic

advantages

  1. Dynamic capacity expansion saves system resources.

disadvantages

  1. When all worker processes are working, new requests need to wait for the creation of worker process, the longest waiting time is 1s (there is an internal timer of 1s to check and create the process).

  2. Processes are frequently started and stopped, consuming system resources (When the number of requests is stable, frequent destruction is not required).

Limiting conditions

  1. The number of worker processes is limitedpm.max_childrenConfiguration, also limited to global configurationprocess.max(To be precise, all three modes are limited by global configuration.)

Other related parameters are described

pm.max_requests

; The number of requests each child process should execute before respawning. ; This can be useful to work around memory leaks in 3rd party libraries. For ; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS. ; Default Value: 0 ; pm.max_requests = 500Copy the code

This parameter indicates how many requests a worker child process has to process before terminating. The master process will create a new worker process.

The main purpose of this configuration is to avoid memory leaks caused by the PHP interpreter or third-party libraries referenced by the program.

pm.status_path


; The URI to view the FPM status page. If this value is not set, no URI will be

; recognized as a status page. It shows the following informations:

; pool - the name of the pool;

; process manager - static, dynamic or ondemand;

; start time - the date and time FPM has started;

; start since - number of seconds since FPM has started;

; accepted conn - the number of request accepted by the pool;

; listen queue - the number of request in the queue of pending

; connections (see backlog in listen(2));

; max listen queue - the maximum number of requests in the queue

; of pending connections since FPM has started;

; listen queue len - the size of the socket queue of pending connections;

; idle processes - the number of idle processes;

; active processes - the number of active processes;

; total processes - the number of idle + active processes;

; max active processes - the maximum number of active processes since FPM

; has started;

; max children reached - number of times, the process limit has been reached,

; when pm tries to start more children (works only for

; pm 'dynamic' and 'ondemand');

; Value are updated in real time.

; Example output:

; pool: www

; process manager: static

; start time: 01/Jul/2011:17:53:49 +0200

; start since: 62636

; accepted conn: 190460

; listen queue: 0

; max listen queue: 1

; listen queue len: 42

; idle processes: 4

; active processes: 11

; total processes: 15

; max active processes: 12

; max children reached: 0

Copy the code
; pm.status_path = /statusCopy the code

We can obtain the FPM process pool status by accessing the /status interface. There are a few relational fields to note:

  • Pool: indicates the name of the FPM process pool, most of which are WWW. The Master process can manage multiple pools. Each pool can be configured in any of the three modes. That is, the Master process supports multiple process management modes at the same time.

  • Listen Queue: request waiting queue. If the value is not 0, increase the number of FPM processes.

  • Max children reached: the number of times that the maximum number of processes has been reached, if this number is not 0, then your maximum number of processes is too small, please change it to larger.

Example of production environment configuration

[pool_name1] pid = /home/service/php/var/run/xxx.pid error_log = /home/service/php/log/xxx.log syslog.facility = daemon syslog.ident = php-fpm log_level = warning emergency_restart_threshold = 100 emergency_restart_interval = 30m process_control_timeout = 1m daemonize = yes rlimit_files = 65535 ; Rlimit_core = 0 rlimit_core = unlimited events.mechanism = epoll [pool_name2] user = work group = Work listen = Listening port access.log=/home/work/logs/xxx.log pm = ondemand pm.max_children = 750 pm.process_idle_timeout = 10s pm.max_requests = 500 pm.status_path = /status ping.path = /ping ping.response = pong catch_workers_output = yes security.limit_extensions  = .php request_slowlog_timeout = 1s request_terminate_timeout = 10s slowlog = /home/service/php/log/xxx php_flag[display_errors] = off php_admin_value[error_log] = /home/work/logs/xxx php_admin_flag[log_errors] = on php_admin_value[memory_limit] = 512MCopy the code

Practices demonstrate

Ondemand presentation

When PM = ondemand, restart php-fpm and check FPM:


# ps -ef | grep fpm

root 32636 1 0 11:41 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

root 32653 32636 0 11:42 pts/0 00:00:00 grep fpm

Copy the code

As you can see, there is no worker process.

When we execute the request, we see an additional worker child process.


# ps -ef | grep fpm

root 32636 1 0 11:41 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 33146 32636 15 11:48 ? 00:00:00 php-fpm: pool www

root 33151 32584 0 11:48 pts/0 00:00:00 grep fpm

Copy the code

After a period of time, we checked again and found that the worker process had disappeared, which was consistent with the above content.


# ps -ef | grep fpm

root 32636 1 0 11:41 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

root 33208 32636 0 11:52 pts/0 00:00:00 grep fpm

Copy the code

What if we kill the master process? So let’s try it out.

After kill -9, Nginx prompts “502”, indicating that the service is unavailable.

The static demo

When we change to the following configuration:


pm = static

pm.max_children = 2

pm.max_requests = 5

Copy the code

[root@yz-dev-inf00 ~]# ps -ef | grep fpm

root 34467 1 0 12:08 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 34468 34467 0 12:08 ? 00:00:00 php-fpm: pool www

work 34469 34467 0 12:08 ? 00:00:00 php-fpm: pool www

root 34473 32584 0 12:08 pts/0 00:00:00 grep fpm

Copy the code

We can see that two worker processes are started. The request can be made normally. What happens if we kill the worker process?


# kill 34468

# ps -ef | grep fpm

root 34467 1 0 12:08 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 34469 34467 0 12:08 ? 00:00:00 php-fpm: pool www

work 34501 34467 0 12:10 ? 00:00:00 php-fpm: pool www

root 34503 32584 0 12:10 pts/0 00:00:00 grep fpm

Copy the code

You can see that a new worker process has been started.

What about our kill -9 main process?


# kill -9 34523

# ps -ef | grep fpm

work 34524 1 0 12:12 ? 00:00:00 php-fpm: pool www

work 34525 1 0 12:12 ? 00:00:00 php-fpm: pool www

root 34540 32584 0 12:13 pts/0 00:00:00 grep fpm

Copy the code

As you can see, the child process is still there and still requests normally. At this point, the two worker processes are orphaned and adopted by the pid = 1 process, but the entire PHP-FPM can continue to serve

Due to our Pm.max_requests = 5, there is only one worker process left after 5 requests. Then we kill the last worker process, and the normal request cannot be made.

Dynamitc demo


pm =dynamic

pm.min_spare_servers=1

pm.max_spare_servers=2

Copy the code

Now let’s look at the FPM process:


# ps -ef | grep fpm

root 35056 1 0 12:20 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 35057 35056 0 12:20 ? 00:00:00 php-fpm: pool www

root 35059 32584 0 12:20 pts/0 00:00:00 grep fpm

Copy the code

Run the kill -9 worker command to restart another worker process.


# kill -9 35057

# ps -ef | grep fpm

root 35056 1 0 12:20 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 35072 35056 0 12:21 ? 00:00:00 php-fpm: pool www

root 35074 32584 0 12:21 pts/0 00:00:00 grep fpm

Copy the code

What about our kill -9 main process?


# ps -ef | grep fpm

root 35056 1 0 12:20 ? 00:00:00 php-fpm: master process (/home/service/php/etc/php-fpm.conf)

work 35072 35056 0 12:21 ? 00:00:00 php-fpm: pool www

root 38428 38406 0 13:41 pts/1 00:00:00 grep fpm

# kill -9 35056

# ps -ef | grep fpm

work 35072 1 0 12:21 ? 00:00:00 php-fpm: pool www

root 38434 38406 0 13:41 pts/1 00:00:00 grep fpm

Copy the code

Again, the worker process becomes an orphan process, adopted by the pid=1 process, but still able to provide services.

conclusion

  1. What are the three modes of phP-FPM process management?

  2. Ondemand: starts ondemand

  3. Static: the number is fixed

  4. Dynamic: indicates the dynamic quantity

  5. How does php-fpm create worker processes?

  6. Ondemand:

  7. Worker processes are not created at startup and can be created when needed. At most, pm.max_children subprocesses exist at the same time.

  8. Static:

  9. Create the pm.max_children child process on startup. When a worker process shuts down, re-create the worker process to make the total number of worker processes pm.max_children.

  10. Dynamic:

  11. Dynamic mode, with at least one worker process;

  12. Start pm. start_Servers up to pM. max_children.

  13. If the child processes are idle and the number is less than Pm.min_spare_Servers, the child processes are filled to Pm.min_spare_Servers, and if the child processes are larger than Pm.max_spare_Servers, the child processes are reduced to Pm.max_spare_Servers.

  14. How to check phP-FPM process status?

  • Configure it in the php-fpm.conf filepm.status_path = /statusTo view the FPM status.

  1. Does the worker process or master process requests in phP-FPM? Can the master process still receive requests after being killed?

  2. It is the worker process that receives requests, and the master process is responsible for managing the worker process.

  3. After the master process is killed by -9, the worker process still exists and can process requests. If the worker process does not exist, error 502 is reported.

  4. After the master process is killed, the worker child process is also killed and cannot provide services.

  5. See the difference between kill and kill-9.

  6. What does the Pm.max_requests parameter do?

  • In order to prevent memory leaks caused by third-party libraries referenced by the PHP interpreter or program, when the number of requests processed by the worker process reachespm.max_requestsThen, the process is killed.

Reference documentation

  • Php-fpm Interpretation – Three modes of process management