Desde que migrei meu grande fórum para o Discourse este ano, tenho observado travamentos infrequentes com a VM na nuvem inacessível via SSH e um rastreamento de chamadas no console virtual. Os travamentos ocorrem aproximadamente a cada 3 a 6 semanas, sem um padrão específico. Inicialmente, eu estava executando o Discourse no Clear Linux porque era o que eu estava usando para extrair um pouco mais de desempenho do sistema durante a longa e intensiva migração do antigo fórum para o Discourse. Mas comecei a suspeitar que talvez o Clear Linux fosse menos estável devido a todas as suas otimizações de desempenho arcanas, então migrei meu Discourse para o Debian 12 Bookworm por volta do lançamento, há cerca de 6 semanas.
Infelizmente, hoje o sistema Debian teve seu primeiro travamento. Aqui está a sequência de eventos:
kernel: Voluntary context switch within RCU read-side critical section!
kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
journalctl mostra a última entrada de log às 06:40:50. Mas o SO e o Discourse ainda continuaram rodando. A última entrada foi apenas um bate-papo padrão do agente de e-mail Dockerizado que rodo na mesma VM.
~08:30 Verifiquei que o Discourse estava funcionando normalmente.
08:46 no log de erros do Discourse: Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
08:53 no log de erros do Discourse: Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory
09:01 no log de erros do Discourse: Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
Última postagem no Discourse foi às 09:17.
09:22 no log de erros do Discourse: 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 no log de erros do Discourse: Redis::TimeoutError (Connection timed out)
Houve mais logs semelhantes do Discourse até o momento em que notei que o site estava fora do ar, por volta das 11:20.
Quando não consegui fazer login via SSH, tirei estas capturas de tela do visualizador do console virtual e reiniciei a VM à força:
Administro servidores Linux há muito tempo, e essa cadeia de eventos não faz sentido para mim. Os logs do Discourse parecem ser uma indicação bastante clara de um evento de falta de memória (out-of-memory), e o console virtual confirma que um componente do meu servidor de e-mail Dockerizado na mesma VM foi atingido pelo OOM killer. Mas não há registro dessa ação OOM no journalctl, que aparentemente parou de funcionar bem antes que os outros sistemas começassem a falhar. O evento aparentemente primeiro às 05:00:22 menciona o processo postmaster (do PostgreSQL no contêiner do aplicativo Discourse) várias vezes, mas o banco de dados não caiu completamente até pelo menos depois das 09:17, quando houve uma postagem bem-sucedida no Discourse.
Atualmente, após rodar o dia todo, o sistema está mostrando uso normal de memória, normalmente é mais ou menos onde ele fica:
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
A única coisa um pouco incomum na minha configuração é que o espaço de swap é na verdade via Zram em vez de um arquivo de swap ou partição de swap. Tenho usado Zram por anos e nunca tive problemas. Também instalei a VM do zero com o ISO do instalador Debian para ter um sistema de arquivos raiz XFS em vez do EXT4 padrão que as imagens Debian do provedor de nuvem usam. O host é Hetzner, e após minha instalação inicial do Discourse no Clear Linux, criei uma VM diferente para a migração para Debian, então presumivelmente estou em um nó de hipervisor diferente e não acho que seja um problema de hardware. Então, me pergunto se isso foi apenas uma condição simples de falta de memória, ou se encontrei um caso extremo na combinação de kernel 6.1 + Zram + XFS + KVM/virtio? Agradeceria qualquer insight que você possa ter.
O Postgres precisa de mais memória. Você pode ajustar essas configurações de memória e talvez adicionar mais RAM, mas acho que você precisará alterar as alocações de memória do seu Postgres.
Hmm. I would tend to agree, except for the kernel errors that started first. The VM had been running since 06/Jul without a single kernel oops until this morning. Here’s the full output of that instant. Notice the page_fault_oops and handle_mm_fault and xfs_filemap_map_pages stuff:
I kind of think the same thing, except that this is somewhat of a repeat issue, feels slightly not random enough. I suspect that Hetzner probably doesn’t use ECC RAM, that’s probably how they can offer so much for the price. Even their dedicated servers apparently don’t/didn’t have ECC. But even so Hetzner is generally regarded as quite reliable in terms of their infrastructure.
Minha suspeita é esta . Tente se livrar do Zram e do XFS (um por um) e veja o que acontece. Com o Zram como meu primeiro suspeito. O Discourse deve funcionar bem com swap regular e ext4. Essas otimizações podem ser divertidas, mas atualmente estão aumentando a complexidade da sua instalação. Assim que sua instância funcionar bem, você pode adicioná-las de volta uma por uma e ver onde as coisas quebram.
Como regra geral, tente se ater o mais próximo possível de uma instalação recomendada primeiro, depois adicione suas próprias coisas inteligentes.
Obrigado pela resposta. Acho que vou tentar desabilitar o Zram e adicionar um arquivo de swap de 2 GB. A alteração do sistema de arquivos exigiria a reconstrução completa da VM com uma nova instalação do Debian, e o XFS realmente não deveria causar problemas.
Gostaria que isso fosse verdade, mas não me faça começar a falar sobre XFS. Já perdi pelo menos 200 horas da minha vida na última década com o XFS causando problemas de memória no kernel.
Bem, parece que o @RGJ estava absolutamente certo sobre o XFS. Obrigado por me indicar a direção certa. (Eu tenho usado principalmente o XFS como minha primeira escolha desde por volta de 2002, então sempre considerei que ele é extremamente estável, o que ele é como sistema de arquivos, mas aparentemente existem bugs relacionados à memória.) O mesmo problema ocorreu após desabilitar o zRAM, e então o Debian lançou uma atualização para o kernel 6.1 que inclui um patch para travamentos com XFS:
Desde que instalei o kernel 6.1.0-13, o servidor está funcionando há 42 dias sem problemas.
. Tente se livrar do Zram e do XFS (um por um) e veja o que acontece. Com o Zram como meu primeiro suspeito. O Discourse deve funcionar bem com swap regular e ext4. Essas otimizações podem ser divertidas, mas atualmente estão aumentando a complexidade da sua instalação. Assim que sua instância funcionar bem, você pode adicioná-las de volta uma por uma e ver onde as coisas quebram.