PHP FPM 7.1 Socket Leck verursacht NGINX - 504 Gateway Timeout

Question

Ich benutze Laravel Forge zum Hochdrehen meiner EC2-Umgebungen, die ein LEMP-Stack für mich macht. Ich habe kürzlich 504 Timeouts auf Anfragen bekommen.

Ich bin kein Sysadmin (daher Abonnement Forge), aber ich sah durch die Protokolle und verengte die Frage nach unten auf diese 2 wiederholten Einträge in meinem Logs:

in: /var/log/nginx/default-error.log

2017/09/15 09:32:17 [error] 2308#2308: *1 upstream timed out (110: Connection timed out) while sending request to upstream, client: x.x.x.x, server: xxxx.com, request: "POST /upload HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock", host: "xxxx.com", referrer: "https://xxxx.com/rest/of/the/path" 

in: /var/log/php7.1-fpm-log

[15-Sep-2017 09:35:09] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 14 total children 

Es scheint, wie fpm öffnet Verbindungen, die nie, und aus meiner RDS Last logs sterben kann ich sehen, dass der RAM konstant ist ly max out.

Ich habe versucht:

• Rollback auf eine bestimmte stabile Version meiner app (2 Monate alt)
• Neuinstallieren meine EC2 mit 5.6, 7.0 und 7.1 (mit ihren jeweiligen fpm)
• Doing alle oben auf 14,04 und 16,04
• Erstellen eines größeren
RDS

Momentan funktioniert nur ein bulliger RDS (8GB RAM) + fpm alle 300 Anfragen. Aber offensichtlich ist es nicht die Lösung, auf dieses Problem Ressourcen zu werfen.

Hier ist meine Config für /etc/php/7.1/fpm/pool.d/www.conf

user = forge 
group = forge 
listen = /run/php/php7.1-fpm.sock 
listen.owner = www-data 
listen.group = www-data 
listen.mode = 0666 
pm = dynamic 
pm.max_children = 30 
pm.start_servers = 7 
pm.min_spare_servers = 6 
pm.max_spare_servers = 10 
pm.process_idle_timeout = 7s; 
pm.max_requests = 300 

Und hier ist meine Config für nginx.conf

listen 80; 
listen [::]:80; 
listen 443 ssl http2; 
listen [::]:443 ssl http2; 
server_name xxxx.com; 
root /home/forge/xxxx.com/public; 

# FORGE SSL (DO NOT REMOVE!) 
ssl_certificate /etc/nginx/ssl/xxxx.com/111111/server.crt; 
ssl_certificate_key /etc/nginx/ssl/xxxx.com/111111/server.key; 

ssl_protocols xxxx; 
ssl_ciphers ...; 
ssl_prefer_server_ciphers on; 
ssl_dhparam /etc/nginx/dhparams.pem; 

add_header X-Frame-Options "SAMEORIGIN"; 
add_header X-XSS-Protection "1; mode=block"; 
add_header X-Content-Type-Options "nosniff"; 

index index.html index.htm index.php; 

charset utf-8; 

# FORGE CONFIG (DOT NOT REMOVE!) 
include forge-conf/xxxx.com/server/*; 

location/{ 
    try_files $uri $uri/ /index.php?$query_string; 
} 

location = /favicon.ico 
location = /robots.txt 

access_log /var/log/nginx/xxxx.com-access.log; 
error_log /var/log/nginx/xxxx.com-error.log error; 

error_page 404 /index.php; 

location ~ \.php$ { 
    fastcgi_split_path_info ^(.+\.php)(/.+)$; 
    fastcgi_pass unix:/var/run/php/php7.1-fpm.sock; 
    fastcgi_index index.php; 
    fastcgi_read_timeout 60; 
    include fastcgi_params; 
} 

location ~ /\.(?!well-known).* { 
    deny all; 
} 

location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { 
    expires 30d; 
    add_header Pragma public; 
    add_header Cache-Control "public"; 
} 

Answer 1

OK, nachdem eine Menge Debuggen und Testen ich diese wenigen Ursachen bemerkt habe.

• Hauptursache für mich: Die AWS RDS-Instanz, die ich für meine MySQL wurde unter Verwendung hatte 500MB Speicher. Rückblickend begannen all diese Probleme, sobald die DB-Größe 400 MB überstieg.

  • Lösung: Stellen Sie sicher, dass jederzeit 2x RAM Ihres DB-Größe haben. Ansonsten passt der gesamte B + Baum nicht in den Speicher, also muss er ständig tauschen. Dies kann Ihre Abfragezeit von mehr als 15 Sekunden dauern.

• Hauptursache für Probleme wie diese: Nicht SQL-Abfragen optimiert.

  • Lösung: In Ihrem localhost Daten pflegen ähnlich der Größe der Daten auf dem Server.