Nginx - PHP7 unerwarteter FastCGI-Eintrag beim Lesen des Antwortheaders vom Upstream

Question

Ich habe vor zwei Tagen auf einem Produktionsserver (CentOS 6.8) ein Upgrade auf PHP7 (PHP 7.0.14) durchgeführt. Jetzt erhalte ich folgenden Fehler in den nginx-Protokollen (1.10.2-1).

20.01.2017 08:20:04 [Fehler] 7654#7654: *153301 Upstream hat unerwarteten FastCGI-Datensatz gesendet: 3 beim Lesen des Antwortheaders von Upstream, Client: XXX.XXX.XXX.XXX, Server: example.com, Anfrage: „GET / HTTP/1.0“, Upstream: „fastcgi://unix:/var/run/php-fpm/example.fpm.sock:“, Host: „www.example.com“

1. Wir haben mehrere Websites, die alle ihren individuellen PHP-FPM-Pool ausführen, und dieser Fehler tritt auf allen Websites gleichzeitig auf.
2. Während dieses Fehlers zeigt der Browser auf allen Websites „502 Bad Gateway“ an.
3. Dieser Fehler tritt 1–2 Minuten lang auf und danach normalisiert sich alles automatisch.
4. Es passierte dreimal an einem Tag zu unterschiedlichen Zeiten.
5. Es gab kein Problem mit PHP5.
6. Ich habe versucht, alle Anwendungs-Cache-Ordner in Opcache auf die schwarze Liste zu setzen

Wir haben einen anderen Server mit ähnlichem Setup, der auf PHP7 aktualisiert wurde und derartige Probleme nicht aufweist.

Wie kann ich das Problem beheben und eine Lösung dafür finden?

AKTUALISIERUNG 1 Serverdetails
CPU: 2x Intel(R) Xeon(R) CPU E5-2620 0 @ 2,00 GHz
RAM: 256 GB
Betriebssystem: CentOS Version 6.8
Kernel: 2.6.32-504.8.1.el6.x86_64
PHP: Verwendung von 7.0.14-3 aus dem IUS-Repo
Nginx: 1.10.2-1

Der Server wird als Webserver verwendet, um mehrere Websites mit einer beliebten Open-Source-PHP-Anwendung auszuführen. Wir verwenden Nginx mit php-fpm als Backend. Jede Website verfügt über einen separaten php-fpm-Pool und verschiedene Sockets. Die PHP-Anwendung ist bereits mit php7 kompatibel und die einzige Änderung ist das Upgrade auf PHP7.

AKTUALISIERUNG 2

Nginx-Hauptkonfiguration

user  apache;
worker_processes  auto;

error_log  /var/log/nginx/error.log alert;
pid        /var/run/nginx.pid;


events {
    use epoll;
    worker_connections  4024;
    multi_accept on;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    server_names_hash_bucket_size 256;
    server_names_hash_max_size 1024;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    client_max_body_size 512M;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;

gzip  on;
gzip_http_version 1.1;
gzip_vary on;
gzip_comp_level 6;
gzip_proxied any;
gzip_min_length 1000;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/rss+xml application/atom+xml application/rdf+xmli font/ttf font/otf image/svg+xm;
gzip_buffers 16 24k;
gzip_disable msie6;

fastcgi_connect_timeout 120;
fastcgi_send_timeout 1200;
fastcgi_read_timeout 1200;
fastcgi_buffer_size 256k;
fastcgi_buffers 16 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;
keepalive_requests 10000;

    include /etc/nginx/conf.d/*.conf;
     # Load all vhosts !
    include /etc/nginx/sites-enabled/*.conf;
}

Individuelle Nginx-Site-Vorlage

server {
  server_name @@HOSTNAME@@ www.@@HOSTNAME@@;
  root "@@PATH@@";
  index  index.php index.html index.htm;
  add_header    Cache-Control  public;

  client_max_body_size 512m;

    access_log @@LOG_PATH@@/access.log;
    error_log @@LOG_PATH@@/error.log;


        location / {
                # This is cool because no php is touched for static content
                try_files $uri $uri/ $uri/index.php @rewrite /index.php$uri?$args;
        }
        location @rewrite {
                rewrite ^ /index.php;
        }

    location ~ \.php$ {
        send_timeout 1200;
        proxy_read_timeout 1200;
        proxy_connect_timeout 120;
        fastcgi_read_timeout 1200;
        fastcgi_pass    unix:@@SOCKET@@;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }



    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
            expires max;
            log_not_found off;
            access_log off;
    }

    location ~* \.(html|htm)$ {
        expires 30m;
    }

    location ~* /\.(ht|git|svn|bak) {
        deny  all;
    }

        location ~ ^/sites/.*/files/styles/ {
                try_files $uri @rewrite;
        }

}

PHP FPM-Pool-Vorlage

[@@USER@@]
listen = /var/run/php-fpm/@@USER@@.fpm.sock
listen.owner = nobody
listen.group = nobody
listen.mode = 0666
user = @@USER@@
group = @@USER@@
pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 300s
pm.max_requests = 5000
rlimit_files = 1024
request_terminate_timeout = 1200s
security.limit_extensions = .php
php_admin_value[session.save_path] = "@@HOME_DIR@@/_sessions"
php_admin_value[error_log] = "@@HOME_DIR@@/logs/www-error.log"

AKTUALISIERUNG 3 Wenn ein Problem auftritt

Anfrage 1

GET /moodle/ HTTP/1.0
User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
Host: www.example.com

Empfangener Header

502 Bad Gateway
Server: nginx/1.10.2
Date: Wed, 25 Jan 2017 12:32:00 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

Empfangener Inhalt

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.10.2</center>
</body>
</html>

Answer 1

Ok, alle PHP-FPM-Pools sind mehrere Minuten lang gleichzeitig tot, und das einzige, was sich mit PHP 5.6 geändert hat, ist => PHP 7. Was hat sich mit PHP 7 geändert? Was ist global für alle PHP-FPM-Pools? Der Opcache. Wären Sie so freundlich, Ihre php.ini bereitzustellen? Wenn nicht, überprüfen Sie bitte Ihre Opcache-Konfiguration und überprüfen Sie zumindest diese Parameter:

zend_extension=opcache.so;
opcache.enable=1;  # on or off on your config ?
opcache.memory_consumption=64; # Too small for you ?
opcache.max_accelerated_files=2000; # maybe to small for you ?
opcache.force_restart_timeout="180"; # Oh!!! This is the time of your outage!!

Ändern Sie das force_restart_timeout von 180 auf 120, ändern Sie opcache.log_verbosity_level auf etwas >=3 und prüfen Sie, ob der Ausfall kürzer als üblich ist. Dann empfehle ich Ihre ÜberprüfungOpcache-Laufzeitkonfigurationund stimmen Sie es richtig auf Ihre Site ab.

Answer 2

Es scheint, dass es sich um einen Fehler in PHP handelte, der in Version 7.0.16 vom 16. Februar 2017 behoben wurde.

Fehler behoben #67583(doppeltes fastcgi_end_request beim Max_Children-Limit).

Answer 3

Serverblock prüfen fürfastcgi_passin der Nginx-Site-Konfiguration.

Um den Fastcgi_Pass für alle Site-Konfigurationen zu aktualisieren, führen Sie Folgendes aus:

sed "s/php5/php/php7.0/g" *.conf -i

Dienst nginx und php7.0-fpm