Abbiamo ripristinato tutti i valori modificati ai valori predefiniti e aggiornato alla versione 2.6.0 beta4. Giochi in programma giovedì e venerdì, quindi avremo una buona copertura dei test entro la fine della settimana.
Purtroppo, la correzione non risolve il problema. Avevamo una partita moderatamente attiva con 600 messaggi. Sono stati osservati diversi blocchi durante i miei test, così come da parte dei nostri membri. Questi si correlano con gli eventi di gioco, ovvero picchi di attività.
- L’utilizzo della CPU era ben entro i limiti, con un picco intorno al 60% e un carico medio intorno al 30%.
- Si tratta sicuramente di un problema lato client. Quando l’argomento della chat si blocca, se vai alla pagina principale vedrai il numero di post non letti. Torna all’argomento e i post diventano visibili.
Ciò che mi preoccupa ancora, e che non è trattato in questo argomento, è cosa sia cambiato dalla versione 2.3, che non presentava questo problema?
I principali aggiornamenti 2.4 e 2.5 sono avvenuti durante la nostra stagione morta (estesa a causa del COVID), quindi nessuno ha notato nulla, ma il blocco è stato evidente immediatamente nella prima partita di esibizione della pre-stagione.
Ci sono parametri che possiamo provare a modificare per domani? Sarà un derby intenso e una partita in trasferta, quindi la community sarà in fermento.
Nel nostro caso, disattivare il plugin Who’s Online e disabilitare il file di rate-limiting (e ho letto che ci sono stati alcuni miglioramenti con la beta più recente) sembra aver risolto il problema per noi.
Ora abbiamo anche partite di calcio di tanto in tanto con 300 utenti o poco più che cliccano e scrivono tutti nello stesso argomento contemporaneamente, e sembra che le prestazioni siano state molto migliori durante l’ultima partita.
Sei sulla versione più recente, con la recente correzione?
Per favore, per favore, aggiorna a “test superati”. Ho affinato molte cose da quando è iniziata la beta.
Sì, l’ultima versione beta (cioè fino alle ultime 48 ore).
Aggiornato. Seguirà un rapporto.
Purtroppo, ancora nessun esito positivo. Certo, il gioco è stato intenso con 950 messaggi. Tenevo d’occhio GAnalytics e c’erano circa 250 persone che osservavano, di cui 119 hanno pubblicato. Sono stati rilevati diversi blocchi, come in precedenza. Il message-bus ha restituito alcuni errori 429, con i messaggi “Hai eseguito questa azione troppe volte, attendi X minuti”.
Il carico della CPU ha raggiunto un picco di circa il 70% e non c’è stato praticamente alcun tempo di attesa (wa). Quindi, sebbene l’attività fosse elevata, non siamo ancora in grado di fornire ciò che l’hardware sarebbe in grado di gestire.
Potresti rispondere all’unica domanda che mi ha lasciato perplesso: cosa è stato implementato dopo la versione 2.3 che sta causando questo problema e cosa dovrebbe apportare di nuovo?
L’implementazione è sostanzialmente la stessa di sempre, tranne per il fatto che abbiamo limiti di velocità globali per l’app, configurabili; puoi aumentarli se vuoi, anche se ciò potrebbe causare un collasso totale, non lo so.
Non capisco cosa intendi per blocchi: se ora il sistema è troppo carico, smette di aggiornarsi, ma la differenza è che non è necessario aggiornare la pagina nel browser per risolvere il problema; si riprenderà non appena il server avrà capacità disponibile.
Un po’ poco chiaro qui: i tuoi utenti stanno riscontrando zero miglioramenti dopo le mie modifiche?
Il tuo server ha molta RAM libera? In tal caso, aggiungi worker Unicorn.
Che valore hai impostato per il parametro db_shared_buffers? All’inizio abbiamo riscontrato molti comportamenti “instabili” (alcuni argomenti “consumavano” molte risorse, specialmente quando erano molto partecipati) con solo il 25% consigliato della RAM totale. Quando l’abbiamo aumentato a 16 GB (su 32 GB totali), tutta quell’instabilità è scomparsa… e più recentemente, grazie alle ultime modifiche, la situazione è migliorata ulteriormente.
Ok, quindi questo fenomeno è difficile da monitorare in un ambiente di produzione (chat di gioco), poiché ogni gioco è diverso: numero diverso di eventi critici, avversario diverso, diversa carica emotiva e così via.
Il problema dal nostro punto di vista è che la nostra capacità massima di servizio è diminuita dalla versione 2.3. Questo è il punto chiave. Ogni server ha i suoi limiti, ma ora ne stiamo ottenendo meno rispetto a marzo, quando eseguivamo la 2.3. In base a un monitoraggio approssimativo del back-end, il server non riesce a raggiungere il 100% del carico o della capacità.
Ciò che gli utenti finali vedono è che il flusso della chat si interrompe semplicemente, senza alcuna indicazione nell’interfaccia utente su cosa stia accadendo. Questo crea confusione.
Sono abbastanza certo che le modifiche nei test superati abbiano migliorato la situazione, ma le prestazioni o l’output massimo sono ancora significativamente inferiori rispetto alla versione 2.3.
Abbiamo un VPS con 6 core veloci e 16 GB di RAM. I processi Unicorn sono impostati a 12, e le impostazioni relative al buffer della RAM sono sui valori predefiniti.
Credo che il passo successivo migliore sia impostare il monitoraggio storico del tuo sistema, così da poter individuare dove si trova il collo di bottiglia, dato che abbiamo stabilito che non è legato al tempo della CPU. È sempre possibile che tu stia saturando la tua connessione di rete!
più metriche server tradizionali come node-exporter.
Se questo è il caso e desideri spingerlo di più:
-
Puoi ridurre i limiti di velocità, consentendo agli utenti di interagire in modo più aggressivo con Discourse. Nello specifico, potresti raddoppiare
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEeDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
Puoi provare ad aggiungere più worker unicorn.
Ciò è temporaneamente atteso mentre sei sovraccarico, ma le cose dovrebbero riprendersi automaticamente non appena il carico diminuirà.
La mia ipotesi è che tutto ciò sia legato ai limiti di velocità: questi sono nuovi e servono a proteggere il server. Sembra che il tuo server stia essendo protetto per progettazione.
Abbiamo provato una partita con…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…e quando le emozioni hanno iniziato a scaldarsi nel terzo periodo, le cose sono peggiorate. Abbiamo raggiunto i limiti dei nostri server, gli utenti venivano costantemente disconnessi e anche la chat di gioco si bloccava.
È stata una grande storia di successo per 4 anni, ma ora ci troviamo in una situazione molto difficile. Passare al livello successivo di capacità VPS ci porterebbe nella fascia di prezzo di circa 160€/mese, una sfida per un sito amatoriale. Non stiamo parlando nemmeno di volumi di utenti enormi: 116 persone hanno pubblicato oltre 800 messaggi durante la partita.
L’ideologia del “non fare chat” non è adatta. Se non avessimo quelle, i post di reazione emotiva si disperderebbero in tutti i temi più “seri”. Sono uno strumento importante per canalizzare l’energia emotiva della situazione dal vivo in un unico argomento, mantenendo puliti i temi più analitici.
Il mio è un forum di calcio e ho riscontrato sfide simili.
In sostanza, ho scoperto che si trattava di un problema di scalabilità.
I problemi per me si sono manifestati a diversi livelli.
Digital Ocean
1 CPU e 1 GB = 30-40 utenti in una situazione simile a una chat
2 CPU e 2 GB = 70-80 utenti in una situazione simile a una chat
4 CPU e 8 GB = adatto per 120 utenti e 1000 post in 2 ore. Non ho raggiunto il limite.
Sto provando diversi livelli di potenziamento con Hetzner (sito di mirror) perché più economico, ma non è andato liscio come speravo.
La mia esperienza finora è:
3 CPU (chip AMD CPX 21) e 4 GB = in difficoltà con 20 utenti
2 CPU (Intel) e 8 GB = nessun problema con 20 utenti.
Sto per testare con 80-100 utenti simultanei in condizioni di partita.
Quando ho controllato l’utilizzo della CPU su Digital Ocean, anche sotto stress l’utilizzo della CPU sembrava piuttosto basso, inferiore al 50% in ogni momento e a tutti i livelli.
Quando ho controllato la CPU per Hetzner con il chip AMD, ho visto un’utilizzazione mediana della CPU di circa il 60%, ma ogni minuto o poco più si verificava un breve picco fino al 300% dell’utilizzo della CPU. Questo non sembrava verificarsi con il chip Intel.
Non so cosa significhi tutto questo. Sospetto che il monitoraggio della CPU sia migliore su Hetzner (rilevando i brevi picchi). Ma nel complesso l’utilizzo della CPU sembra ben bilanciato. Digital Ocean, a prima vista, sembra gestire meglio i picchi, ma dopo questo weekend dovrei avere più informazioni su Hetzner.
Dovrei anche aggiungere che, con il test di Hetzner, il plugin ‘Whose Online’ non ha fatto alcuna differenza.
Ma il plugin ‘Quick Messages’ di Discourse sembra essere stato dannoso.
La prossima partita è prevista per domani. Abbiamo rimosso le nostre modifiche interne e stiamo provando con queste impostazioni.
Inoltre, come tentativo estremo, ho aumentato db_shared_buffers da 4 GB (25%) a 6 GB (37,5%). Ho anche sbloccato la riga db_work_mem da 40 MB in app.yml (tra l’altro, questa è un’opzione scarsamente documentata, sebbene venga presentata all’amministratore come un’opportunità di miglioramento).
Non mi aspetto più di trovare una soluzione definitiva al problema, ma solo di mitigare i danni: un insieme di parametri che abbia il minor impatto negativo sull’esperienza utente finale. Nel frattempo, dovrò valutare le possibilità per aumentare ulteriormente le risorse del nostro hosting.
Domanda per @sam e altri sviluppatori.
Come influisce la dimensione in continua crescita del database su questo caso d’uso, in cui gli utenti martellano un singolo argomento per un paio d’ore?
Ho dato un’occhiata all’attività storica delle chat di gioco e ho notato che nel 2017 avevamo partite con statistiche enormi, quando il nostro server aveva una frazione delle risorse che abbiamo oggi. Avevamo partite in cui il numero di post raggiungeva le 1600 messaggi da parte di 165 utenti e nessuno si è lamentato delle prestazioni. Ora non riusciamo a gestire nemmeno la metà di quello, con un server molto più potente.
Potresti provare ad aumentarla a 80MB. Forse invece dell’altra modifica.
Questo è un punto su cui stiamo lavorando attivamente in continuazione.
Quando Discourse era nuovo, quasi tutti i siti avevano un database appena creato, quindi il database poteva stare facilmente in memoria. Ora, a distanza di qualche anno, alcuni siti hanno database superiori a 100 GB e dimensioni della RAM che non sono nemmeno un decimo di quelle.
Uno degli aggiornamenti in arrivo nelle prossime settimane è l’aggiornamento a PostgreSQL 13, che ridurrà a metà la dimensione dell’oggetto più grande.
Oltre a ciò, il primo passo per diagnosticare i problemi di prestazioni è raccogliere dati con il plugin Prometheus exporter per Discourse, così da non procedere alla cieca.