Máquina inteira trava durante a atualização

Desde que experimentei os plugins de IA (e depois os removi novamente), minha máquina trava totalmente durante o /admin/upgrade.

Nem sempre, mas aproximadamente 80% das vezes.

Geralmente, toda a minha instância EC2 congela e preciso fazer uma reinicialização forçada através da interface web do AWS EC2.

Hoje, ela travou novamente. Para minha surpresa, não congelou completamente. Ao abrir a URL raiz, agora mostra:

Oops

O software que alimenta este fórum de discussão encontrou um problema inesperado. Pedimos desculpas pelo inconveniente.

Informações detalhadas sobre o erro foram registradas e uma notificação automática gerada. Daremos uma olhada.

Nenhuma ação adicional é necessária. No entanto, se a condição de erro persistir, você pode fornecer detalhes adicionais, incluindo passos para reproduzir o erro, postando um tópico de discussão na categoria de feedback do site.

Agora tentarei reiniciá-lo novamente e farei o usual sudo ./launcher rebuild app, que o consertou até agora. Dedos cruzados para que funcione hoje, novamente.

Minha pergunta

Alguém pode me dar algumas dicas sobre onde posso verificar arquivos de log ou coisas assim para obter pelo menos uma mensagem de erro do porquê os travamentos ocorrem?

O plugin de IA oficial?

Eu executaria isso do console e veria onde ele trava, compartilhe os logs.

Sim, o plugin oficial.

Eu o desinstalei removendo os plugins de app.yml novamente e depois reconstruindo. Talvez isso não seja suficiente?

O que se entende por “isto”? O sudo ./launcher rebuild app?

Qual é a especificação do seu servidor?

Atualizações online, na minha opinião, exigem um servidor de 4 GB + 2 GB de swap atualmente como mínimo.

Estou usando um AWS EC2 "t2.medium" com 2 vCPUs e 4 GiB de RAM.

O HDD é de 100 GiB com 60 GiB de espaço livre.

Se ajudar, posso fazer o upgrade do "t2.medium" para um tipo de instância maior.

Estou apenas confuso que essa configuração funcionou de forma sólida (por anos) antes do meu teste do plugin oficial de IA e somente desde que o removi ocorrem esses travamentos durante a atualização.

Outra coisa mudou: a versão do software para a qual você está atualizando. Ela se tornou mais exigente em memória ultimamente. Então, eu acho que pode ser qualquer uma das duas.

Uma atualização temporária e reversível para uma instância com mais RAM é provavelmente a maneira mais fácil de testar se a falta de memória é o problema, embora custe algumas reinicializações. A outra maneira é adicionar swap, que também é reversível.

Eu tentaria adicionar swap.

Obrigado, pessoal, vou pesquisar no Google como fazer isso e depois farei .

Atualização 1

Adicionei 8 GiB de swap:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

Postarei uma atualização aqui após algumas próximas atualizações para ver se isso ajudou.

Atualização 2

Acabei de fazer um /admin/upgrade e monitorei o uso de RAM:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

E a atualização foi concluída com sucesso. Espero que continue assim.

Atualização 3

Vários dias e atualizações depois, nunca mais experimentei uma travada.

Então, acho que o swap foi a solução. Obrigado novamente a todos que me ajudaram com este problema.

Isto está um pouco fora do tópico, mas eu realmente gostaria de entender. Por que o swap, que usou 200 MB, ajudou quando havia 2 GB de RAM livre?

(Eu entendo que no mundo da polegada o sistema SI pode ser confuso porque usa escala de 10, mas por que diabos Mi? Eu posso meio que entender Gi se for abreviado de giga, mas mega deveria então ser Me?)

Mi por Mibibytes eu presumo, e Gi por Gibibytes.

Obrigado. Eu não sabia disso, óbvio. Mas é mebibyte

E para outros que também não sabiam

Eu acho que o problema original provavelmente foi um processo sendo encerrado porque a máquina estava sem memória (cuidado com o OOM killer). Adicionar swap significou que a memória não se esgotou. Essas duas saídas de free podem não estar contando toda a história, a menos que tenham sido tiradas com muito cuidado no momento de maior estresse da máquina. É o pico de uso de swap que é interessante, eu acho.

Mas também há a questão do ajuste do kernel, como mencionado em
Configuração de Implantação Opiniosa do Discourse do MKJ
que eu configurei corretamente, mas que talvez muitas pessoas não tenham configurado corretamente.

Vale notar que o overcommit de memória não tem muito a ver com o Redis. É apenas que o Redis é gentil o suficiente para dar a dica de que deve ser configurado corretamente.

Acabei de iniciar mais um /admin/upgrade e abri um shell para chamar manualmente tree -h a cada segundo, mais ou menos.

Os maiores valores de uso de memória que consegui encontrar foram estes:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

A atualização foi bem-sucedida.

Então 4 GB está no limite no momento da compilação, se supusermos que a última captura de tela mostra o momento mais estressante.

E essa é outra coisa que não consigo entender: por que outros têm pouca memória e eu, que uso muitos plugins e componentes, não tive nenhum problema o que faz essa diferença?

E eu usei tinha porque hoje em dia tenho 8 GB por causa da IA (e para mim a diferença de preço não foi tão importante, mas essa é outra história).

Este tópico deve ser movido para outro lugar ou estamos vendo isso como uma explicação de por que usar swap ajudou?

De qualquer forma. Para outros iniciantes, este é um exemplo onde se fala um pouco sobre pouca memória e as razões para isso:

Essa é uma pergunta fortemente frequente quando a atualização falha. Mas a razão para isso raramente é explicada.

@Jagster @uwe_keim por favor, poderiam relatar a saída destes comandos

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled 

Nos meus sistemas eu tenho

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]

$ cat /proc/sys/vm/overcommit_memory
0

e

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

Obrigado @uwe_keim - Vou supor que esses parâmetros ajustáveis do kernel são o motivo pelo qual você precisou adicionar swap, mesmo que não parecesse estar sendo usado. (O mesmo se aplicaria se você precisasse adicionar muita RAM, pois a memória total disponível é RAM + swap.)

Posso alterar as configurações do servidor a qualquer momento se você recomendar que eu o faça.

root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

Eu recomendo!

Isso corrigirá para reinicializações futuras (observe que ele substitui arquivos sem verificar o estado atual):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system