Ciao!
Ho Discourse su Docker e non sembra mai utilizzare lo swap quando la RAM è troppo occupata, causando un crash o un messaggio come fatal error: out of memory allocating heap arena map se provo a ricostruire, a meno che non riavvii ogni poche ore. Sembra che non funzioni altrimenti.
Qualcuno sa come risolvere?
Grazie,
Kian
Assumendo che tu sia su Linux, cosa mostra free -h? (Preferibilmente, subito dopo il riavvio e anche poco prima dell’errore.)
Forse swappiness è impostato a 0?
cat /proc/sys/vm/swappiness
Ciao!
Era impostato a 40, ora l’ho portato a 60.
Il sistema memorizza sempre nella cache grandi porzioni di RAM, e lo swap non viene mai utilizzato nemmeno quando la RAM è molto utilizzata.
Credo che le due parti dell’output su cui concentrarsi siano i 5,5 GB di memoria disponibile e i 0 B di swap utilizzata. O forse i 9 GB di swap libera. La somma di 5,5 GB + 9 GB indica quanto margine hai a disposizione. La quantità di memoria utilizzata per buffer e cache è dinamica e non dovrebbe mai causare carenze.
Considerando un tempo di guasto di sole poche ore, suggerirei di eseguire vmstat 5 e catturarne l’output in modo da poter osservare gli ultimi istanti. In passato utilizzavo un job cron per eseguire vmstat 5 5 e scrivere i risultati in un file di log ogni 10 minuti.
È possibile che, in caso di software malfunzionante, vengano consumate rapidamente tutte le risorse disponibili. In tal caso, un log di ps uax eseguito ogni pochi minuti – per ottenere alcune istantanee nei momenti cruciali – potrebbe essere molto utile.
È anche possibile che siano in gioco altri limiti. Immagino si tratti di un’installazione standard su un sistema operativo standard, senza altri processi in esecuzione e senza configurazioni particolari?
Ciao!
Come posso impostare vmstat 5 per scrivere su un log ogni 10 minuti? E come posso fare in modo che ps uax scriva su un log ogni pochi minuti?
Sì, si tratta di un’installazione standard di Ubuntu Server 18.04. Ho installato solo cose come Apache, Docker, ecc.
Ho appena ricordato che ho anche Varnish Cache installato, il che spiega la RAM che viene memorizzata nella cache. Ma non capisco perché Discourse non utilizzi anche lo swap. Ho impostato la sua allocazione qualche giorno fa con un comando Docker per limitare lo swap, ma non ha avuto alcun effetto.
Ecco una riga di comando semplice ed efficace (anche se cron sarebbe un approccio migliore)
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
Esecuzione continua: per fermarlo, usa touch /tmp/stop
Il log verrà salvato in /var/log/monitor.log - usa tail -99 per vedere gli ultimi eventi, oppure less per sfogliarlo. In qualche modo dovrai individuare le sezioni del log che mostrano l’insorgere del problema.
Sembra che tu ti stia ponendo la domanda sbagliata. È il kernel Linux che gestisce la memoria virtuale, inclusi l’uso dei buffer e dello swap. Se free segnala che lo swap è configurato, è tutto corretto e non devi fare nulla.
La tua vera domanda dovrebbe essere: perché Discourse non funziona bene, perché deve essere riavviato e perché sto vedendo l’errore fatal error?
Ti consiglio vivamente di rinominare questo argomento in:
“Perché ‘fatal error: out of memory allocating heap arena map’?”
Inoltre, mi preoccupa che sembri avere diverse osservazioni distinte:
Non è chiaro come queste osservazioni siano correlate.
Sarebbe utile ricevere le tue risposte!
Mmh, cosa hai fatto esattamente? Cosa riportano
docker stats --no-stream --no-trunc
per MEM USAGE / LIMIT e MEM %?
(Nel mio caso, il LIMIT è leggermente inferiore alla memoria fisica della macchina. Forse questo significa che nulla in esecuzione all’interno del container è probabile che causi lo swap, e potresti vedere un processo fallire nell’allocazione della memoria anche quando c’è poco o nessun swap in uso.)
Ciao!
Penso che Discourse si sia bloccato perché quando vado sul dominio ricevo l’errore Nginx 502 Bad Gateway. Tuttavia, il contenitore Docker è ancora attivo.
Sì, tranne in qualche occasione.
L’ho ricreato perché spesso risolve temporaneamente il problema del 502 Bad Gateway.
Ho anche riavviato il server per vedere se risolveva l’errore; spesso funziona, ma è più probabile che non lo faccia, mentre una ricreazione risolve il problema per un po’.
Tra poco ti invierò anche quel registro degli errori.
Quando eseguo /var/log/monitor.log - uso tail -99 ottengo -bash: /var/log/monitor.log: Permesso negato
(Dallo screenshot, vedo che il contenitore chiamato “app” ha un limite di memoria di 7,8 GB e ne sta utilizzando solo il 3%, quindi va bene. Modifica: ma potrebbe essere sospetto che stia utilizzando il 100% della CPU.)
Dobbiamo solo guardare la fine di quel file di log, quindi
tail -199 /var/log/monitor.log
potrebbe fornirci ciò di cui abbiamo bisogno. Ma potrebbe essere necessario esaminarne di più: forse puoi comprimere il file di log e allegarlo o condividerlo in un altro modo. Quanto è grande il file di log?
ls -l /var/log/monitor.log
Credo che il 100% corrisponda a 1 core. Perché il sistema funziona correttamente
log.txt|allegato (25,0 KB)
199 righe del log.
monitor.txt|allegato (39,3 KB)
Ecco il log completo 
Grazie. Tutto sembra a posto, ma si tratta di un singolo snapshot. Ciò che dovrebbe accadere è che ogni 10 minuti venga aggiunto un nuovo blocco al log. Aspetta di vedere il problema con il tuo Discourse, poi condividi gli ultimi blocchi.
Devo dire che non so cosa stia succedendo.
Ho notato che i tuoi 3 unicorni stanno utilizzando molta CPU, e non so perché dovrebbero farlo.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \_ unicorn worker[2] -E production -c config/unicorn.conf.rb
Puoi eseguire top e premere shift+m per ordinare per utilizzo della RAM e vedere cosa sta consumando più RAM. Puoi pubblicare qui il risultato?
