Quindi tutte le affermazioni secondo cui il UNICORN WORKER dovrebbe essere 2*vCPU sono sbagliate?
Il mio server è Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB Ram
Quanti UNICORN WORKER devo impostare?
8? o 48?
Il mio sito ha più di 7.000 utenti e circa 1.000 utenti attivi giornalmente. gli utenti inviano da 3.000 a 7.000 post al giorno. la nostra community ha 120.000-200.000 visualizzazioni di pagina al giorno, inclusi crawler e utenti anonimi.
Ciò dipende da molti fattori. Come la dimensione del tuo database rispetto alla tua RAM, il rapporto tra traffico di utenti autenticati e anonimi, se hai plugin che mantengono la tua coda Sidekiq più occupata, se stai eseguendo YJIT, ecc.
Ciò che è semplice è guardare i dati di MiniProfiler durante la tua ora di punta e navigare nel forum per vedere se le prestazioni sono peggiori e identificare il collo di bottiglia.
Poiché questa CPU è più vecchia, inizierei con un numero maggiore del solito di worker Unicorn, poiché ogni richiesta richiederà più tempo del solito. Ma se stai eseguendo PostgreSQL e Redis sullo stesso server, non puoi affamarli eseguendo troppi worker.
Prova a eseguire 16 worker per iniziare e valuta come sta funzionando il sito.
Esiste una descrizione semplice e comprensibile di cosa fanno i worker Unicorn? L’impressione che ho è che ogni richiesta di pagina dell’utente debba passare a un worker Unicorn per essere gestita. Se non ne hai abbastanza, l’utente deve aspettare. Se ne hai troppi… beh, forse ti costa un po’ di RAM?
Sono i server web dell’applicazione.
1 Mi Piace
Sembra che la tua CPU di 10 anni stia mostrando la sua età. Aumentare i worker di Unicorn ti permetterà di servire più utenti contemporaneamente, ma non renderà più veloce una singola richiesta.
Puoi provare ad abilitare YJIT?
3 Mi Piace
Con il tuo hardware mi aspetterei di ottenere un tempo medio di elenco/ultimo accesso registrato di circa 150 ms per l’app, 80 ms per SQL.
Inizierei con 12 worker e vedrei come si comporta. La cosa migliore che puoi fare è monitorare le metriche; se vuoi sapere se dovresti aggiungere altri worker, controlla se le richieste sono in coda in attesa dei worker dell’app.
Stai monitorando le metriche che Discourse stesso esporta tramite l’esportatore Prometheus? Queste ti daranno una buona visione delle prestazioni complessive dell’istanza.
Quali sono i numeri di prestazioni per gli utenti anonimi e regolari (non amministratori)?
5 Mi Piace
Ci sono molti mega argomenti nel nostro Discourse, e il più grande è già nella dodicesima sezione.
Visualizzazioni delle risposte
1 Mi Piace
(/smette di ridere, accede al provider di hosting … )
wow, non è questa la predefinita ormai??
edit: ah certo potresti aver compilato con un vecchio app.yml e non averlo aggiornato da allora
1 Mi Piace
È nel nostro hosting, ma è piuttosto difficile renderlo un default poiché le persone potrebbero operare in scenari con RAM limitata…
Detto questo, la nostra build JS utilizza molta più RAM di Discourse stesso, quindi si potrebbe dire che chiunque sia in grado di creare gli asset JS ha molta RAM da vendere 
1 Mi Piace
In queste immagini, quanti worker hai impostato?
Direi che dovresti
- Aumentare un po’ i worker, dato che si crea un po’ di coda
- Abilitare YJIT, dato che il tuo tempo web è piuttosto lento
Ci sono solo 8 worker ora e YJIT è già abilitato.
Quanti worker dovrei aumentare?
A proposito, ecco cosa stava guardando Falco per fare quella raccomandazione:
Suggerirei di aumentare da 8 a 12. Ti darà un po’ di margine e dovrebbe svuotare quelle code.
Quello spike elevato, a proposito, è indicativo di altre richieste in attesa di… qualcosa, probabilmente un lock comune. Forse un megatopic.
Se riesci a ottenere anche le metriche di utilizzo di postgres, sarebbe utile.
i megatopic sono un punto debole, vedi Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Considera di dividerli o di usare la chat invece (vedo che il tuo più grande con 8,9k risposte è esplicitamente una chat room).
La cultura di discussione della nostra community è megatopici, formatasi ancora prima che iniziassimo a usare Discourse, e la chat manca delle funzionalità di spoiler sfocati e dettagli nascosti.
1 Mi Piace
Come fare
Utilizziamo GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus, anche se non sono sicuro che ci siano guide su meta per la sua configurazione.
Tuttavia, dato che sembra che tu abbia già configurato Prometheus, sembri sapere cosa stai facendo.
ora la RAM del server è 16/32GB, UNICORN_WORKERS: 12, db_shared_buffers: “4096MB”
Poiché c’è ancora RAM disponibile e poche richieste web in coda, ho aumentato UNICORN_WORKERS a 24. Nel pomeriggio di oggi, il server si è improvvisamente spento e dopo essere stato riavviato, gli utenti sono arrivati immediatamente. Ciò ha portato a un numero molto basso di Richieste Web Attive e a un gran numero di richieste in coda. Pochi giorni fa, abbiamo osservato che 24 UNICORN_WORKERS potevano gestire oltre 150 Richieste Web Attive, ma solo 30 Richieste Web Attive questo pomeriggio. Questo perché abbiamo appena cambiato dominio e ci sono molti post che vengono ribattuti da sidekiq. Ciò ha causato molta pressione sul server. Cosa dovremmo fare?
