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.
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.
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?