Ciao a tutti,
abbiamo aggiornato il nostro server CentOS 7 dalla versione 2.2.2 alla 2.7.0.beta4 e da allora riscontriamo latenza nel caricamento delle pagine. In particolare nelle pagine che coinvolgono contenuti del database o immagini, al punto da renderle inutilizzabili.
Qualsiasi indicazione in merito sarebbe molto apprezzata.
Negli ultimi anni sono accadute diverse cose. C’è stato un cambiamento nel bug che richiede l’elaborazione di tutte le immagini. Sospetto che il tuo server sia sovraccarico mentre svolge questo lavoro. Puoi dare un’occhiata a /sidekiq per vedere la coda.
Quanto è grande il tuo database? Quante immagini ci sono? Cosa mostra sidekiq? Stai usando un SSD, giusto?
È un server basato su VM, quindi non sono sicuro se sia SSD o meno.
Non vedo Sidekiq accessibile, dato che questa distribuzione non è stata eseguita da me, quindi non so come accedervi.
Sai come è stato installato? Sembra che non si tratti di un’installazione standard (altrimenti, se fossi un amministratore, /sidekiq sarebbe disponibile per te).
Il modo migliore per procedere è indagare sul motivo del calo delle prestazioni. Nel corso degli anni sono state aggiunte molte attività in background (ottimizzazione delle immagini, rebaking, ecc.) che probabilmente sono ora in esecuzione e stanno utilizzando le risorse del tuo server. Una volta completate, le prestazioni dovrebbero migliorare.
Accedere a /sidekiq (utilizzando un account amministratore!) per scoprire quali attività sono in esecuzione è un ottimo primo passo.
Ok, sono riuscito ad accedere a Sidekiq. Potete aiutarmi a capire questa situazione e suggerire eventuali ottimizzazioni? Mi trovo in una situazione piuttosto difficile a causa di questi problemi di prestazioni.
Il comportamento che osservo sul server è che continua a mostrare questa coda vuota, anche quando provo ad aprire un post per vederlo elencato. Inoltre, il portale Sidekiq si blocca durante il caricamento del post e si aggiorna solo quando il post è completamente caricato.
Inoltre, una volta caricato, mostra ancora una volta una coda vuota. Qualsiasi aiuto o suggerimento sarebbe molto apprezzato.
Se la coda è vuota, allora non hai il problema di molti job in esecuzione in background. Quindi è qualcos’altro.
Hai dei plugin? Hai componenti del tema che effettuano molte chiamate API?
Ho fatto alcune altre domande sopra.
Quanto è grande il tuo database?
Quante immagini contiene?
Hai componenti del tema che effettuano molte chiamate API?
Potresti dirmi come posso ottenere queste informazioni da una configurazione basata su Docker? So che l’ultimo backup è di 135 MB.
Per quanto riguarda i plugin, sì, abbiamo questi plugin elencati:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Consiglio di rimuovere il plugin Mermaid.
Quanti post e utenti hai? Traffico?
Quanta RAM hai?
Sembra che tu possa stare tranquillo con un droplet DigitalOcean da 2 GB; potresti crearne uno e vedere come funziona.
Forse c’è qualche altro problema con il tuo server? È aggiornato? È stato riavviato di recente?
Ok, la rimuoverò.
Abbiamo circa 4.000 post e circa 350 utenti.
Il numero medio di utenti connessi contemporaneamente non è molto alto, forse 5-10 al massimo in media.
Questo server è stato avviato di recente e dispone di 8 GB di RAM e 10 GB di spazio di swap. Attualmente è attivo da soli 13 giorni. Tuttavia, i problemi di prestazioni si verificano indipendentemente dal riavvio e dal tempo di attività.
C’è sicuramente qualcosa che non va nella tua installazione; con questo hardware dovresti ottenere prestazioni molto migliori.
Prova a eseguire un vacuum esplicito su PostgreSQL. Se stai usando l’installazione all-in-one in container:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Digita "help" per ricevere assistenza.
discourse=# VACUUM ANALYZE;
VACUUM
Quanti worker Unicorn hai configurato nel tuo file app.yml?
Puoi chiedere a Discourse di includere ulteriori intestazioni di performance nelle risposte aggiungendo quanto segue alla tua sezione env:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Nel frattempo, puoi attivare miniprofiler seguendo questo post.
Dovrebbe essere più che sufficiente.
Non ricordo se è stato suggerito di rieseguire discourse-setup per regolare l’utilizzo della memoria di Discourse, o se queste impostazioni predefinite siano ragionevoli considerando tutto il resto che utilizza il server.
Se non hai reindicizzato il database dopo l’aggiornamento a PG13, potresti dare un’occhiata a Aggiornamento PostgreSQL 13 per alcune informazioni al riguardo.
Sì, la mancanza di statistiche sulle tabelle (VACUUM ANALYZE) è molto probabilmente la causa principale.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
Quindi ho eseguito questi comandi e ho impostato anche l’intestazione nell’ambiente, ma non noto molta differenza nei tempi di caricamento della pagina.
Sto utilizzando 8 unicorni.
Hai eseguito quei comandi su PostgreSQL, giusto?
Sì, ho eseguito docker exec -it -u postgres app psql discourse prima di eseguire i comandi sopra indicati.
Beh, è tutto molto strano. Nessuno ha avuto problemi simili. Sembra che tu abbia hardware sufficiente. L’unica mia ipotesi è un problema con un reverse proxy (immagino che sulla macchina ci siano altre cose?).
sì, un altro servizio basato su Docker. Ma nulla di davvero intensivo dal punto di vista delle prestazioni, poiché ciò si sarebbe riflesso nelle metriche di prestazioni della macchina.
