Potrebbe indicare che UNICORN_WORKERS è impostato troppo alto/basso?
Il server ha 64 GB di RAM (solitamente mostra circa 40 GB liberi) e 6 core, ci sono 4 istanze di Discourse sul server, ognuna impostata su UNICORN_WORKERS: 8.
Avete idee o suggerimenti su cosa lo stia causando o cosa provare? (Uno dei forum è in modalità di sola lettura e non riceve molto traffico, dovrebbe essere impostato per avere meno worker?)
Grazie per le risposte a tutti - non sono sicuro di dove l’abbia letto ora, ma ho sempre pensato che dovessimo impostare 2 worker per core. Ho ridotto i worker ora per forum, assegnandone di più ai forum più trafficati e meno a quelli meno trafficati. Monitorerò le cose la prossima settimana e riferirò se non ha aiutato.
Nel tuo caso, tuttavia, non stai allocando due worker per core. Hai sei core, il che significherebbe dodici worker, ma hai quattro istanze che utilizzano ciascuna otto worker, quindi 32 in totale.
Sì… ho regolato in modo che il numero totale di worker non sia maggiore del doppio del numero di core, anche se mi chiedo ancora: qual è il consiglio corretto/standard, quello che hai detto tu o quello che c’era nel post di Nate, dove cita Jeff dicendo 1 worker per core?
Dai miei esperimenti, 1 worker per core causa timeout (ma riduce il carico del server), più worker portano a prestazioni migliori ma a un carico maggiore (che sul mio server è ancora entro un intervallo accettabile).
Dai un’occhiata a discourse-setup, che gestisce lo scaling per le nuove installazioni oggi:
# UNICORN_WORKERS: 2 * GB per 2GB o meno, o 2 * CPU, max 8
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
La seconda istruzione, che utilizza il doppio del numero di core disponibili, è l’impostazione predefinita sui sistemi con più di 2 GB di RAM. Sembra che il tuo problema sia più dovuto a un tira e molla tra le tue istanze (risorse host), piuttosto che a un problema di discourse.
Sto vedendo la stessa cosa dopo il mio ultimo aggiornamento, che è avvenuto un giorno dopo l’OP, quindi non credo che questo abbia nulla a che fare con il numero di worker di unicorn. Il processo unicorn.conf.r* è sospetto, perché il post originale di questo argomento è l’unico risultato per quel termine sull’intero web. Credo che unicorn.conf.rb sarebbe più normale.
Ho utilizzato lo stesso numero di worker di unicorn sulla stessa istanza per diversi anni e non ho cambiato nulla, ho solo ricostruito a 3.4.0.beta4-dev.
Ho appena effettuato l’aggiornamento all’ultima versione di Discourse e non ho più visto unicorn.conf.r* (ora qualsiasi cosa intorno all’80% di utilizzo della CPU è solo ruby, anche se sembra meno frequente). I carichi sono più o meno gli stessi (anche se inferiori rispetto a quando ho apportato quelle modifiche ai worker).
Ti sei aggiornato all’ultima versione? Che tipo di hardware hai e quanto è trafficato il tuo forum?
Sì, sono alla versione 3.4.0.beta4-dev. È quello che ha iniziato l’elevato utilizzo della CPU. Non è cambiato nient’altro.
8 GB di RAM, 2 vCPU, SSD da 160 GB con molto spazio.
Ho pubblicato l’utilizzo della CPU sopra per il mio sito di produzione, che ha circa 30 utenti online contemporaneamente. Ma ho un sito di test con lo stesso problema e non c’è assolutamente traffico né plugin. Utilizzo della CPU prima e dopo l’aggiornamento (i picchi sono i backup giornalieri):
Non sono sicuro che le nostre situazioni siano correlate, Mark. Penso che nel mio caso ciò che ha detto Stephen abbia giocato un ruolo importante:
Recentemente ho spostato altre due istanze sullo stesso server e avevo effettivamente dimenticato che i worker di unicorn erano impostati su 8 perché in precedenza eravamo su un server con più core (ma aveva i suoi problemi, motivo per cui siamo tornati a uno Xeon che aveva meno core ma funzionava meglio nel complesso).
Quindi, quello che ho scoperto è che ridurre i worker di unicorn su questo server ha ridotto il carico, ma ha iniziato a darci timeout, aumentarli ha eliminato i timeout ma ha comportato un carico maggiore, sebbene ancora entro un intervallo accettabile. Penso di poter aumentare i worker e potremmo comunque gestire il carico aumentato, ma quello che abbiamo ora va bene per il momento.
Detto questo, avevo spostato le istanze sullo stesso server e stava funzionando entro ciò che mi sarei aspettato (quindi il carico è aumentato ma non di molto) e sembrava che un aggiornamento avesse comportato carichi maggiori… tuttavia non posso esserne sicuro, e dobbiamo tenere presente che di tanto in tanto, con Discourse che ottiene più funzionalità, potrebbe richiedere hardware più potente o comportare a volte una sensazione di “lentezza” (avevo alcune istanze di Discourse su vecchie versioni e sembravano notevolmente più scattanti, anche se ovviamente non avevano tutte le funzionalità delle versioni più recenti).
Detto questo, penso che i carichi siano effettivamente diminuiti un po’ dall’ultimo aggiornamento di Discourse (con PG 15).
Non sono sicuro di cosa suggerire per te Mark, magari gioca con i worker e anche con alcune altre impostazioni? Come db_shared_buffers e db_work_mem? Forse avvia un thread dedicato del tipo “Utilizzo elevato della CPU dopo l’aggiornamento - la mia istanza necessita di ottimizzazioni delle prestazioni?” O qualcosa del genere
Mi sono aggiornato stasera e ho subito notato una differenza nell’utilizzo della CPU sul mio sito. Ecco un grafico di prima, durante e dopo l’aggiornamento. Questo rappresenta una durata di un’ora.
Ecco i risultati dopo 15 ore dall’aggiornamento. La percentuale di utilizzo della CPU è aumentata drasticamente di 3 volte. Il fattore di carico è aumentato di 4 volte.
Quindi sembra che il mio problema non fossero i worker unicorn, dopo tutto: dopo l’aggiornamento di @sam che segue il thread di @LotusJeff, i carichi del server sono tornati a quelli che erano (meno della metà di quelli che erano aumentati)…
Probabilmente non me ne sarei accorto se non avessi tenuto d’occhio il server dopo aver recentemente spostato gli altri due forum su di esso: mi chiedo quante persone ne siano state interessate senza nemmeno rendersene conto?
Il team di Discourse ha messo in atto delle misure per avvisarli di problemi come questo? Forse un programma di volontariato che gli amministratori possono impostare per argomenti specifici, ad esempio, “Invia i carichi del server a Discourse entro XX ore/giorni/settimane prima/dopo un aggiornamento”? O ancora meglio, monitorare questi problemi a livello locale e quindi avvisare gli amministratori quando vengono notati aumenti del carico del server dopo gli aggiornamenti, che possiamo quindi pubblicare qui, se necessario.
Probabilmente non avrei notato l’impatto, ma sto monitorando attentamente il server perché ci siamo migrati a Discourse circa 2 settimane fa. Sono immerso in varie validazioni post-migrazione (esecuzione di backup, ecc.). Dopo un paio di mesi, non avrei mai notato l’impatto.
Spero che Discourse abbia un test di carico giornaliero in esecuzione. Nella mia vita passata, avevo un server che veniva ricostruito quotidianamente con codice committato. Aveva utenti simulati che utilizzavano il server tutto il giorno. Abbiamo misurato le metriche chiave delle prestazioni dal punto di vista dell’utente e dal punto di vista del server. Ci ha permesso di individuare in modo proattivo perdite di memoria, codice inefficiente e modifiche impreviste all’UX.
Devo ancora fare i complimenti a Sam e al team. Provenendo dal mondo di phpBB, dove qualcosa del genere richiederebbe decenni per essere risolto e rimediato, ho trovato la risposta rapida fantastica. (Anche se significava rimanere alzato fino alle 2 del mattino CT rispetto all’ora di Sydney.)
