Aumento dell'uso della CPU dopo l'aggiornamento a 3.4.0.beta4-dev (58f75ed205)

Supporto
1

Ho riscontrato un notevole aumento dell’utilizzo della CPU da quando ho effettuato l’aggiornamento questo fine settimana. L’utilizzo della CPU di RUBY sembra essere il driver principale. Questo è stato segnalato da un altro utente di discourse in questo topic.

Come puoi vedere dai grafici sottostanti, l’utilizzo della CPU e il carico prima dell’aggiornamento erano molto inferiori rispetto a quelli post-aggiornamento. L’aggiornamento è avvenuto la sera del 31/1.

The image shows graphs depicting CPU and Load percentage from 27 January to 2 February. (Captioned by AI)
The image shows graphs depicting CPU and Load percentage from 27 January to 2 February. (Captioned by AI)985×619 68.1 KB

Ecco due immagini di TOP scattate a distanza di 33 ore:

TOP data from 2/1 @ 1:00pm CT
TOP data from 2/1 @ 1:00pm CT689×219 9.92 KB

TOP data from 2/2 @ 9:45pm CT.
TOP data from 2/2 @ 9:45pm CT.649×192 8.48 KB

In 33 ore, c’è un significativo utilizzo della CPU di ruby. Sulla base dei dati di top, ho riscontrato un utilizzo della CPU 2 volte superiore nelle ultime 33 ore rispetto a 22 giorni. In 33 ore, ho riscontrato 11 ore di tempo CPU. (648 minuti di tempo CPU su 5 PID)

Dati aggiuntivi:

  • Il traffico è diminuito negli ultimi due giorni di circa il 10%. (analytics e dashboard)
  • Installazione standard di discourse su singolo container (senza chat)
  • Code Sidekiq minime (da 1K a 2K al giorno)
  • Nulla sembra insolito nei log di discourse
  • Funziono su un server DO con 8 GB di RAM e 2 vCPU AMD.

Non è il caso in cui il server sia critico, ma i server che funzionano al 5% - 7% sono molto più felici di quelli che funzionano al 25%.

Quali informazioni posso fornire per aiutare a risolvere questo problema?

grazie

3 Mi Piace
2

Lasciamo questo in supporto per un po’ finché non determiniamo se si tratta di un bug.

Puoi entrare nel container ed eseguire un htop dall’interno (dovrai installarlo) in questo modo sarai in grado di dire quale processo specifico sta consumando elevate quantità di CPU.

Puoi ottenere un po’ più di visibilità utilizzando una tecnica come questa: Debugging 100% CPU usage in production Ruby on Rails systems

Molto probabilmente, però, è sidekiq /sidekiq in qualche modo sovraccarico sulla tua istanza. (Mi concentrerei in particolare sullo scheduler)

3

viste htop.

Ecco un video di 30 secondi:

Screenshot casuali:

L'immagine mostra un elenco di processi o un task manager di un sistema Unix-like che visualizza vari processi in esecuzione, con particolare attenzione a più istanze di processi "unicorn worker", e fornisce dettagli specifici come ID utente, ID processo, priorità, CPU, utilizzo della memoria e tempo di esecuzione stimato. (Didascalia dell'IA)
L'immagine mostra un elenco di processi o un task manager di un sistema Unix-like che visualizza vari processi in esecuzione, con particolare attenzione a più istanze di processi "unicorn worker", e fornisce dettagli specifici come ID utente, ID processo, priorità, CPU, utilizzo della memoria e tempo di esecuzione stimato. (Didascalia dell'IA)1140×852 98.8 KB

Questa immagine mostra l'output di utilizzo dei processi e della CPU di un sistema Unix, con più processi worker associati a Chrome, javascript e Redis, insieme a dettagli come PID, utente e percentuale di utilizzo della CPU. (Didascalia dell'IA)
Questa immagine mostra l'output di utilizzo dei processi e della CPU di un sistema Unix, con più processi worker associati a Chrome, javascript e Redis, insieme a dettagli come PID, utente e percentuale di utilizzo della CPU. (Didascalia dell'IA)1139×860 99.7 KB

Questa immagine è uno screenshot dell'elenco dei processi di un sistema Unix che mostra vari processi, principalmente correlati a un server Redis, con dettagli come PID, utente, priorità, VIRT e altre informazioni specifiche del sistema. (Didascalia dell'IA)
Questa immagine è uno screenshot dell'elenco dei processi di un sistema Unix che mostra vari processi, principalmente correlati a un server Redis, con dettagli come PID, utente, priorità, VIRT e altre informazioni specifiche del sistema. (Didascalia dell'IA)1153×878 101 KB

Questa immagine è uno screenshot di un terminale a riga di comando di un sistema operativo Unix-like che visualizza l'output di un processo "discourse" in esecuzione con vari dettagli del processo, informazioni di sistema e comandi eseguiti. (Didascalia dell'IA)
Questa immagine è uno screenshot di un terminale a riga di comando di un sistema operativo Unix-like che visualizza l'output di un processo "discourse" in esecuzione con vari dettagli del processo, informazioni di sistema e comandi eseguiti. (Didascalia dell'IA)1134×505 59.4 KB

Vista ad albero:

L'immagine mostra una sezione di log del server con timestamp, comandi e azioni dell'utente, insieme a righe ripetute in testo verde e rosso che indicano processi come "sdekiq" e "unicorn worker" che interagiscono con "discourse" e comandi di configurazione correlati. (Didascalia dell'IA)
L'immagine mostra una sezione di log del server con timestamp, comandi e azioni dell'utente, insieme a righe ripetute in testo verde e rosso che indicano processi come "sdekiq" e "unicorn worker" che interagiscono con "discourse" e comandi di configurazione correlati. (Didascalia dell'IA)1151×674 104 KB

L'immagine mostra uno screenshot di un sistema Linux che utilizza il comando top, visualizzando processi e metriche di sistema. (Didascalia dell'IA)
L'immagine mostra uno screenshot di un sistema Linux che utilizza il comando top, visualizzando processi e metriche di sistema. (Didascalia dell'IA)1150×879 119 KB

sidekiq:

Questa immagine è uno screenshot di una dashboard di gestione delle code che visualizza un conteggio dei processi, alcune immagini fallite e code con informazioni dettagliate come occupazione, accodate, tentativi, pianificate e immagini inattive, insieme a un'azione di eliminazione per ciascuna coda. (Didascalia dell'IA)
Questa immagine è uno screenshot di una dashboard di gestione delle code che visualizza un conteggio dei processi, alcune immagini fallite e code con informazioni dettagliate come occupazione, accodate, tentativi, pianificate e immagini inattive, insieme a un'azione di eliminazione per ciascuna coda. (Didascalia dell'IA)1189×428 43.8 KB

Il grafico a linee mostra la progressione di un'attività di didascalia di immagini nel corso di diversi giorni, contrassegnata da marcatori verticali che indicano tentativi falliti in momenti diversi. (Didascalia dell'IA)
Il grafico a linee mostra la progressione di un'attività di didascalia di immagini nel corso di diversi giorni, contrassegnata da marcatori verticali che indicano tentativi falliti in momenti diversi. (Didascalia dell'IA)1203×296 50.5 KB

Questa immagine mostra un pannello del server per un processo denominato "discourse-app:817" in esecuzione con un utilizzo dello 0%, 461 MB di RSS, e può essere messo in pausa o arrestato utilizzando i pulsanti forniti. (Didascalia dell'IA)
Questa immagine mostra un pannello del server per un processo denominato "discourse-app:817" in esecuzione con un utilizzo dello 0%, 461 MB di RSS, e può essere messo in pausa o arrestato utilizzando i pulsanti forniti. (Didascalia dell'IA)1229×537 73.1 KB

Fammi sapere se c’è qualcosa di specifico che devi vedere. Io

2 Mi Piace
4

Sì, c’è qualcosa che non va:

top -H -p PID_DEL_UNICORN

Uno screenshot che mostra l'output di un comando top che indica le risorse di sistema e i processi, con 367 thread, prevalentemente in esecuzione di un processo ruby o colourer-2480, e un utilizzo della RAM prevalentemente libero ma utilizzato. (Sottotitolato dall'IA)
Uno screenshot che mostra l'output di un comando top che indica le risorse di sistema e i processi, con 367 thread, prevalentemente in esecuzione di un processo ruby o colourer-2480, e un utilizzo della RAM prevalentemente libero ma utilizzato. (Sottotitolato dall'IA)1242×610 102 KB

Sospetto che vedrai V8 DefaultWorker lì, penso che sia un regressione in mini_racer… lo riporterò per vedere se questo risolve il problema.

1 Mi Piace
5

OK, questo è stato ripristinato ora,

Fammi sapere se il commit ripristina le prestazioni.

6 Mi Piace
6

Sì, ha risolto il problema dell’elevato utilizzo della CPU. Il mio carico a 1 minuto e 5 minuti è circa 1/3 dei valori precedenti. Questo con htop e netdata in esecuzione sul sistema.

Video HTOP

Grafico del carico

L'immagine mostra due grafici a linee che raffigurano la percentuale della CPU e il carico (1/5/15) su vari intervalli di tempo, con diverse linee che rappresentano diversi carichi (0.100, 1.000, 15.000 e 50.150). (Sottotitolato dall'IA)
L'immagine mostra due grafici a linee che raffigurano la percentuale della CPU e il carico (1/5/15) su vari intervalli di tempo, con diverse linee che rappresentano diversi carichi (0.100, 1.000, 15.000 e 50.150). (Sottotitolato dall'IA)988×553 28.2 KB

Mi aspetto che l’utilizzo della CPU e il carico diminuiscano lentamente man mano che più query di database vengono memorizzate nella cache nel sistema.

Tabella del carico:

tempo Pre-fix post-fix
1 min 0.4 - 0.6 0.06 - 0.1
5 min 0.39 - 0.5 0.15 - 0.18

La metrica dei 15 minuti è influenzata da una ricostruzione. Pubblicherò altre statistiche più tardi domattina.

Grazie per la correzione notturna.

3 Mi Piace
7

Mi dispiace per questo, l’aggiornamento di mini_racer è stata una grande avventura. Speriamo di superarla presto.

3 Mi Piace
8

Grazie per la rapida risposta per indagare.

Sono sicuro che avevate altri piani per la giornata oltre a un rollback.

Essendo un nuovo utente di Discourse, a 2 settimane dalla migrazione, il prodotto si è dimostrato ottimo con cui lavorare.

2 Mi Piace
9

Storia simile anche qui.

Il grafico mostra un grafico dettagliato con due grafici: il grafico superiore è un grafico a linee colorato che mostra l'utilizzo della CPU nel tempo, evidenziato con un picco significativo il 27 gennaio, contrassegnato con un utilizzo della CPU del 2,03%, accanto al grafico inferiore che indica il carico del sistema in formato grafico a linee, con trascurabili... (Sottotitolato dall'IA)
Il grafico mostra un grafico dettagliato con due grafici: il grafico superiore è un grafico a linee colorato che mostra l'utilizzo della CPU nel tempo, evidenziato con un picco significativo il 27 gennaio, contrassegnato con un utilizzo della CPU del 2,03%, accanto al grafico inferiore che indica il carico del sistema in formato grafico a linee, con trascurabili... (Sottotitolato dall'IA)2208×1234 295 KB

[Modifica: sembra essere stato risolto ora dopo l’aggiornamento all’ultima branch]

10

Ecco una revisione delle prestazioni 18 ore dopo la ricostruzione. La tabella dei carichi dice tutto.

Tabella dei carichi:

tempo Pre-fix post-fix
1 min da 0,4 a 0,6 da 0,03 a 0,05
5 min da 0,39 a 0,5 0,09
15 min 0,68 0,12

Legenda:

  • Freccia rossa - ricostruita l’app
  • Freccia viola - spento netdata

L'immagine mostra due grafici: uno con una freccia rossa che indica un elevato utilizzo della CPU e un altro con una freccia viola che mostra picchi di carico, entrambi verificatisi in momenti diversi della giornata. (Didascalia dell'IA)
L'immagine mostra due grafici: uno con una freccia rossa che indica un elevato utilizzo della CPU e un altro con una freccia viola che mostra picchi di carico, entrambi verificatisi in momenti diversi della giornata. (Didascalia dell'IA)984×551 54.8 KB

11

Nota, per chiudere il cerchio, il bug che lo causava era questo:

Ho aggiornato la gemma. Un vantaggio immediato è che sembra che questa versione di v8 utilizzi leggermente meno memoria, il che è positivo.

6 Mi Piace
12

L’ho installata ieri sera con la correzione. L’utilizzo della CPU è tornato ai livelli storici.

Grazie per tutto l’ottimo lavoro.

1 Mi Piace
13

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