eu tenho umt3a.microinstância executando o wordpress com tráfego muito baixo. Esta instância fica indisponível automaticamente, resultando em erro de tempo limite do gateway 504. Naquele momento, também não consigo me conectar ao EC2 usando ssh. Acontece a qualquer hora do dia, às vezes diariamente e às vezes nem acontece durante a semana inteira. Não há pico de tráfego quando ele cai também. Também fiz esta pergunta no AWS Support e recebi a seguinte resposta:
Ao verificar do meu lado, pude ver que a instância falhou na verificação de status da instância[1] várias vezes nas últimas 24 horas, indicando que a instância tem problemas no nível do sistema operacional. Ao verificar mais detalhadamente os logs do console, pude ver o seguinte erro de falta de memória:
[5626.002561] Sem memória: processo eliminado 2050 (apache2) total-vm:552924kB, anon-rss:54868kB, arquivo-rss:0kB, shmem-rss:32076kB, UID:33 pgtables:848kB oom_score_adj:0
[5674.174673] Sem memória: processo eliminado 1788 (apache2) total-vm:624936kB, anon-rss:51952kB, arquivo-rss:0kB, shmem-rss:34184kB, UID:33 pgtables:856kB oom_score_adj:0
[5763.820732] Sem memória: processo eliminado 1815 (apache2) total-vm:550384kB, anon-rss:51604kB, arquivo-rss:0kB, shmem-rss:34532kB, UID:33 pgtables:836kB oom_score_adj:0
[5773.275938] Sem memória: processo eliminado 1973 (apache2) total-vm:624744kB, anon-rss:52260kB, arquivo-rss:0kB, shmem-rss:32136kB, UID:33 pgtables:856kB oom_score_adj:0
[5959.347157] Sem memória: processo eliminado 2014 (apache2) total-vm:552440kB, anon-rss:54020kB, arquivo-rss:0kB, shmem-rss:28856kB, UID:33 pgtables:844kB oom_score_adj:0
[6438.787255] Sem memória: processo eliminado 2165 (apache2) total-vm:624756kB, anon-rss:51948kB, arquivo-rss:0kB, shmem-rss:29836kB, UID:33 pgtables:856kB oom_score_adj:0
Um pouco sobre o assassino OOM (falta de memória), se a memória for exaustivamente usada pelos processos, a ponto de ameaçar a estabilidade do sistema, então o assassino OOM entra em ação. processos até que memória suficiente seja liberada para o bom funcionamento do restante do processo que o Kernel está tentando executar. Parece pela saída que sua instância pode ter esgotado a memória, portanto, o assassino OOM está sendo chamado pelo Kernel do Linux.
Eles sugeriram monitorar o uso de memória por cada processo e eliminar ou consertar esse processo para não usar tanta memória. Esta não parece uma abordagem muito prática no momento em que estou executando o wordpress, que não posso modificar mesmo que use muita memória por alguns minutos.
Eu tenho outro exemplot3.pequenousando o beanstalk elástico que hospeda um aplicativo web java com ambiente nginx/tomcat no Amazon Linux AMI fornecido pelo beanstalk. O mesmo problema acontece com esta instância, desativa automaticamente e mostra o tempo limite do gateway 504.
Pergunta:- Não quero atualizar minha instância porque ela está funcionando perfeitamente com a quantidade atual de tráfego nelas. Existe alguma solução para lidar com esses problemas sem atualização e, claro, monitoramento constante dos processos?
Responder1
Suas principais opções são:
- Descubra o que está usando a RAM e configure-o para usar menos RAM (melhor opção)
- Use uma instância com mais RAM (o que pode não resolver totalmente o problema)
- Use um arquivo de troca como uma forma barata de aumentar a RAM - eu uso um arquivo de troca apenas para ter certeza de que há algum espaço extra para evitar situações de OOM, portanto, embora não resolva o problema, é uma boa ideia.
Eu executo cinco sites Wordpress de volume bastante baixo, MySQL e algumas outras ferramentas em um t3a.nano (512 MB de RAM) mais 512 MB de swap.
Aqui estão algumas maneiras de reduzir o uso de memória de um sistema Wordpress típico (na minha cabeça):
- Limite o número de threads/trabalhadores PHP. Acho que permito talvez 2 a 3 threads; se um não estiver disponível, o servidor web esperará até que um esteja, o que geralmente não demora muito. Este é fundamental, pois PHP / Wordpress consome muita memória.
- Limite a memória máxima disponível para cada thread PHP.
- Desligue o esquema de desempenho do MySQL
- Gire os parâmetros do MySQL para reduzir o uso de memória. Basicamente, você só precisa ler a documentação, mas copiarei minha configuração atual abaixo. Isto é do meu PC com Windows, mas o Linux será semelhante.
- Verifique o uso de memória do seu servidor web, se for Apache e alto, você pode considerar o Nginx, que é rápido e pequeno.
Você também deve procurar por "LAMP (ou LEMP) wordpress reduz o uso de memória"
Aqui está a configuração do MySQL que estou usando. É minha nova configuração para MySQL 8.x e não foi testada, mas é bastante semelhante à minha configuração do MySQL5, então deve estar ok. Ele é otimizado para baixo uso de memória, não para alto desempenho, e eu não sou um especialista em MySQL, então provavelmente não é ótimo.
[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)