Rake:rebake si blocca con errori: PG::ConnectionBad: PQsocket

[j127]

Ho migrato un forum di 200.000 post su un nuovo server. Il sito live è stato messo in modalità di sola lettura per evitare tempi di inattività.

Ho ripristinato il backup su un sottodominio diverso in modo che gli utenti non vedessero le schermate di installazione o eventuali problemi che potrebbero verificarsi durante il ripristino, qualcosa come dev.example.com.

Appena completato il ripristino, ho puntato il DNS al nuovo server e ho modificato il dominio nel file app.yml in forum.example.com.

Quindi tutte le faccine nei post originali puntavano al server dev.example.com, quindi ho eseguito rake:rebake.

Procede con circa 1.000-2.000 post prima di bloccarsi con errori relativi alla connessione al database.

Ecco un paio di estratti:

/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

Al momento, ho le immagini che si caricano reindirizzando il dominio dev.example.com al dominio forum.example.com, ma è solo una soluzione temporanea.

Qualcuno sa come superare quell’errore in modo da poter rifare il rebake di tutti i post? Sta creando troppo carico sul database?

[pfaffman (Jay Pfaffman)]

Per prima cosa, consulta Cambia il nome del dominio o rinomina il tuo Discourse (anche se un’altra soluzione è eseguire il backup e quindi ripristinare con il nuovo hostname).

La mia ipotesi è che tu stia esaurendo le connessioni al database, ma non è questo l’errore che mi aspetterei.

Si tratta di un’installazione standard o stai utilizzando un altro server PG?

[j127]

Grazie per i link. Si tratta di un’installazione Docker standard su una droplet DigitalOcean (“Premium AMD”, 4 GB di RAM, 2 vCPU).

Ho seguito le istruzioni nel link che hai menzionato. Ho trovato alcuni URL errati nelle impostazioni, quindi li ho corretti e ho ricostruito nuovamente il forum per sicurezza.

Poi ho eseguito questo tipo di comando:

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

Quel comando è andato in crash con questo tipo di errore:

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.

Quindi ho eliminato temporaneamente un post che collegava all’URL menzionato (https://forum.example.com/t/the-slug/78946/7), ho eseguito nuovamente il comando e ha funzionato senza andare in crash.

Poi ho eseguito di nuovo rake posts:rebake.

È fallito su alcuni post come questo, ma ha continuato (ho ricostruito manualmente l’HTML per quei post):

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)

Infine, è andato in crash poco prima di raggiungere 11.000 post con errori come questo:

/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'

L’intero server sembra essere andato offline perché sono stato avvisato da Uptime Robot che il sito non era disponibile.

Pensi che il server non sia abbastanza potente per eseguire quel comando?

Normalmente è in uso oltre l’80% della RAM e raggiunge il 100% mentre il comando è in esecuzione. Forse ha semplicemente esaurito la memoria.

[Ed_S]

Se hai un disco locale, puoi aggiungere lo swap, che eviterebbe l’esaurimento della memoria (indipendentemente dal fatto che sia la causa del problema qui). Cosa dice free? Vedi oom o memory nell’output di dmesg?

[j127]

@Ed_S

Cosa dice free?

Al 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

Vedi oom o memory nell’output di dmesg?

Non vedo oom, ma la parola memory appare in alcuni punti riguardo alla prenotazione e al rilascio di memoria.

Il server è stato creato con 4GB di RAM, quindi Discourse non ha creato automaticamente un file di swap. Pensi che valga la pena aggiungerlo?

[Ed_S]

Se hai spazio su disco, vale sicuramente la pena aggiungere, diciamo, 2G di swap.

L’altra cosa da fare è monitorare l’utilizzo mentre il tuo grosso lavoro è in esecuzione. Userei vmstat 5 5 e forse registrerei su un file. Speri di non vedere valori elevati nelle colonne si o so, e di non vedere la colonna swpd avvicinarsi alla dimensione del tuo swap.

Forse vedi questo post:

@Ed_S

Per cercare di cogliere la situazione al suo punto più vicino al fallimento, ho usato vmstat 5

(Sembra possibile che il sistema di database stia esaurendo qualche risorsa, ma non ne so nulla.)

[j127]

Grazie, proverò queste cose più tardi oggi. Al momento ho 50 GB liberi.

[j127]

Ho aggiunto un file di swap da 2 GB e sembra che abbia risolto il problema. Il ribaking è completato solo al 20%, ma non c’è stato un singolo errore e l’utilizzo della RAM è appena al di sotto del 100%.

Grazie a entrambi per il vostro aiuto.

[Ed_S]

Ottimo! Giusto per la cronaca

• potresti aggiungere più swap, anche mentre l’attività è in esecuzione, se vmstat o free (o top) mostrano che lo swap si sta esaurendo.
• se sei attento, potresti probabilmente fare un aggiornamento temporaneo reversibile a un’istanza con più RAM, che costerà un po’ di denaro, ma dovrà essere in atto solo per poche ore. È importante non passare a un’istanza con un disco più grande poiché ciò non è reversibile. (Più RAM dovrebbe consentire alle cose di funzionare a piena velocità, mentre una RAM modesta e molto swap potrebbero comportare una penalità di prestazioni e l’attività richiederà più tempo per essere completata.)

[j127]

@Ed_S

probabilmente potresti fare un aggiornamento temporaneo reversibile a un’istanza con più RAM

Ci ho pensato, ma dovrei spegnere il server, e gli utenti avevano già avuto un fastidioso periodo di “sola lettura” e un’interruzione quando ho spostato i server.

Non sono riuscito a finire ieri sera perché dovevo andare a dormire, ma ora è di nuovo operativo. Finora al 30% senza errori.

[Ed_S]

Tieni d’occhio le cose con vmstat o simili: si tratta di un processo così lungo, non vorrai doverlo riavviare. Probabilmente aggiungerei altri 2G di swap, per sicurezza.

[j127]

Grazie, ho controllato occasionalmente con vmstat. L’ho avviato in una sessione tmux in modo da potermi disconnettere e chiudere il laptop per un po’. Probabilmente ci sono volute 8-9 ore per eseguire il comando, ma tutto è stato completato senza errori.