Poiché ho migrato il mio grande forum a Discourse quest’anno, ho riscontrato crash infrequenti con la VM cloud inaccessibile tramite SSH e un trace di chiamata sulla console virtuale. I crash si verificano approssimativamente ogni 3-6 settimane senza uno schema specifico. Inizialmente stavo eseguendo Discourse su Clear Linux perché era quello che stavo usando per spremere un po’ più di prestazioni dal sistema durante la lunga e intensiva migrazione del vecchio forum a Discourse. Ma ho iniziato a sospettare che forse Clear Linux fosse meno stabile a causa di tutte le sue arcane ottimizzazioni delle prestazioni, quindi ho migrato il mio Discourse a Debian 12 Bookworm intorno al momento del suo rilascio, circa 6 settimane fa.
Sfortunatamente, oggi il sistema Debian ha avuto il suo primo crash. Ecco la sequenza degli eventi:
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 l’ultima voce di log alle 06:40:50. Ma il sistema operativo e Discourse continuavano a funzionare. L’ultima voce era solo un normale chiacchiericcio dall’agente di posta Dockerizzato che eseguo sulla stessa VM.
Intorno alle 08:30 ho verificato che Discourse fosse attivo e funzionante normalmente.
08:46 nel log degli errori di 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 nel log degli errori di 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 nel log degli errori di Discourse: Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker
Ultimo post su Discourse alle 09:17.
09:22 nel log degli errori di Discourse: 'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted!
09:22 nel log degli errori di Discourse: Redis::TimeoutError (Connection timed out)
Ci sono stati altri log simili di Discourse fino al momento in cui ho notato che il sito era inattivo intorno alle 11:20.
Quando non sono riuscito ad accedere tramite SSH, ho scattato questi screenshot dal visualizzatore della console virtuale e ho riavviato forzatamente la VM:
Amministro server Linux da molto tempo e questa catena di eventi non ha senso per me. I log di Discourse sembrano essere una chiara indicazione di un evento di esaurimento della memoria (out-of-memory) e la console virtuale conferma che un componente del mio server di posta Dockerizzato sulla stessa VM è stato eliminato dall’OOM killer. Ma non c’è traccia di quell’azione OOM in journalctl, che apparentemente ha smesso di funzionare ben prima che gli altri sistemi iniziassero a fallire. L’evento apparentemente primo alle 05:00:22 menziona il processo postmaster (da PostgreSQL nel container dell’app Discourse) più volte, ma il DB non è andato completamente giù fino almeno a dopo le 09:17, quando c’è stato un post riuscito su Discourse.
Attualmente, dopo aver funzionato tutto il giorno, il sistema mostra un utilizzo normale della memoria, questo è normalmente all’incirca dove si trova:
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
L’unica cosa leggermente insolita nella mia configurazione è che lo spazio di swap è effettivamente tramite Zram invece di un file di swap o una partizione di swap. Uso Zram da anni e non ho mai avuto problemi. Inoltre, ho installato la VM da zero con l’ISO di installazione Debian per avere un filesystem root XFS invece del normale EXT4 che usano le immagini Debian del provider cloud. L’host è Hetzner e dopo la mia installazione iniziale di Discourse su Clear Linux, ho creato una VM diversa per la migrazione a Debian, quindi presumibilmente sono su un nodo hypervisor diverso e non credo che sia un problema hardware. Quindi mi chiedo se questo sia stato semplicemente un semplice esaurimento di memoria, o se ho trovato un caso limite nella combinazione di kernel 6.1 + Zram + XFS + KVM/virtio? Apprezzerei qualsiasi intuizione tu possa avere.
Postgres ha bisogno di più memoria. Puoi modificare quelle impostazioni di memoria e magari aggiungere RAM, ma penso che dovrai modificare le allocazioni di memoria del tuo 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.
La mia ipotesi è questa . Prova a eliminare sia Zram che XFS (uno alla volta) e vedi cosa succede. Con Zram come mio primo sospetto. Discourse dovrebbe funzionare bene con swap normale ed ext4. Queste ottimizzazioni potrebbero essere divertenti ma attualmente aumentano la complessità della tua installazione. Una volta che la tua istanza funziona bene, puoi riaggiungerle una alla volta e vedere dove si rompono le cose.
Come regola generale, cerca di attenerti il più possibile a un’installazione consigliata prima, poi aggiungi le tue cose intelligenti.
Grazie per la risposta. Penso che proverò a disabilitare Zram e ad aggiungere un file di swap da 2 GB. La modifica del filesystem richiederebbe la ricostruzione completa della VM con una nuova installazione di Debian, e XFS non dovrebbe mai causare problemi.
Vorrei che fosse vero, ma non iniziare a parlarmi di XFS. Ho sprecato almeno 200 ore della mia vita nell’ultimo decennio a causa di XFS che causava problemi di memoria nel kernel.
Beh, sembra che @RGJ avesse assolutamente ragione riguardo a XFS. Grazie per avermi indicato la giusta direzione. (Uso principalmente XFS come prima scelta dal 2002 circa, quindi ho sempre dato per scontato che fosse estremamente stabile, il che è vero come filesystem, ma apparentemente ci sono bug legati alla memoria.) Lo stesso problema si è verificato dopo aver disabilitato zRAM, e poi Debian ha rilasciato un aggiornamento per il kernel 6.1 che include una patch per i crash con XFS:
Da quando ho installato il kernel 6.1.0-13, il server è attivo da 42 giorni senza problemi.
. Prova a eliminare sia Zram che XFS (uno alla volta) e vedi cosa succede. Con Zram come mio primo sospetto. Discourse dovrebbe funzionare bene con swap normale ed ext4. Queste ottimizzazioni potrebbero essere divertenti ma attualmente aumentano la complessità della tua installazione. Una volta che la tua istanza funziona bene, puoi riaggiungerle una alla volta e vedere dove si rompono le cose.