Maggiore attività del processo idle dopo l'aggiornamento

Ciao,
Dopo aver aggiornato Discourse alla versione v2.5.0.beta4-399-gbf8085e436 (da una versione 2.4.x, utilizzando il bootstrap da riga di comando tramite discourse_docker git, poco prima dei commit relativi all’aggiornamento a Postgres 12), si nota un aumento significativo dell’utilizzo della CPU sul server (anche quando nessun utente è connesso).

Il comando “top” indica che diversi processi “ruby” sono attivi con frequenza. Ho capito che si tratta dei worker di Sidekiq gestiti da Unicorn. Eseguito redis-cli monitor, ho osservato che effettuano richieste BRPOP bloccanti con un timeout di 2 secondi per verificare se ci sono attività da elaborare. Questo si traduce in una dozzina di comandi Redis al secondo. Inoltre, vengono aggiornate delle statistiche ogni 5 secondi. Il comando redis-cli info stats mostra che vengono elaborati in media 15-20 comandi al secondo.

Non so se questa attività possa portare al 2-4% di utilizzo della CPU che rileviamo. Con la versione precedente era inferiore allo 0,5%. Non ho controllato le stesse statistiche di redis-cli in quel periodo.

Sarei curioso di provare un timeout più lungo per vedere se ciò aiuta, ma non ho ancora capito come farlo.

Hmm, potrebbe essere correlato al tuo lavoro, @eviltrout?

A quale lavoro stavi pensando? Non credo che nulla di cui mi sono occupato recentemente possa aver causato questo.

Scusa, pensavo a ember-cli

Controlla forum.example.com/sidekiq - potrebbero esserci alcuni job di rielaborazione in background in esecuzione dopo l’aggiornamento.

È altamente improbabile che abbia toccato Redis. Non dirò mai mai perché ci sono rimasto male in passato, ma sospetto che si tratti di qualcos’altro :slight_smile:

Bel suggerimento. Non ho notato nulla di allarmante, nessun job in esecuzione e nessuno con esecuzione prolungata (solo pochi sopra i 100 ms). La dashboard indica circa 1000 elaborati al giorno, come prima dell’aggiornamento.

Probabilmente è fuori tema, ma è interessante anche il grafico “Processed” negli ultimi 6 mesi: sembrano c’essere due plateau (uno doppio rispetto all’altro) tra cui si alterna con intervalli di settimane. Non sembra correlato ai riavvii (e non abbiamo aggiornato queste componenti in quel periodo).

Esiste un modo semplice per modificare quel timeout di 2 secondi per BRPOP? Non l’ho trovato nel codice. Sarebbe almeno un indicatore per capire se i loop di polling del lavoro sono il problema.

Ecco ciò che a volte vedo in top:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                     
   1024 discour+  20   0  333584 202888  21660 S   1.3   2.5   3:35.81 ruby                                                                        
   1156 discour+  20   0  715904 249416  24532 S   1.3   3.1   3:26.50 ruby                                                                        
   1178 discour+  20   0  726664 251468  24564 S   1.3   3.1   3:26.11 ruby                                                                        
   1189 discour+  20   0  714368 247912  24444 S   1.3   3.1   3:24.56 ruby                                                                        
   1200 discour+  20   0  709760 249708  24632 S   1.3   3.1   3:22.96 ruby                                                                        
   1234 discour+  20   0  713344 250288  24636 S   1.3   3.1   3:30.24 ruby                                                                        
   1167 discour+  20   0  712832 247928  24436 S   1.0   3.1   3:24.75 ruby                                                                        
 188658 me        20   0   10424   4240   3576 R   0.7   0.1   0:00.36 top                                                                         
    448 root      20   0 1748444  84900  45884 S   0.3   1.1   6:09.98 dockerd                                                                     

senza che nessuno sia connesso…

I 3,5 minuti di tempo CPU accumulati ciascuno sono dopo 35 ore di uptime, con pochissima attività utente.

Ho anche provato a usare rbtrace, ma lamenta:
(pid is not listening for messages, did you require “rbtrace”)
Devo ricostruire l’immagine per risolvere il problema? Oppure posso semplicemente modificare o ricostruire qualcosa all’interno del contenitore?