Утечка сокета PHP FPM 7.1 приводит к превышению времени ожидания шлюза NGINX — 504

я использую Laravel Forge для раскрутки моей среды EC2, что делает стеки LEMP для меня. Недавно я начал получать 504 тайм-аута на запросы.

Я не являюсь системным администратором (следовательно, подписка на Forge), но я просмотрел журналы и сузил проблему до этих 2 повторяющихся записей в моих журналах:

в: /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"

в: /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

Кажется, что fpm открывает соединения, которые никогда не умирают, и из моих журналов загрузки RDS я вижу, что ОЗУ постоянно исчерпано.

Я пробовал:

  • Откат к определенной стабильной версии моего приложения (2 месяца назад)
  • Переустановка мой EC2 с 5,6, 7,0 и 7,1 (с соответствующими fpm)
  • Делать все вышеперечисленное 14.04 и 16.04
  • Создание большего RDS

На данный момент единственное, что работает, это мощная RDS (8 ГБ ОЗУ) + уничтожение пула соединений fpm через каждые 300 запросов. Но очевидно, что использование ресурсов для этой проблемы не является решением.

Вот мой конфиг для /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

А вот мой конфиг для 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";
}

2

Решение

Хорошо, после МНОГО отладки и тестирования я заметил эти несколько причин.

  • Основная причина для меня: Экземпляр AWS RDS, который я использовал для своего MySQL было 500 МБ памяти. Оглядываясь назад, все эти проблемы начались, когда размер БД превысил 400 МБ.

    • Решение: Убедитесь, что у вас всегда есть 2x RAM вашего размера БД. В противном случае все дерево B + не помещается в памяти, поэтому он должен делать постоянные перестановки. Это может занять более 15 секунд.
  • Основная причина таких проблем: Не оптимизированные SQL-запросы.

    • Решение: На вашем локальном хосте храните данные, аналогичные размеру ваших данных на сервере.
0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]