Повторяющиеся ошибки 502, 504, несмотря на низкий уровень ЦП и использование памяти
Я уже давно борюсь с этой проблемой. У меня есть экземпляр t2.site на AWS, на котором размещен личный веб-сайт с очень низким трафиком, созданный с помощью wordpress, ничего особенного. Я сначала использовал Apache2, и после нескольких месяцев безупречной работы я внезапно начал получать ошибки 502, 504. В то время я решил перейти на Nginx / php5-fpm, какое-то время дела шли хорошо: ошибок 502, 504. И со вчерашнего дня все повторилось, я заметил, что если я перезапущу php5-fpm или mysql, сайт снова станет доступен, но только в течение 5-10 минут, прежде чем снова выдаст ошибку 502 или 504.
Я следил за несколькими потоками. с подобными проблемами ничего толком не работало, поэтому я сдаюсь и прошу помощи здесь. Я несколько раз менял конфигурацию nginx и php5-fpm без каких-либо долговременных изменений. Я вижу в htop, что существует много процессов mysql, и начинаю подозревать, что что-то (wordpress или?) Создает кучу ненужных подключений к mysql, но я не знаю, как исследовать дальше. После проверки журнала php5-fpm я обнаружил следующее:
My /var/log/upstart/php5-fpm.log
[16-Sep-2016 00:05:02] NOTICE: fpm is running, pid 32006
[16-Sep-2016 00:05:02] NOTICE: ready to handle connections
[16-Sep-2016 00:05:02] NOTICE: systemd monitor interval set to 10000ms
[16-Sep-2016 00:05:07] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[16-Sep-2016 01:03:39] NOTICE: Terminating ...
[16-Sep-2016 01:03:39] NOTICE: exiting, bye-bye!
[16-Sep-2016 01:03:39] NOTICE: fpm is running, pid 32699
[16-Sep-2016 01:03:39] NOTICE: ready to handle connections
[16-Sep-2016 01:03:39] NOTICE: systemd monitor interval set to 10000ms
[16-Sep-2016 01:03:43] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
Итак, я обновил конфигурацию php5-fpm для следующих параметров: В настоящее время я изменяю конфигурацию php5-fpm, особенно увеличивая значение pm.max_children:
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
Через несколько секунд сайт работает лучше, но я сомневаюсь, что это долгосрочное решение проблемы.
РЕДАКТИРОВАТЬ 2:
После долгого исследования mysql.log (все запросы) и доступа я обнаружил, что подвергся атаке грубой силы. Вы можете найти информацию об этой атаке здесь: https://www.digitalocean.com/community/tutorials/how-to-protect-wordpress-from-xml-rpc-attacks-on-ubuntu-14-04
Журнал доступа неоднократно показывал следующее:
191.96.249.75 - - [16/Sep/2016:05:28:52 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.75 - - [16/Sep/2016:05:28:54 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.75 - - [16/Sep/2016:05:28:57 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.75 - - [16/Sep/2016:05:28:58 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.75 - - [16/Sep/2016:05:29:01 +0000] "POST /xmlrpc.php HTTP/1.0" 499 0 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
Похоже, что PHP падает. На самом деле с этим ничего не поделаешь, но Monit может помочь. Вам нужно посмотреть в PHP-журнале, не говорит ли он о том, почему он не работает - предложите отредактировать вопрос и добавить их. Возможно, память исчерпана. Проверьте все в актуальном состоянии, конечно, обновление sudo yum.
У меня точно такая же настройка t2.micro для моих сайтов, но я запускаю четыре сайта, включая один умеренно большой объем на t2.micro с задней частью RDS. У меня есть учебное пособие по настройке , включая загружаемые конфигурации. Кэширование страниц может быть действительно полезным для снижения нагрузки - единственное время, когда мой сервер работает на 2% процессора, это во время ночного резервного копирования вне сайта. Я сижу на полном процессоре 99% времени.
Обновление
Я заметил, что на выходе htop отображается не менее 20 mysqld процессов, которые занимают не менее 60% вашей памяти... Я не знаю, это отдельные экземпляры MySQL (маловероятно) или процессы/потоки, которые принимают соединения (маловероятно). Я бы посоветовал в первую очередь уменьшить это число до меньшего - 5, наверное, достаточно, или, может быть, вы можете делать min/expected/max соединения - я не эксперт по MySQL.
А еще лучше, переместите ваш сервер на t2.nano или t2.micro и используйте Amazon RDS. RDS находится на бесплатном уровне в течение года, после чего он составляет около $10 в месяц и означает, что вам не придется запускать базу данных самостоятельно. Веб-сервер t2.micro и сервер t2.micro RDS будут стоить примерно столько же, сколько и малый экземпляр t2.small, выполняющий и то, и другое.
У меня больше веб-сайтов, чем у вас, и я уверен, что могу запускать веб и базы данных на одном сервере без проблем. Вам просто нужно убедиться, что вы не переходите через доступную оперативную память. Это довольно просто, если у вас в основном читаемый сайт, вы просто кэшируете все страницы с Nginx-кэшированием страниц.
Мне все равно нужно посмотреть ваши PHP-журналы, чтобы убедиться, что это не работает.
Обновление2
Эти строки интересны. Первая - это просто информация, вам, вероятно, следует следовать ее советам. Вторая, завершение, примерно через час, но в ней не сказано, почему оно завершается. Интересно, можно ли включить подробный вход в систему, чтобы с этим разобраться?
[16-Sep-2016 00:05:07] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
[16-Sep-2016 01:03:39] NOTICE: Terminating ...
Вы также можете проверить CloudWatch. Убедитесь, что вы настроили пользовательскую метрику "памяти в использовании". Пусть она будет работать до тех пор, пока не возникнет проблема, а затем посмотрите на значение MAX для потребляемой памяти. Если у Вас заканчивается память, это может показать, но может быть недостаточно гранулярно. Моя теория, которая, честно говоря, наверное, неверна, заключается в том, что процесс не может выделить достаточно памяти и из-за этого закрывается. Хотя, возможно, это и не та проблема, которую стоит исключить.
Рассмотрим возможность сокращения использования оперативной памяти MySQL, как я уже говорил ранее.
.