Risoluzione dei problemi di un sito lento che fino a stamattina era piuttosto veloce

Come posso procedere per risolvere i problemi di un sito che è diventato lento (senza motivo apparente) oggi?

L’utilizzo delle risorse è molto basso:


Questo è un droplet da 16 GB di memoria / 4 vCPU AMD / 200 GB di disco / SFO3 - Ubuntu 24.04 (LTS) x64 con il 30% del disco utilizzato.

Lo stato del servizio di DigitalOcean Service status è stato normale per tutto il giorno.

Il sito lento è stato segnalato in varie località dagli utenti.

yaml:
UNICORN_WORKERS: 8
db_shared_buffers: "1024MB"
db_work_mem: "40MB"

Ho ricostruito all’ultima versione e ho dato a Sidekiq più memoria UNICORN_SIDEKIQ_MAX_RSS: 1000

Alcuni errori 429 nella console:


Il log degli errori degli ultimi 3 giorni:

1 Mi Piace

cosa succede in modalità provvisoria?

1 Mi Piace

Non ricevo errori nella console in modalità provvisoria, ma è molto più lenta. Ci vogliono circa 10-15 secondi per caricare qualsiasi cosa e le immagini si bloccano come se stessero arrivando tramite un modem da 14,4 Kbps.

Ci sono voluti circa 20 secondi per caricare /logs. Tornare a /admin ha richiesto circa un minuto.

Un “poll” sembra richiedere molto tempo:

A proposito, questi sono i plugin in esecuzione:

1 Mi Piace

Ecco un paio di altri dati di questa mattina. Sidekiq sembra tranquillo:

Grafico della memoria interessante: dopo la ricostruzione dell’app è circa il 20-30%, poi salta al 46% durante un backup e rimane lì:

Hai installato il famigerato componente del tema “badges in posts”?

4 Mi Piace

Questo?\n\n

8 Mi Piace

Wow! Notte e giorno dopo aver rimosso il componente Post Badges. Disabilitarlo non ha fatto differenza, ma eliminarlo sì. Niente più errori nella console.

Grazie @Falco!

5 Mi Piace

Beh, temo che non fosse quello, o almeno non tutto.

Ora vedo immagini corrotte e questo nella console:

Ancora caricamento lento o non caricamento affatto con lo spinner attivo…

1 Mi Piace

Mi chiedo se questo abbia a che fare con il problema:

Ho ripristinato Discourse da un backup circa 4 settimane fa quando l’ho spostato da un vecchio droplet Ubuntu 16.4 LTS a uno nuovo con Ubuntu 24.04. Non ho fatto un rebake manuale.

2 Mi Piace

Diventa sempre più strano. Questo accade passando da /logs a /admin cliccando sul link “Back to site”.

1 Mi Piace

C’è stato un altro argomento recente con l’errore “no route named admin”.

Forse anche questo è correlato a Cloudflare

2 Mi Piace

Hmm. Il mio non usa Cloudflare, ma ho visto un’intestazione duplicata in Chrome, come nel primo post lì.

Ho appena ricostruito senza plugin oltre a docker_manager, quindi vi farò sapere come si comporta.

Un’altra cosa da notare è che quando si blocca in Chrome, ho dovuto chiudere quella scheda e aprirla in una nuova. Il ricaricamento forzato non ha fatto nulla.

1 Mi Piace

Ora il backup notturno su S3 sta fallendo senza alcuna modifica nella configurazione:

[2024-10-10 15:03:04] Uploading archive...
[2024-10-10 15:14:33] EXCEPTION: multipart upload failed: Net::WriteTimeout with #<TCPSocket:(closed)>

EDIT: Due backup attivati manualmente sono falliti con lo stesso errore sopra, ma poi due backup manuali sono riusciti. Il tutto senza modifiche alla configurazione. :person_shrugging:

1 Mi Piace

Non vedo errori nella console, solo tempi di caricamento molto lenti in modo intermittente:

Discourse Doctor sembra funzionare correttamente in un’esecuzione, poi in una seconda esecuzione segnala che la porta 587 è probabilmente bloccata, il che è strano perché ha inviato l’email di prova nella prima esecuzione e poi di nuovo con successo nella terza esecuzione:

Connessione alla porta 587 fallita.
====================================== SOLUZIONE =======================================
Il problema più probabile è che il tuo server abbia bloccato il traffico SMTP in uscita.
Se stai utilizzando un servizio come Mailgun o Sendgrid, prova a utilizzare la porta 2525.

Ho ragione a pensare che ci sia qualcosa di strano con questa droplet DigitalOcean?

Sembra che questa droplet abbia alcuni problemi di rete: il download è piuttosto lento, ma nota la velocità di upload :scream::

speedtest-cli
Recupero della configurazione di speedtest.net...
Test da Digital Ocean (24.199.xxx.xxx)...
Recupero dell'elenco dei server di speedtest.net...
Selezione del miglior server in base al ping...
Ospitato da Next Level Infrastructure (Santa Clara, CA) [4,38 km]: 2,242 ms
Test della velocità di download................................................................................
Download: 839,25 Mbit/s
Test della velocità di upload......................................................................................................
Upload: 1,27 Mbit/s
1 Mi Piace

Ecco la felice conclusione di questa saga…

Dopo aver eseguito i test di velocità di rete speedtest-cli e iperf3 che hanno mostrato velocità abissalmente lente tra il droplet e il mondo esterno, ho chiesto a DigitalOcean di indagare e hanno concluso, dopo aver effettuato i propri test:

Abbiamo scoperto alcuni problemi con l’hypervisor in cui si trova il tuo Droplet. Stiamo lavorando con il nostro team di backend per migrare il tuo Droplet su un altro hypervisor.

Tutto è di nuovo a posto.

3 Mi Piace

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.