Dado que migré mi gran foro a Discourse este año, he estado experimentando caídas infrecuentes con la VM en la nube inaccesible a través de SSH y un rastreo de llamadas en la consola virtual. Las caídas ocurren aproximadamente cada 3 a 6 semanas sin ningún patrón específico. Inicialmente estaba ejecutando Discourse en Clear Linux porque era lo que estaba usando para exprimir un poco más de rendimiento del sistema durante la larga e intensiva migración del antiguo foro a Discourse. Pero comencé a sospechar que tal vez Clear Linux era menos estable debido a todas sus crípticas optimizaciones de rendimiento, así que migré mi Discourse a Debian 12 Bookworm alrededor del momento de su lanzamiento, hace aproximadamente 6 semanas.
Desafortunadamente, hoy el sistema Debian tuvo su primera caída. Aquí está la secuencia 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 muestra la última entrada de registro a las 06:40:50. Pero el sistema operativo y Discourse todavía seguían funcionando. La última entrada fue solo un parloteo estándar del agente de correo dockerizado que ejecuto en la misma VM.
~08:30 Verifiqué que Discourse estaba funcionando normalmente.
08:46 en el registro de errores de 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 en el registro de errores de 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 en el registro de errores de Discourse: Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
Última publicación en Discourse a las 09:17.
09:22 en el registro de errores de Discourse: 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 en el registro de errores de Discourse: Redis::TimeoutError (Connection timed out)
Hubo más registros similares de Discourse hasta el momento en que noté que el sitio estaba caído alrededor de las 11:20.
Cuando no pude iniciar sesión a través de SSH, tomé estas capturas de pantalla del visor de la consola virtual y reinicié la VM forzadamente:
He administrado servidores Linux durante mucho tiempo, y esta cadena de eventos no tiene sentido para mí. Los registros de Discourse parecen ser una indicación bastante obvia de un evento de falta de memoria (out-of-memory), y la consola virtual confirma que un componente de mi servidor de correo dockerizado en la misma VM fue eliminado por el OOM killer. Pero no hay registro de esa acción OOM en journalctl, que aparentemente dejó de funcionar bien antes de que los otros sistemas comenzaran a fallar. El evento aparentemente primero a las 05:00:22 menciona el proceso postmaster (de PostgreSQL en el contenedor de la aplicación Discourse) varias veces, pero la base de datos no se cayó por completo hasta al menos después de las 09:17, cuando hubo una publicación exitosa en Discourse.
Actualmente, después de funcionar todo el día, el sistema muestra un uso normal de memoria, normalmente se sitúa así:
# free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
Lo único un poco inusual en mi configuración es que el espacio de intercambio (swap) es en realidad a través de Zram en lugar de un archivo de intercambio o una partición de intercambio. He estado usando Zram durante años y nunca he tenido un problema. También instalé la VM desde cero con la ISO del instalador de Debian para tener un sistema de archivos raíz XFS en lugar del EXT4 estándar que usan las imágenes de Debian del proveedor de la nube. El host es Hetzner, y después de mi instalación inicial de Clear Linux de Discourse, creé una VM diferente para la migración a Debian, así que presumiblemente estoy en un nodo de hipervisor diferente y no creo que sea un problema de hardware. Así que me pregunto si esto fue solo una simple condición de falta de memoria, o si he encontrado un caso límite en la combinación de kernel 6.1 + Zram + XFS + KVM/virtio? Agradecería cualquier información que puedas tener.
Postgres necesita más memoria. Puedes ajustar esas configuraciones de memoria y quizás añadir RAM, pero creo que necesitarás cambiar las asignaciones de memoria de tu postgres.
Mi primera reacción aquí es problemas de hardware… y luego una búsqueda rápida en la web ve publicaciones sobre el uso de hardware de grado de escritorio.
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.
Mi presentimiento es este . Intenta deshacerte de Zram y XFS (uno por uno) y observa qué sucede. Con Zram como mi primer sospechoso. Discourse debería funcionar bien con swap normal y ext4. Estas optimizaciones pueden ser divertidas, pero actualmente están aumentando la complejidad de tu instalación. Una vez que tu instancia funcione bien, puedes volver a añadirlas una por una y ver dónde se rompen las cosas.
Como regla general, intenta ceñirte primero a una instalación recomendada, luego añade tus propias cosas inteligentes.
Gracias por la respuesta. Creo que intentaré deshabilitar Zram y agregar un archivo de intercambio de 2 GB. El cambio de sistema de archivos requeriría reconstruir completamente la VM con una nueva instalación de Debian, y XFS realmente no debería causar problemas nunca.
Ojalá fuera cierto, pero no me hagas empezar con XFS. He perdido al menos 200 horas de mi vida en la última década con XFS causando problemas de memoria en el kernel.
Bueno, parece que @RGJ tenía toda la razón sobre XFS. Gracias por indicarme la dirección correcta. (He estado usando principalmente XFS como mi primera opción desde alrededor de 2002, así que siempre he dado por sentado que es muy sólido, lo cual es como sistema de archivos, pero aparentemente hay errores relacionados con la memoria). El mismo problema ocurrió después de deshabilitar zRAM, y luego Debian lanzó una actualización para el kernel 6.1 que incluye un parche para fallos con XFS:
Desde que instalé el kernel 6.1.0-13, el servidor ha estado funcionando durante 42 días sin problemas.
. Intenta deshacerte de Zram y XFS (uno por uno) y observa qué sucede. Con Zram como mi primer sospechoso. Discourse debería funcionar bien con swap normal y ext4. Estas optimizaciones pueden ser divertidas, pero actualmente están aumentando la complejidad de tu instalación. Una vez que tu instancia funcione bien, puedes volver a añadirlas una por una y ver dónde se rompen las cosas.