Настройка Nginx + PHP-FPM для высокой нагрузки трафика
Мой nginx продолжает вылетать и сообщать об ошибках "плохой шлюз" в браузере. Nginx и PHP-FPM заранее не настроены для обработки больших нагрузок трафика. Мне пришлось каждый час запускать cron systemctl restart php7.0-fpm задание cron, чтобы убедиться, что мои сайты не работают. t оставаться внизу слишком долго, когда они уходят. Давайте просто приступим к делу.
Некоторые ошибки я получаю из /var/log/php7.0-fpm.log :
[20-Sep-2017 12:08:21] NOTICE: [pool web3] child 3495 started
[20-Sep-2017 12:08:21] NOTICE: [pool web3] child 2642 exited with code 0 after 499.814492 seconds from start
[20-Sep-2017 12:32:28] WARNING: [pool web3] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 7 idle, and 57 total children
В журнале nginx мне ничего не выскакивает. Если я оставлю его работать слишком долго без перезапуска (PHP-FPM), я получу ошибки шлюза. Я пробовал следовать руководствам 3 раза, теперь настраивая настройки, но это все еще не работает. Прямо сейчас у меня есть всевозможные настройки, вероятно, далеко, но они никогда не работают, как я это делаю.
/etc/nginx/nginx.conf :
user www-data;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 100000;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
http {
sendfile on;
reset_timedout_connection on;
client_body_timeout 10;
send_timeout 2;
keepalive_timeout 30;
keepalive_requests 100000;
tcp_nopush on;
tcp_nodelay on;
types_hash_max_size 2048;
fastcgi_read_timeout 300000;
client_max_body_size 9000m;
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
access_log off;
}
/etc/php/7.0/fpm/ php-fpm.conf :
[www]
pm = dynamic
pm.max_spare_servers = 200
pm.min_spare_servers = 100
pm.start_servers = 100
pm.max_children = 300
[global]
pid = /run/php/php7.0-fpm.pid
error_log = /var/log/php7.0-fpm.log
include=/etc/php/7.0/fpm/pool.d/*.conf
/etc/php/7.0/fpm/pool.d/www.conf :
[www]
user = www-data
group = www-data
listen = /run/php/php7.0-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 300
pm.start_servers = 100
pm.min_spare_servers = 100
pm.max_spare_servers = 200
pm.max_requests = 500
Один из моих сайтов ( /etc/php/7.0/ fpm / pool.d / web3.conf ):
[web3]
listen = /var/lib/php7.0-fpm/web3.sock
listen.owner = web3
listen.group = www-data
listen.mode = 0660
user = web3
group = client1
pm = dynamic
pm.max_children = 141
pm.start_servers = 20
pm.min_spare_servers = 20
pm.max_spare_servers = 35
pm.max_requests = 500
chdir = /
env[HOSTNAME] = $HOSTNAME
env[TMP] = /var/www/clients/client1/web3/tmp
env[TMPDIR] = /var/www/clients/client1/web3/tmp
env[TEMP] = /var/www/clients/client1/web3/tmp
env[PATH] = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Использование ресурса / proc с htop:
Проблема связана с доступом к вашей базе данных. У вас есть несколько процессов MySQL, использующих ЦП, что указывает на то, что выполнение запросов к базе данных занимает много времени.
Вам нужно заглянуть в свое приложение и найти следующие вещи:
- Запросы к базе данных оптимизированы должным образом.
- Дизайн базы данных является эффективная и правильная индексация.
- Приложение имеет надлежащие кеши данных.
Медленные запросы к базе данных затем заставляют PHP-FPM запускать доступные дочерние процессы, которые обрабатывают запросы клиентов. Это вызовет ошибку 502 Bad Gateway . Вы можете попробовать увеличить настройку pm.max_children для пула web3 , поскольку это вызывает ошибки. Это может устранить симптомы масштабируемости, но не устраняет основную причину, которая заключается в неэффективности приложения / базы данных.
Если вы не используете пул www , вы можете удалить его, чтобы сэкономить ресурсы, которые он использует.
12156] Идеальная настройка для pm.max_requests - ноль, то есть рабочие процессы PHP никогда не должны перезапускаться. Если ваши PHP-воркеры не пропускают память из-за плохого кодирования библиотек, тогда вы можете использовать ноль. В противном случае вы можете использовать любое значение, которое обеспечивает приличное использование памяти рабочими. Других хороших советов относительно этой настройки действительно нет.
Здесь мало что можно сделать с настройками nginx, так как это PHP-FPM, который иногда недоступен.Вы можете изменить gzip_comp_level на 1 , что заставит nginx тратить немного меньше ресурсов ЦП на сжатие вывода. Но это действительно небольшой эффект по сравнению с оптимизацией приложений.
(это должен быть комментарий, но он немного длинный)
мои сайты продолжают давать сбой
.... это не проблема емкости, если только ваш сервер не настроен настолько плохо, что Убийца oom начинает действовать. И это не та ошибка, которую вы цитировали из своих журналов.
Почему у вас есть полгигаба подкачки на коробке с 12 гигабайтами RAM?
У вас слишком высокий keepalive.
Вы отключили ведение журнала доступа (ваши журналы место, где можно начать поиск проблем с емкостью).
Верхний вывод указывает на проблемы с производительностью mysql.
Ваш pm.max_requests слишком низкий.
Вы не закрыли список listen_backlog.
Все, что вы нам здесь показали, имеет проблемы, и это лишь верхушка айсберга. Голосование за закрытие
По моему опыту, особенно с большим сайтом, php-fpm использует много мощности процессора. это происходит, если нет доступного кеша, и он должен ждать, пока ваша страница загрузится и отобразится локально, а затем кэшировать ее, а затем сервер кеша. У меня раньше были те же проблемы с большими сайтами. Лучше всего использовать httrack для сканирования вашего сайта, установить ограничения скорости в httrack, чтобы не перегружать ваш сервер. Это создаст ваш кеш nginx, а после его создания вы увидите мгновенную загрузку страниц и очень небольшое использование процессора или оперативной памяти. Основная причина действительно связана с отрисовкой страницы, которая может быть вызвана большим количеством JS или CSS или, скорее всего, большим количеством запросов SQL или плохо настроенной базой данных sql. обязательно индексируйте часто используемые таблицы базы данных.
Не работает ли сайт web3? Эта запись журнала, кажется, указывает на причину:
[20-Sep-2017 12:32:28] WARNING: [pool web3] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers)
У вас действительно высокие значения для start_servers / max_spare_servers для сайта www, но гораздо более низкие значения для web3.
Кажется, вам не хватает памяти, поэтому добавление mysql может помочь. Если ваше приложение php никогда не запрашивает mysql, исключение mysql из процесса оптимизации является ошибкой.
Для начала вам нужно взглянуть на вашу конфигурацию mysql. Я считаю, что большинство дистрибутивов довольно консервативны в настройке памяти и количестве потоков. Найдите примеры конфигураций mysql, например: my-large.cnf my-medium.cnf и сравните их с вашими. В дистрибутивах на основе Debian они находятся в /usr/share/doc/mysql-server-x.y/examples/ (где x.y - основная версия)
При настройке различных ручек я бы порекомендовал небольшие изменения. Например, измените значение с 8M на 16M.
Если это ваше приложение php, вы также захотите посмотреть журнал медленных запросов, как это было предложено в ответе Теро Килканена.
Надеюсь, что это поможет.
htop, похоже, указывает, что каждый из 15 PID, связанных с MySQL, использовал ВРЕМЯ более 1: nn.nn, и у каждого из них используется не менее 1 ГБ ОЗУ VIRT. Поскольку в общей сложности у вас 12 ГБ ОЗУ, не пора ли вам поделиться с нами своим
SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;
SHOW ENGINE INNODB STATUS;
, чтобы можно было провести разумные проверки конфигурации MySQL, даже если это не проблема? Время безотказной работы в 1 день, 11 часов обнадеживает.
Есть идеи, что делал PID 6148, для которого ВРЕМЯ 28: + вложено в усилия?
Из предыдущего сегодняшнего ответа @xendi ....
«Когда это происходит, все страницы на всех сайтах, независимо от того, какие скрипты или контент, выдают ошибку с ошибкой шлюза. Это происходит со всеми страницами и сайтами»
Вы смотрели на php.ini session.gc_maxlifetime = nnnn в секундах сборки мусора как на возможную причину?
24.09.2017 вопросы о nginx.conf, которые могут повлиять
client_max_body_size 9000m; # really 9G in one body?
client_body_timeout 10; # seconds to receive the client body seems short.
open_file_cache max=200000 inactive=20s; may be causing churn at 20s
https://www.linode.com/docs/web-servers/nginx/configure-nginx-for-optimized-performance/
, возможно, полезная ссылка.