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. Tiendo a estar de acuerdo, excepto por los errores del kernel que aparecieron primero. La VM llevaba funcionando desde el 6 de julio sin un solo «oops» del kernel hasta esta mañana. Aquí está la salida completa de ese instante. Fíjate en las cosas de page_fault_oops, handle_mm_fault y xfs_filemap_map_pages:
En cierto modo pienso lo mismo, excepto que esto es un problema que se repite en cierta medida; no parece tan aleatorio. Sospecho que Hetzner probablemente no use memoria RAM ECC; eso es probablemente lo que les permite ofrecer tanto por ese precio. Incluso sus servidores dedicados aparentemente no tenían/tienen ECC. Pero aun así, Hetzner se considera generalmente bastante fiable en cuanto a su infraestructura.
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.