Sembra che 2+2 potrebbe non bastare più… Sto gestendo un’istanza Discourse piuttosto modesta (senza plugin grandi/fantastici, ecc.) che, a partire da oggi, non riesce ad avviarsi perché Ember sta consumando tutta la RAM che trova, e tutta la swap, e sta rendendo la macchina inutilizzabile. L’aggiunta di altri 2 GB di swap ha permesso il completamento dell’avvio, con un picco di utilizzo della swap di circa 2,5 GB.
Accidenti, questa è nella lista di @david da indagare.
5 Mi Piace
@david sta indagando, confermiamo che al momento 2 GB sono sufficienti per le ricompilazioni di Docker, ma non abbastanza per il funzionamento dell’aggiornatore web.
Un’idea che ho avanzato è quella di arrestare tutti i processi Ruby durante l’aggiornatore web per risparmiare altri 300-500 MB, il che lascerebbe abbastanza spazio per la precompilazione degli asset.
Un approccio a lungo termine che probabilmente dovremo adottare per gli self-hoster è spedire container avviati, il che è un vaso di Pandora perché come potrebbe un aggiornatore web riuscire a realizzarlo. Non vogliamo montare socket Docker…
È proprio un bel pasticcio.
2 Mi Piace
Beh, per me non lo erano.
Questo è un confronto tra un’installazione pura di base e situazioni reali?
In effetti, non è perfettamente coerente. Anche con tutto il resto spento, può comunque fallire.
Sfortunatamente stiamo combattendo una battaglia persa contro gli strumenti di build JS moderni qui. Sono tutti progettati per funzionare su 8 GB+ di RAM su macchine per sviluppatori moderne, non su VPS da 1 GB 
Abbiamo alcune soluzioni in mente. Ad esempio: fornire asset precompilati che possono essere scaricati automaticamente. La grande sfida che abbiamo sono i plugin, perché variano su ogni sito e al momento sono strettamente integrati nella build principale.
Ma per ora, una ricostruzione completa della CLI dovrebbe avere un tasso di successo più elevato rispetto a un aggiornamento dell’interfaccia utente web.
8 Mi Piace
Come Jagster, 2 GB di RAM + 2 GB di swap non sono, di fatto, sufficienti per la mia ricompilazione di Docker guidata da CLI. Controllando ulteriormente, gli unici plugin su questa installazione sono docker_manager e discourse-prometheus – nessuno dei quali, mi aspetto, metterebbe un carico imprevisto su ember.
Se le specifiche minime dovessero cambiare, sarebbe un peccato, ma sarebbe molto meglio della situazione attuale, in cui le macchine muoiono inaspettatamente ad ogni aggiornamento.
7 Mi Piace
Se questo è il caso, penso che sarebbe comunque meglio aumentare leggermente le specifiche consigliate. Personalmente, non mi dispiace aggiungere altri 2 (o anche 4) GB di swap se rende le ricostruzioni più affidabili, almeno finché le operazioni quotidiane vanno ancora bene con 2-4 GB di RAM (per comunità piccole e medie).
2 Mi Piace
In effetti l’installazione iniziale è fallita nella mia recente installazione su un’istanza 4c 4g. Ed ha suggerito di creare un file di swap. Ho trovato l’argomento per creare uno swap e ho creato uno swap da 4 GB. Ora tutto funziona come previsto nell’aggiornamento/upgrade web o CLI.
Secondo me potremmo semplicemente dover accettare che Discourse richiede più RAM di quanto non facesse in passato.
3 Mi Piace
Non avrebbe senso zram?
Abbiamo appena implementato questo commit che speriamo possa migliorare la situazione. Fateci sapere come procede! (sarà disponibile nei test superati tra circa 30 minuti)
Testando con un container docker con memoria limitata localmente, ora riesco a ottenere una build riuscita con -m 1600m. Prima di questa modifica, il minimo che potevo ottenere era -m 3000m.
12 Mi Piace
Ho eseguito una ricostruzione di test (installazione pulita), che è andata a buon fine senza problemi. Ora quella macchina ha 4 GiB di RAM (Hetzner CAX11) e un file di swap delle stesse dimensioni, quindi è certamente meno vincolata rispetto alla configurazione 2+2 GB menzionata sopra. Tuttavia, l’uso dello swap è stato minimo durante l’intera compilazione e l’utilizzo massimo di RAM che ho visto è stato di circa 3,1 GB. E per la maggior parte del tempo, è rimasto intorno ai 2 GB, quindi non sembra male (il tempo di compilazione è rimasto più o meno invariato, cioè circa 8 minuti).
4 Mi Piace
Mi piacerebbe molto condurre alcuni esperimenti controllati, con installazioni pulite e ricompilazioni, su una varietà di configurazioni, e in particolare vorrei vedere la differenza (se presente) nell’esecuzione con vm overcommit, ma temo di non aver avuto il tempo.
(Senza overcommit, un processo di grandi dimensioni che esegue un fork avrà un aumento istantaneo dell’impronta di memoria che potrebbe essere fatale, e non apparirà su un monitor interrogato. Anche con l’overcommit, l’aumento della memoria potrebbe essere abbastanza rapido da non apparire su un poll, che sia htop, vmstat o altro.)
Non credo di aver mai visto nessuno dichiarare se sta eseguendo o meno l’overcommit, sebbene a mio parere sia un aspetto importante della configurazione dell’host.
1 Mi Piace
Scommetto che la maggior parte delle persone non lo fa.
Lo imposto automaticamente nelle mie installazioni. Ricevo ancora quell’avviso, tuttavia.
L’overcommit è irrilevante qui, perché il problema non sono i processi che vengono terminati prematuramente dall’OOM, ma semplicemente si cerca di far entrare dieci libbre di memoria allocata in un sacco da cinque libbre.
Non è praticamente possibile eseguire una ricostruzione di Discourse con overcommit_memory=2, perché ember (tra le altre cose, senza dubbio) prealloca enormi quantità di memoria virtuale (se ricordo bene, circa 80 GB è quello che ho visto), quindi questo andrà sempre a infrangere qualsiasi impostazione ragionevole di overcommit_ratio. Anche impostare overcommit_memory=1 non aiuterà, perché, di nuovo, il problema non è un VMM troppo zelante che termina i processi, ma una gestione della memoria orribilmente scarsa da parte del compilatore ember.
1 Mi Piace
Non sono sicuro di essere completamente d’accordo con la tua analisi! Per quanto ne so, l’overcommit consente ai processi di allocare memoria che non utilizzano. Non riguarda solo il comportamento dell’OOM-killer. Ma come dicevo, vorrei condurre alcuni esperimenti controllati, è un modo migliore per vedere cosa fa e cosa non fa la differenza.
Ho 4 GB di RAM e molti plugin (niente file di swap di cui sono a conoscenza). Quanti plugin hai e pensi che 4 GB di RAM semplici siano sufficienti?
Parzialmente corretto, ma comunque irrilevante, perché il problema discusso in questo argomento sono i processi che allocano memoria che toccano, e toccano più di quanto il sistema abbia a disposizione, causando interruzioni visibili ai clienti.
Puoi confermare che dopo le modifiche di @david i requisiti di memoria sono diminuiti? Dovremmo essere in uno stato ragionevole ora.
Il prossimo grande salto sarà la pre-compilazione e gli asset pre-compilati distribuiti, è un cambiamento piuttosto grande per arrivarci ma cancellerà un bel po’ di lavoro da Internet una volta fatto.
2 Mi Piace
Con rispetto, non ne sono sicuro. Ho visto file di log che mostrano errori nell’avvio di processi figli (forking). Stiamo dicendo in questo thread che si tratta di “requisiti di memoria”, ma questo include, a mio avviso, le tattiche del kernel per la memoria virtuale. Chiaramente un esperimento o tre dimostrerà se ho ragione o meno sull’overcommit.
Era una build fresca senza plugin. Posso provare un’altra con alcuni plugin abilitati e forse disabilitare temporaneamente lo swap per confermare che la build va a buon fine (probabilmente ci vorranno alcuni giorni prima di avere tempo, comunque).
2 Mi Piace