Rake:rebake falla con errores: PG::ConnectionBad: PQsocket

[j127]

Migré un foro de 200.000 publicaciones a un nuevo servidor. El sitio en vivo se puso en modo de solo lectura para evitar tiempos de inactividad.

Restauré la copia de seguridad en un subdominio diferente para que los usuarios no vieran las pantallas de instalación ni ningún problema que pudiera ocurrir durante la restauración, algo como dev.example.com.

Tan pronto como la restauración se completó, apunté el DNS al nuevo servidor y cambié el dominio del archivo app.yml al forum.example.com normal.

Luego, todas las caritas sonrientes en las publicaciones base apuntaban al servidor dev.example.com, así que ejecuté rake:rebake.

Procesa alrededor de 1.000-2.000 publicaciones antes de fallar con errores sobre la conexión a la base de datos.

Aquí hay un par de extractos:

/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:34:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:28:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:45:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:33:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
     1999 / 200968 (  1.0%)
Failed to rebake (topic_id: 78730, post_id: 210607)
PG::ConnectionBad: PQsocket() can't get socket descriptor

/var/www/discourse/lib/tasks/posts.rake:108:in `rebake_posts_all_sites'
/var/www/discourse/lib/tasks/posts.rake:7:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'

Caused by:
PG::ConnectionBad: PQsocket() can't get socket descriptor

En este momento, tengo las imágenes cargando redirigiendo el dominio dev.example.com al dominio forum.example.com, pero es solo una solución temporal.

¿Alguien sabe cómo superar ese error para poder volver a hornear todas las publicaciones? ¿Está creando demasiada carga en la base de datos?

[pfaffman (Jay Pfaffman)]

Primero, consulta Cambiar el nombre de dominio o renombrar tu Discourse (aunque otra solución es hacer una copia de seguridad y luego restaurar con el nuevo nombre de host).

Supongo que te estás quedando sin conexiones a la base de datos, pero ese no es el error que esperaría.

¿Es una instalación estándar o estás usando algún otro servidor PG?

[j127]

Gracias por los enlaces. Es una instalación estándar de Docker en una instancia de DigitalOcean (“Premium AMD”, 4 GB de RAM, 2 vCPUs).

Seguí las instrucciones del enlace que mencionaste. Encontré algunas URL incorrectas en la configuración, así que las corregí y reconstruí el foro nuevamente para estar seguro.

Luego ejecuté este tipo de comando:

discourse remap dev.example.com forum.example.com

Ese comando falló con este tipo de error:

Error: ERROR:  duplicate key value violates unique constraint "unique_post_links"
DETAIL:  Key (topic_id, post_id, url)=(78821, 207117, https://forum.example.com/t/the-slug/78946/7) already exists.

Así que temporalmente eliminé una publicación que enlazaba a la URL mencionada (https://forum.example.com/t/the-slug/78946/7), ejecuté el comando de nuevo y funcionó sin fallar.

Luego hice rake posts:rebake de nuevo.

Falló en algunas publicaciones como esta, pero continuó (reconstruí el HTML para esas publicaciones manualmente):

Rebaking post markdown for 'default'
     2273 / 200996 (  1.1%)
Failed to rebake (topic_id: 66586, post_id: 210353)
JavaScript was terminated (either by timeout or explicitly)

Finalmente, falló justo antes de llegar a 11.000 publicaciones con errores como este:

/usr/local/bin/bundle:25:in `<main>'
    10996 / 200996 (  5.5%)
Failed to rebake (topic_id: 76678, post_id: 200988)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.4.1/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `block (2 levels) in exec_no_cache'

Todo el servidor pareció desconectarse porque Uptime Robot me avisó que el sitio estaba caído.

¿Crees que el servidor no es lo suficientemente potente para ejecutar ese comando?

Está funcionando con más del 80% de RAM normalmente, y alcanza el 100% mientras se ejecuta el comando. Quizás simplemente se quedó sin memoria.

[Ed_S]

Si tienes un disco local, puedes añadir swap, lo que evitaría el agotamiento de la memoria (sea o no la causa del problema aquí). ¿Qué te dice free? ¿Ves oom o memory en la salida de dmesg?

[j127]

@Ed_S

¿Qué te dice free?

En este momento dice:

              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       2.1Gi       160Mi       1.0Gi       1.6Gi       488Mi
Swap:             0B          0B          0B

@Ed_S

¿Ves oom o memory en la salida de dmesg?

No veo oom, pero la palabra memory aparece en algunos lugares sobre reservar y liberar memoria.

El servidor se creó con 4 GB de RAM, por lo que Discourse no creó automáticamente un archivo de intercambio. ¿Crees que vale la pena añadirlo?

[Ed_S]

Si tienes espacio en disco, ciertamente vale la pena agregar, digamos, 2G de swap.

Lo otro que debes hacer es monitorear el uso mientras se ejecuta tu trabajo grande. Usaría vmstat 5 5 y quizás registraría en un archivo. Esperas no ver valores grandes en las columnas si o so, y no ver que la columna swpd se acerque al tamaño de tu swap.

Quizás ve esta publicación:

@Ed_S

Para intentar capturar la situación en su punto más cercano a la falla, usé vmstat 5

(Parece posible que el sistema de bases de datos se esté quedando sin algún recurso, pero no sé nada al respecto).

[j127]

Gracias, intentaré esas cosas más tarde hoy. Tengo 50 GB libres en este momento.

[j127]

Agregué un archivo de paginación de 2 GB y eso parece haberlo solucionado. El rebaking solo está al 20%, pero no ha habido ni un solo error y el uso de RAM está justo por debajo del 100%.

Muchas gracias a ambos por su ayuda.

[Ed_S]

¡Suena bien! Solo para que conste

• podrías añadir más swap, incluso mientras la tarea se está ejecutando, si vmstat o free (o top) muestran que el swap se está agotando.
• si tienes cuidado, probablemente podrías hacer una actualización temporal reversible a una instancia con más RAM, lo que costará un poco de dinero, pero solo debería estar en su lugar durante unas pocas horas. Es importante no pasar a una instancia con un disco más grande, ya que eso no es reversible. (Más RAM debería permitir que las cosas funcionen a toda velocidad, mientras que una RAM modesta y mucho swap podrían tener una penalización de rendimiento, y la tarea tardará más en finalizar).

[j127]

@Ed_S

probablemente podrías hacer una mejora temporal reversible a una instancia con más RAM

Lo pensé, pero tendría que apagar el servidor, y los usuarios ya tuvieron un molesto período de “solo lectura” y tiempo de inactividad cuando cambié de servidor.

No pude terminarlo anoche porque tuve que irme a dormir, pero ya está funcionando de nuevo. 30% hasta ahora sin errores.

[Ed_S]

Vigila las cosas con vmstat o similar; es un trabajo de tan larga duración que no querrás tener que reiniciarlo. Probablemente añadiría otros 2G de swap, por si acaso.

[j127]

Gracias, revisé ocasionalmente con vmstat. Lo inicié en una sesión de tmux para poder desconectarme y cerrar mi portátil por un tiempo. Probablemente tardó entre 8 y 9 horas en ejecutar el comando, pero todo se completó sin errores.