Juraj Nemec's questions

I have PHP 5.6 and PHP 7.3 running on my machine. Webserver is Nginx and is using FastCGI (php-fpm). I have setup two php-fpm status pages - one for the www pool of the php-fpm 5.6 and one for the www pool of the php-fpm 7.3.

The status page for version 5.6 is working correctly and gives desired output:

pool:                 www
process manager:      static
start time:           29/Apr/2021:17:12:19 +0200
start since:          2870
accepted conn:        154
listen queue:         0
max listen queue:     1
listen queue len:     128
idle processes:       4
active processes:     1
total processes:      5
max active processes: 2
max children reached: 0
slow requests:        0

************************
pid:                  9209
state:                Idle
start time:           29/Apr/2021:17:12:19 +0200
start since:          2870
requests:             32
request duration:     331468
request method:       GET
request URI:          /index.php?q=test-page
content length:       0
user:                 -
script:               /data/www56/test/index.php
last request cpu:     48.27
last request memory:  26214400

************************
pid:                  9214
state:                Running
start time:           29/Apr/2021:17:12:19 +0200
start since:          2870
requests:             31
request duration:     107
request method:       GET
request URI:          /php56_status?full
content length:       0
user:                 -
script:               /data/www56/test/php56_status
last request cpu:     0.00
last request memory:  0

On the other hand, the status page for the version 7.3 has some weird behavior - request information (such as Method, URI, or script) are not displayed on Idle processes. These information are displayed only on Running processes on this php-fpm 7.3 pool:

pool:                 www
process manager:      static
start time:           29/Apr/2021:17:41:56 +0200
start since:          1062
accepted conn:        45
listen queue:         0
max listen queue:     1
listen queue len:     128
idle processes:       4
active processes:     1
total processes:      5
max active processes: 2
max children reached: 0
slow requests:        0

************************
pid:                  9003
state:                Idle
start time:           29/Apr/2021:17:41:56 +0200
start since:          1062
requests:             9
request duration:     201048
request method:       -
request URI:          -
content length:       0
user:                 -
script:               -
last request cpu:     19.90
last request memory:  4194304

************************
pid:                  9006
state:                Running
start time:           29/Apr/2021:17:41:56 +0200
start since:          1062
requests:             8
request duration:     140
request method:       GET
request URI:          /php73_status?full
content length:       0
user:                 -
script:               /data/www73/test/php73_status
last request cpu:     0.00
last request memory:  0

Nginx configuration in the same for both status pages:

#php5.6
location /php56_status {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_intercept_errors on;
        fastcgi_connect_timeout 300s;
        fastcgi_read_timeout 300s;
        fastcgi_send_timeout 300s;
        fastcgi_keep_conn on;
}

#php7.3
location /php73_status {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php7.3-fpm.sock;
        fastcgi_intercept_errors on;
        fastcgi_connect_timeout 300s;
        fastcgi_read_timeout 300s;
        fastcgi_send_timeout 300s;
        fastcgi_keep_conn on;
}

Pools configurations are the same (default www.conf) and php-fpm configurations are the same (default php-fpm.conf) on both. The fastcgi_params file content:

fastcgi_param   QUERY_STRING            $query_string;
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;

fastcgi_param   SCRIPT_FILENAME         $request_filename;
fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
fastcgi_param   REQUEST_URI             $request_uri;
fastcgi_param   DOCUMENT_URI            $document_uri;
fastcgi_param   DOCUMENT_ROOT           $document_root;
fastcgi_param   SERVER_PROTOCOL         $server_protocol;

fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
#fastcgi_param  SERVER_SOFTWARE         nginx/$nginx_version;
fastcgi_param   SERVER_SOFTWARE         nginx;

fastcgi_param   REMOTE_ADDR             $remote_addr;
fastcgi_param   REMOTE_PORT             $remote_port;
fastcgi_param   SERVER_ADDR             $server_addr;
fastcgi_param   SERVER_PORT             $server_port;
fastcgi_param   SERVER_NAME             $server_name;

fastcgi_param   HTTPS                   $https if_not_empty;

It is a little bit useless when I cannot access information about processes that ended (as it was possible in php-fpm 5.6). It is possible to display these information about Idle workers and their last script processed also in php-fpm 7.3? Or what have I wrong or missing here, that it is not working correctly?

Thank you!

We are running server with this configuration: Nginx + FastCGI (PHP-FPM) + PHP 7.3 + MySQL 5.7. However, we experience some issues with long running PHP scripts, so we have setup these restrictions:

php.ini

...
max_execution_time = 60
max_input_time = 60
...

pool.d/xxx.conf (pool config)

...
pm = dynamic
pm.max_children = 20
pm.max_requests = 500
request_terminate_timeout = 300
...

nginx virtualhost

location ~ \.php$ {
  ...
  fastcgi_connect_timeout 300s;
  fastcgi_read_timeout 300s;
  fastcgi_send_timeout 300s;
  fastcgi_keep_conn on;
  ...
}

When we check our php-fpm logs, we see that some workers are SIGKILL-ed / SIGTERM-ed, but what is important here, is the time, after which workers are killed. This time is greater than all possible timeouts set in different config files (see above). For example the script below (Apr 20 19:09:24) was timed out after 400s and killed after 428s. And the second one (Apr 20 19:05:34) was killed after 427s but processed only 1 request (according to FPM status page). So that one request has duration of 427s... But the php.ini timeout is 60s and other timeouts (nginx, php-fpm) are set to 300s, not more.

Apr 20 19:09:24 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 31032, script '/example.com/index.php' (request: "GET /index.php") execution timed out (399.965025 sec), terminating
Apr 20 19:09:24 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 31032 exited on signal 15 (SIGTERM) after 428.563463 seconds from start
...
Apr 20 19:05:34 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 30951 exited on signal 9 (SIGKILL) after 427.516062 seconds from start
Apr 20 19:05:34 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 30985 exited on signal 9 (SIGKILL) after 334.407532 seconds from start
Apr 20 19:05:34 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 30960 exited on signal 9 (SIGKILL) after 411.221728 seconds from start
Apr 20 19:05:34 srv01 php-fpm[21093]: [WARNING] [pool xxx] child 31031 exited on signal 9 (SIGKILL) after 210.926257 seconds from start

So my question is, how is this possible? Do we miss some another config directive (in nginx/php-fpm) to restrict these scripts to our desired maximum duration? Or should this issues be related with some PHP-FPM/Nginx communication problems mentioned for example here:

• https://github.com/perusio/drupal-with-nginx/issues/55 (this is related with "fastcgi_keep_conn" vs "dynamic" PHP-FPM process manager)
• https://bugs.php.net/bug.php?id=63395

It seems like that the problem is not in MySQL (all processes are idle here, when long running scripts are logged).

We are also working on application optimalization (which should eliminate these long running scripts in the future), but until then, we need to tighten up the server, as we can run the application without problems. So we would like to know what else should we try to limit these scripts to run for maximum of 300s.

Thank you for all your help!

I am running debian jessie on my server and recently upgraded to new nginx web server with http/2 support (nginx 1.10). As today, it works great and webserver is delivering content with http2 protocol.

I have read, that chrome is dropping NPN support and only allows ALPN after 15.5.2016. ALPN is extension, which requires openssl 1.0.2 installed, but on debian jessie is only openssl 1.0.1 (also on debian backports and another repositories, there is no openssl 1.0.2 version for this debian).

And there is the problem - i have upgraded from SPDY to http2 and in few days, i will have to turn off http2 and cannot use SPDY because this version of nignx have only http2. I have also read, that this version of debian will stuck with openssl 1.0.1 and only debian stretch will have openssl 1.0.2. But to release date there is almost year and chrome will be dropping support soon, so i do not want to loose the benefit of http2 protocol.

Is there any solution, how to install openssl 1.0.2 on this system, without building own build (bad maintenance) or waiting for backports repository to have it? I also don't want two versions of openssl on my system if one of them must be linked and maintained manually.

Thanks for any help.