Экземпляр EC2 автоматически становится недоступным - 504 Gateway timeout

Экземпляр EC2 автоматически становится недоступным - 504 Gateway timeout

у меня естьt3a.микроэкземпляр, на котором запущен WordPress с довольно низким трафиком. Этот экземпляр автоматически становится недоступным, что приводит к ошибке 504 Gateway timeout. В этот момент я также не могу подключиться к EC2 с помощью ssh. Это происходит в любое время дня, иногда ежедневно, а иногда вообще не происходит целую неделю. Также нет всплеска трафика, когда он выходит из строя. Я также задал этот вопрос в службу поддержки AWS и получил следующий ответ:

Проверив с моей стороны, я смог увидеть, что экземпляр несколько раз провалил проверку статуса экземпляра[1] за последние 24 часа, что указывает на то, что у экземпляра есть проблемы на уровне ОС. После дальнейшей проверки журналов консоли я смог увидеть следующую ошибку Out of Memory:

[ 5626.002561] Недостаточно памяти: завершен процесс 2050 (apache2) total-vm:552924kB, anon-rss:54868kB, file-rss:0kB, shmem-rss:32076kB, UID:33 pgtables:848kB oom_score_adj:0

[ 5674.174673] Недостаточно памяти: завершен процесс 1788 (apache2) total-vm:624936 КБ, anon-rss:51952 КБ, file-rss:0 КБ, shmem-rss:34184 КБ, UID:33 pgtables:856 ​​КБ oom_score_adj:0

[ 5763.820732] Недостаточно памяти: завершен процесс 1815 (apache2) total-vm:550384kB, anon-rss:51604kB, file-rss:0kB, shmem-rss:34532kB, UID:33 pgtables:836kB oom_score_adj:0

[ 5773.275938] Недостаточно памяти: завершен процесс 1973 (apache2) total-vm:624744kB, anon-rss:52260kB, file-rss:0kB, shmem-rss:32136kB, UID:33 pgtables:856kB oom_score_adj:0

[ 5959.347157] Недостаточно памяти: завершенный процесс 2014 (apache2) total-vm:552440 КБ, anon-rss:54020 КБ, file-rss:0 КБ, shmem-rss:28856 КБ, UID:33 pgtables:844 КБ oom_score_adj:0

[ 6438.787255] Недостаточно памяти: завершен процесс 2165 (apache2) total-vm:624756 КБ, anon-rss:51948 КБ, file-rss:0 КБ, shmem-rss:29836 КБ, UID:33 pgtables:856 ​​КБ oom_score_adj:0

Немного об OOM (Out of memory) killer, если память полностью занята процессами, в той степени, которая может угрожать стабильности системы, то OOM killer вступает в действие. Задача OOM Killer — продолжать убивать процессы до тех пор, пока не освободится достаточно памяти для бесперебойной работы остальной части процесса, которую пытается запустить ядро. Из вывода следует, что ваш экземпляр мог исчерпать память, поэтому ядро ​​Linux вызывает OOM killer.

Они предложили отслеживать использование памяти каждым процессом и убивать или исправлять этот процесс, чтобы он не использовал так много памяти. Это не выглядит как очень практичный подход, когда я работаю с WordPress, который я не могу изменить, даже если он использует слишком много памяти в течение нескольких минут.

У меня есть еще один примерt3.маленькийс использованием elastic beanstalk, который размещает веб-приложение java с окружением nginx/tomcat на amazon linux AMI, предоставленном beanstalk. Та же проблема происходит с этим экземпляром, автоматически отключается и показывает 504 Gateway timeout.

Вопрос:- Я не хочу обновлять свой экземпляр, потому что они прекрасно работают с текущим объемом трафика на них. Есть ли решение для решения этих проблем без обновления и, конечно, постоянного мониторинга процессов?

решение1

Ваши основные варианты:

  • Определите, что использует оперативную память, и настройте ее так, чтобы она использовала меньше оперативной памяти (лучший вариант)
  • Используйте экземпляр с большим объемом оперативной памяти (это может не полностью решить проблему)
  • Используйте файл подкачки как дешевый способ увеличить объем оперативной памяти. Я использую файл подкачки, чтобы быть уверенным, что есть некоторый запас для предотвращения ситуаций OOM, так что, хотя это и не решит проблему, это хорошая идея.

Я управляю пятью довольно малопосещаемыми сайтами Wordpress, MySQL и несколькими другими инструментами на t3a.nano (512 МБ ОЗУ) плюс 512 МБ подкачки.

Вот несколько способов уменьшить использование памяти типичной системой Wordpress (пришедшие мне на ум):

  • Ограничьте количество потоков PHP / рабочих. Я думаю, что я разрешаю, может быть, 2-3 потока, если один недоступен, веб-сервер будет ждать, пока он не будет доступен, что обычно не занимает много времени. Это ключевой момент, поскольку PHP / Wordpress — огромный пожиратель памяти.
  • Ограничьте максимальный объем памяти, доступный каждому потоку PHP.
  • Отключить схему производительности MySQL
  • Включите параметры MySQL, чтобы уменьшить использование памяти. По сути, вам просто нужно прочитать документацию, но я скопирую свою текущую конфигурацию ниже. Это с моего ПК с Windows, но Linux будет похож.
  • Проверьте использование памяти вашего веб-сервера. Если это Apache и он большой, то можно рассмотреть Nginx, который быстрый и небольшой.

Вам также следует выполнить поиск по запросу «LAMP (или LEMP) wordpress reduce memory use»

Вот конфигурация MySQL, которую я использую. Это моя новая конфигурация для MySQL 8.x, и она не была протестирована, но она довольно похожа на мою конфигурацию MySQL5, так что должно быть нормально. Она оптимизирована для низкого использования памяти, а не для высокой производительности, и я не эксперт по MySQL, так что она, вероятно, не очень хороша.

[mysqld]
# set basedir to your installation path
basedir=(insert here)
# set datadir to the location of your data directory
datadir=(insert here)

# Turn off performance schema
performance_schema=OFF

# Turn off binary log
skip-log-bin
log_bin = OFF

# Disable monitoring
innodb_monitor_disable=all

# RAM optimisation settings overall
innodb_buffer_pool_size=50M
innodb_buffer_pool_instances=1
innodb_flush_method=unbuffered
innodb_log_buffer_size=1048576
innodb_log_file_size=4194304
innodb_max_undo_log_size=10485760
innodb_sort_buffer_size=64K
innodb_ft_cache_size=1600000
innodb_max_undo_log_size=10485760
max_connections=20
key_buffer_size=1M

# Reduce RAM: per thread or per operation settings
thread_stack=140K
thread_cache_size = 2
read_buffer_size=8200
read_rnd_buffer_size=8200
max_heap_table_size=16K
tmp_table_size=128K
temptable_max_ram=2097152
bulk_insert_buffer_size=0
join_buffer_size=128
net_buffer_length=1K

# Slow query log
slow_query_log=OFF
#long_query_time=5
#log_slow_rate_limit=1
#log_slow_rate_type=query
#log_slow_verbosity=full
#log_slow_admin_statements=ON
#log_slow_slave_statements=ON
#slow_query_log_always_write_time=1
#slow_query_log_use_global_control=all

# Logs
log_error = (wherever)
general_log = ON
general_log_file  = (wherever)

Связанный контент