Sto ospitando tutti i miei file caricati su uno storage NAS (glusterfs).
Recentemente ho scoperto che c’è un traffico di rete enorme e costante sul NAS. E ho risalito la causa a Discourse che richiede immagini ottimizzate. Esiste un processo che cerca costantemente queste immagini? Perché? E come posso disattivarlo?
btw la pulizia delle impostazioni del sito di caricamento è disabilitata nel mio forum.
Forse il riempimento @david ha aggiunto per la ricerca del colore primario dell’immagine.
Alla fine finirà e tornerà a uno stato stabile
Dobbiamo scorrere tutte le immagini per il riempimento, potresti essere in grado di aggirare il problema forzando il colore di tutte le immagini a bianco o qualcos’altro
Per quanto vedo,
Sta lavorando su 25 immagini ogni 15 minuti. sì? questo dovrebbe essere molto trascurabile. Vedo migliaia di file cercati ogni minuto.
E guardando anche la larghezza di banda di 6 mesi fa, vedo lo stesso comportamento. Quindi penso che dovrebbe essere qualcos’altro.
Tuttavia, sono abbastanza sicuro che sia fatto da un job di discourse o qualcosa di simile, perché quando fermo l’app di discourse, la larghezza di banda scompare. Tuttavia, quando fermo solo l’app nginx di discourse, la larghezza di banda rimane.
Dai un’occhiata in /sidekiq dovrebbe dirti quali processi sono in esecuzione, assicurati di fare clic su tutte le schede
Nessun processo è in esecuzione. 
. Ci sono altri processi che non verrebbero elencati qui?
O forse c’è qualcosa nel container che tenta di indicizzare i file?
Tutta la nostra logica di background avviene sui job di Sidekiq. Se nessun job è in esecuzione e hai ancora un I/O del disco elevato, potrebbero essere gli utenti che visitano il tuo sito web e le immagini servite da nginx?
Hai una CDN di caching che gestisce gli asset statici?
Ho già testato questo in precedenza.
Quindi non è perché gli utenti visitano il sito web. Se così fosse, quando ho interrotto nginx, il traffico sarebbe dovuto scomparire.
Dovrai utilizzare gli strumenti di ispezione di Linux per vedere esattamente quali PID e syscall vengono effettuati.
@Falco @sam Penso di aver trovato la causa principale.
Per prima cosa ho riavviato l’app discourse in modo che il traffico costante se ne vada. Poi sono andato nel pannello di amministrazione e sono andato alla sezione per i report in blocco. È da molto tempo che i report non vengono visualizzati correttamente qui:
Subito dopo che i report vanno in timeout, vedo il picco nella larghezza di banda della rete. E vedo questo errore nei log degli errori:
'hijack admin/reports bulk' è ancora in esecuzione dopo 90 secondi sul db predefinito, questo processo potrebbe dover essere riavviato!
Cosa sta andando storto qui?
Il database si trova nello stesso storage NAS?
No, il database si trova sul disco SSD fisico.
Solo la cartella di caricamento è sul NAS.
Quindi non c’è correlazione tra questi. Tornando a
In realtà penso che forse c’è una correlazione. nel mio ambiente di test qui calcola lo spazio utilizzato.
Penso che calcolare lo spazio utilizzato su una cartella NAS con molti file richiederebbe molto tempo e sarebbe la causa principale dell’elevata larghezza di banda.
Ho ragione?
L’esecuzione di
df -Pk
df -P
du -s
richiede una quantità significativa di tempo sulla condivisione di rete?
Questi due sono stati istantanei
df -Pk
df -P
Tuttavia du -s ha prodotto un comportamento simile a quello che ho segnalato sopra.
Ed è stato in esecuzione per circa 5 minuti e non è terminato e ho dovuto interromperlo manualmente.
Capisco. Il risultato di quel report è memorizzato nella cache, ma immagino che non finisca mai e non possa essere memorizzato nella cache perché la tua condivisione di rete è troppo lenta.
C’è qualcosa che possiamo fare per evitarlo? Ad esempio, trattarlo come caricamenti s3 in cui non calcoliamo la dimensione del disco
