La instancia EC2 deja de estar disponible automáticamente: tiempo de espera de puerta de enlace 504

La instancia EC2 deja de estar disponible automáticamente: tiempo de espera de puerta de enlace 504

tengo unt3a.microejemplo ejecutando wordpress con tráfico bastante bajo. Esta instancia deja de estar disponible automáticamente, lo que genera un error de tiempo de espera de puerta de enlace 504. En ese momento tampoco puedo conectarme con EC2 usando ssh. Ocurre en cualquier momento del día, a veces a diario y a veces no ocurre durante toda la semana. Tampoco hay picos de tráfico cuando baja. También hice esta pregunta a AWS Support y obtuve la siguiente respuesta:

Al verificar por mi parte, pude ver que la instancia no pasó la verificación de estado de la instancia[1] varias veces en las últimas 24 horas, lo que indica que la instancia tiene problemas a nivel del sistema operativo. Al revisar más a fondo los registros de la consola, pude ver el siguiente error de falta de memoria:

[5626.002561] Sin memoria: proceso cancelado 2050 (apache2) total-vm:552924kB, anon-rss:54868kB, file-rss:0kB, shmem-rss:32076kB, UID:33 pgtables:848kB oom_score_adj:0

[5674.174673] Sin memoria: proceso cancelado 1788 (apache2) total-vm:624936kB, anon-rss:51952kB, file-rss:0kB, shmem-rss:34184kB, UID:33 pgtables:856kB oom_score_adj:0

[5763.820732] Sin memoria: proceso cancelado 1815 (apache2) total-vm:550384kB, anon-rss:51604kB, file-rss:0kB, shmem-rss:34532kB, UID:33 pgtables:836kB oom_score_adj:0

[5773.275938] Sin memoria: proceso cancelado 1973 (apache2) total-vm:624744kB, anon-rss:52260kB, file-rss:0kB, shmem-rss:32136kB, UID:33 pgtables:856kB oom_score_adj:0

[5959.347157] Sin memoria: proceso cancelado 2014 (apache2) total-vm:552440kB, anon-rss:54020kB, file-rss:0kB, shmem-rss:28856kB, UID:33 pgtables:844kB oom_score_adj:0

[6438.787255] Sin memoria: proceso cancelado 2165 (apache2) total-vm:624756kB, anon-rss:51948kB, file-rss:0kB, shmem-rss:29836kB, UID:33 pgtables:856kB oom_score_adj:0

Un poco sobre el asesino OOM (Memoria insuficiente), si los procesos utilizan la memoria de manera exhaustiva, hasta el punto de amenazar la estabilidad del sistema, entonces el asesino OOM entra en acción. La tarea del asesino OOM es continuar matando. procesos hasta que se libere suficiente memoria para el buen funcionamiento del resto del proceso que el Kernel está intentando ejecutar. Según el resultado, parece que su instancia podría haber agotado la memoria, por lo que el kernel de Linux está invocando el asesino OOM.

Sugirieron monitorear el uso de la memoria por parte de cada proceso y eliminar o arreglar ese proceso para no usar tanta memoria. Esto no parece un enfoque muy práctico en un momento en el que estoy ejecutando WordPress, que no puedo modificar incluso si usa demasiada memoria durante unos minutos.

tengo otra instanciat3.pequeñoutilizando elastic beanstalk que aloja una aplicación web java con entorno nginx/tomcat en la AMI de amazon linux proporcionada por beanstalk. El mismo problema ocurre con esta instancia, se desactiva automáticamente y muestra el tiempo de espera de la puerta de enlace 504.

Pregunta:- No quiero actualizar mi instancia porque están funcionando perfectamente bien con la cantidad actual de tráfico. ¿Existe alguna solución para manejar estos problemas sin actualizaciones y, por supuesto, un monitoreo constante de los procesos?

Respuesta1

Tus principales opciones son:

  • Averigüe qué está usando la RAM y configúrelo para usar menos RAM (la mejor opción)
  • Utilice una instancia con más RAM (lo que puede no resolver completamente el problema)
  • Utilice un archivo de intercambio como una forma económica de aumentar la RAM. Yo uso un archivo de intercambio solo para asegurarme de que haya algo de repuesto para evitar situaciones OOM, por lo que, aunque no resolverá el problema, es una buena idea.

Ejecuto cinco sitios web de Wordpress de volumen bastante bajo, MySQL y algunas otras herramientas en un t3a.nano (512 MB de RAM) más 512 MB de intercambio.

Aquí hay algunas formas de reducir el uso de memoria de un sistema Wordpress típico (que no se me ocurre):

  • Limite el número de subprocesos/trabajadores de PHP. Creo que permito quizás 2 o 3 subprocesos; si uno no está disponible, el servidor web esperará hasta que lo esté, lo que normalmente no es mucho tiempo. Este es clave ya que PHP/Wordpress consume mucha memoria.
  • Limite la memoria máxima disponible para cada hilo PHP.
  • Desactivar el esquema de rendimiento de MySQL
  • Cambie los parámetros de MySQL para reducir el uso de memoria. Básicamente sólo tienes que leer la documentación, pero copiaré mi configuración actual a continuación. Esto es de mi PC con Windows, pero Linux será similar.
  • Verifique el uso de memoria de su servidor web; si es Apache y es alto, podría considerar Nginx, que es rápido y pequeño.

También debes buscar "LAMP (o LEMP) wordpress reduce el uso de memoria"

Aquí está la configuración de MySQL que estoy usando. Es mi nueva configuración para MySQL 8.x y no ha sido probada, pero es bastante similar a mi configuración de MySQL5, por lo que debería estar bien. Está optimizado para un uso reducido de memoria, no para un alto rendimiento, y no soy un experto en MySQL, por lo que probablemente no sea excelente.

[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)

información relacionada