Sidekiq si ferma dopo un po' di tempo

Ciao a tutti,

Ho un’installazione con 3 deployment di Openshift, uno per Redis (7.0.10), uno per Postgress (13.10) e un altro per discourse (stable 3.0.3), tutto funziona bene quando viene distribuito, tuttavia, dopo un paio d’ore o giorni, i processi sidekiq (UNICORN_SIDEKIQS=3) si fermano, ci sono alcune cose che ho notato, sotto /shared/log/rails, non viene generato alcun sidekiq.log, e credo che questo sia il motivo per cui sidekiq non si riavvia automaticamente:

root@discourse-b9f766dcf-52zjq:/var/www/discourse# ls -laF /shared/log/rails/
total 32
drwxr-xr-x. 2 nobody www-data  4096 Jun  9 08:57 ./
drwxr-xr-x. 3 root   root      4096 May 30 06:16 ../
-rw-r--r--. 1 nobody www-data 16082 Jun  9 09:28 production.log
-rw-r--r--. 1 nobody www-data  1345 Jun  9 09:02 unicorn.stderr.log
-rw-r--r--. 1 nobody www-data   204 Jun  9 09:02 unicorn.stdout.log

Quando sidekiq si ferma, vedo il seguente messaggio in /host/logs:

Info:
Sidekiq is consuming too much memory (using: 530.35M) for 'discourse.internal.odencluster.com', restarting

backtrace:
config/unicorn.conf.rb:163:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:243:in `master_sleep'
unicorn-6.1.0/lib/unicorn/http_server.rb:295:in `join'
unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'

Poi vedo nel log del pod di discourse il messaggio:

(48) Reopening logs
(48) Reopening logs
(48) Reopening logs

Tuttavia, poiché non c’è alcun sidekiq.log sotto /shared/log/rails/, non si riavvia.

La mia conoscenza di Rails è quasi nulla, quindi trovo difficile risolvere il problema, ma vedo che sidekiq non è in pausa:

[1] pry(main)> Sidekiq.paused?
=> false

E quando lo avvio manualmente, funziona:

2023-06-09T09:47:15.556Z pid=195386 tid=449q INFO: Booting Sidekiq 6.5.8 with Sidekiq::RedisConnection::RedisAdapter options {:host=>"redis", :port=>6379, :namespace=>"sidekiq"}
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Booted Rails 7.0.4.3 application in production environment
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Running in ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: See LICENSE and the LGPL-3.0 for licensing details.
2023-06-09T09:47:20.528Z pid=195386 tid=449q INFO: Upgrade to Sidekiq Pro for more features and support: https://sidekiq.org

Ci sono un paio di cose che immagino mi aiuterebbero a risolvere questo problema:

  1. Come posso fare in modo che crei /shared/log/rails/sidekiq.log?
  2. Come posso permettere a sidekiq di usare più di 530M di memoria?

Se qualcuno avesse un suggerimento, per favore fatemelo sapere e vi ringrazio in anticipo per il tempo dedicato a supportarmi!

Buona giornata! :slight_smile:

1 Mi Piace

Ciao Denis,

Mi concentrerò nel fornirti informazioni su come aumentare l’RSS per Sidekiq.

Per questo, dai un’occhiata alla variabile d’ambiente UNICORN_SIDEKIQ_MAX_RSS (vedi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub) (ad esempio, UNICORN_SIDEKIQ_MAX_RSS: 1000) in modo che ti permetta di allocare più memoria. In ogni caso, ti consiglio di diminuire un po’ il valore di UNICORN_SIDEKIQS a 1 o 2, a meno che tu non abbia diversi job in coda per molto tempo.

Non so quale possa essere la causa dei riavvii del tuo sidekiq, normalmente si riavvia in background dopo OOM (secondo discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub), ma controlla your-forum.com/logs per maggiori informazioni, spero questo aiuti.

Saluti,
Ismael

4 Mi Piace

Ciao @trobiyo, grazie mille per il supporto rapido e diretto!

Sì, il mio sidekiq si sta riavviando a causa di OOM, ma ora ho seguito il tuo consiglio e ho ridotto UNICORN_SIDEKIQS=1 e ho allocato più memoria a RSS utilizzando la variabile d’ambiente UNICORN_SIDEKIQ_MAX_RSS.

Spero che questo aiuti ed eviti il riavvio di sidekiq.

Hai qualche idea sul perché sidekiq non stia generando alcun log in /shared/log/rails/sidekiq.log?

Grazie ancora e buona giornata! :slight_smile:

Saluti,
Denis

Ciao,

Se non erro, devi impostare la variabile d’ambiente DISCOURSE_LOG_SIDEKIQ su 1, come da discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub, altrimenti la funzione write_to_log restituirà senza scaricare il log (vedi discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub)

Spero questo aiuti.

2 Mi Piace

Ciao,

Sì, DISCOURSE_LOG_SIDEKIQ=1 ha aiutato e vedo un /shared/log/rails/sidekiq.log. È fantastico!

Ho anche notato che sidekiq è in esecuzione da un po’ e non si è riavviato a causa di OOM da quando ho aumentato la memoria allocata e ridotto a 1 solo processo.

Sembra essere la soluzione al mio problema con sidekiq, continuerò a monitorarlo e aggiornerò qui nel caso in cui riscontrassi ancora qualche problema relativo a sidekiq.

Nel frattempo, apprezzo davvero il tuo aiuto @trobiyo, un supporto eccezionale da parte tua!

Buona giornata!

:slight_smile:

2 Mi Piace

Ottime notizie :clap: , sono contento che questo abbia aiutato a risolvere il problema!

Saluti,
Ismael

3 Mi Piace

Ciao di nuovo @trobiyo,

Sfortunatamente il mio sidekiq si sta ancora fermando, sembra che le modifiche non siano state sufficienti. =/

Vedo nei log il seguente errore:

info:
Job exception: FinalDestination: tutti gli IP risolti non erano consentiti

backtrace:
/var/www/discourse/lib/final_destination/ssrf_detector.rb:104:in `lookup_and_filter_ips'
/var/www/discourse/lib/final_destination/http.rb:13:in `connect'
/usr/local/lib/ruby/3.2.0/net/http.rb:1248:in `do_start'
/usr/local/lib/ruby/3.2.0/net/http.rb:1237:in `start'
/usr/local/lib/ruby/3.2.0/net/http.rb:687:in `start'
/var/www/discourse/lib/final_destination.rb:511:in `safe_session'
/var/www/discourse/lib/final_destination.rb:450:in `safe_get'
/var/www/discourse/lib/final_destination.rb:161:in `get'
/var/www/discourse/lib/retrieve_title.rb:81:in `fetch_title'
/var/www/discourse/lib/retrieve_title.rb:7:in `crawl'
/var/www/discourse/lib/inline_oneboxer.rb:76:in `lookup'
/var/www/discourse/lib/cooked_processor_mixin.rb:310:in `process_inline_onebox'
/var/www/discourse/lib/cooked_processor_mixin.rb:39:in `block in post_process_oneboxes'
/var/www/discourse/lib/oneboxer.rb:213:in `block in apply'
/var/www/discourse/lib/oneboxer.rb:161:in `block in each_onebox_link'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:235:in `block in each'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:234:in `upto'
nokogiri-1.14.2-x86_64-linux/lib/nokogiri/xml/node_set.rb:234:in `each'
/var/www/discourse/lib/oneboxer.rb:161:in `each_onebox_link'
/var/www/discourse/lib/oneboxer.rb:212:in `apply'
/var/www/discourse/lib/cooked_processor_mixin.rb:9:in `post_process_oneboxes'
/var/www/discourse/lib/cooked_post_processor.rb:41:in `block in post_process'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/lib/cooked_post_processor.rb:38:in `post_process'
/var/www/discourse/app/jobs/regular/process_post.rb:28:in `block in execute'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/app/jobs/regular/process_post.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
/var/www/discourse/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
sidekiq-6.5.8/lib/sidekiq/processor.rb:202:in `execute_job'
sidekiq-6.5.8/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:134:in `call'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
sidekiq-6.5.8/lib/sidekiq/middleware/chain.rb:182:in `invoke'
sidekiq-6.5.8/lib/sidekiq/processor.rb:169:in `block in process'
sidekiq-6.5.8/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_retry.rb:113:in `local'
sidekiq-6.5.8/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
sidekiq-6.5.8/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/processor.rb:263:in `stats'
sidekiq-6.5.8/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.5.8/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_retry.rb:80:in `global'
sidekiq-6.5.8/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.5.8/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.5.8/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.5.8/lib/sidekiq/processor.rb:168:in `process'
sidekiq-6.5.8/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.5.8/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.5.8/lib/sidekiq/component.rb:8:in `watchdog'
sidekiq-6.5.8/lib/sidekiq/component.rb:17:in `block in safe_thread'

Hai qualche idea su cosa sta andando storto basandoti su questo?

Grazie ancora per il tuo supporto.

:slight_smile:

Ciao Denis,

Mi sembra un problema con i socket/DNS che danno timeout? Hai impostato qualcosa sotto l’opzione allowed internal hosts?

Guardando lo stacktrace, quando si effettua una ricerca degli IP, sembra che questo elenco sia vuoto (vedi discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub), attivato in discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub, quindi sono tentato di dire che questo potrebbe essere associato alla tua installazione (che non riesce a raggiungere l’IP dei pod di sidekiq?)

Oppure verifica se stai utilizzando qualche NetworkPolicy installata nel tuo cluster, questo può essere un altro motivo.

Saluti

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