Sidekiq para após algum tempo

Olá a todos,

Tenho uma instalação com 3 implantações Openshift, uma para Redis (7.0.10), uma para Postgress (13.10) e outra para discourse (stable 3.0.3), tudo funciona bem quando implantado, no entanto, após algumas horas ou dias, os processos sidekiq (UNICORN_SIDEKIQS=3) param. Há algumas coisas que notei, em /shared/log/rails, nenhum sidekiq.log está sendo gerado, e acredito que isso me leva ao motivo pelo qual o sidekiq não reinicia 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 o sidekiq para, vejo a seguinte mensagem em 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>'

Então, posso ver no log do pod do discourse a mensagem:

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

No entanto, como não há sidekiq.log em /shared/log/rails/, ele não reinicia.

Meu conhecimento de Rails é quase zero, portanto, acho difícil solucionar o problema, mas vejo que o sidekiq não está pausado:

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

E quando eu o inicio manualmente, ele funciona:

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

Há algumas coisas que imagino que me ajudariam a resolver este problema:

  1. Como faço para que ele crie /shared/log/rails/sidekiq.log?
  2. Como faço para permitir que o sidekiq use mais de 530M de memória?

Se alguém tiver uma sugestão, por favor me avise e agradeço antecipadamente por dedicar seu tempo para me apoiar nisso!

Tenha um ótimo dia! :slight_smile:

Olá Denis,

Vou me concentrar em fornecer informações sobre como aumentar o RSS para o Sidekiq.

Para isso, dê uma olhada na variável de ambiente UNICORN_SIDEKIQ_MAX_RSS (ffi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub) (por exemplo, UNICORN_SIDEKIQ_MAX_RSS: 1000), pois isso permitirá que você aloque mais memória. Em qualquer caso, recomendo que você diminua um pouco o valor de UNICORN_SIDEKIQS para 1 ou 2, a menos que você tenha vários trabalhos sendo enfileirados por muito tempo.

Desconheço a causa das reinicializações do seu sidekiq, normalmente ele apenas reinicia em segundo plano após OOM (de acordo com discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub), mas verifique your-forum.com/logs para mais informações, espero que isso ajude.

Abraços,
Ismael

Olá @trobiyo, muito obrigado pelo suporte rápido e direto!

Sim, meu sidekiq está reiniciando devido a OOM, mas agora segui seu conselho e reduzi o UNICORN_SIDEKIQS=1 e aloquei mais memória para RSS usando a variável de ambiente UNICORN_SIDEKIQ_MAX_RSS.

Espero que isso ajude a evitar que o sidekiq reinicie.

Você tem alguma ideia de por que o sidekiq não está gerando nenhum log em /shared/log/rails/sidekiq.log?

Obrigado mais uma vez e tenha um ótimo dia! :slight_smile:

Abraços,
Denis

Olá,

Se não me engano, você precisa definir a variável de ambiente DISCOURSE_LOG_SIDEKIQ como 1, conforme discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub, caso contrário, a função write_to_log retornará sem despejar o log (veja discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub)

Espero que ajude.

Olá,

Sim, DISCOURSE_LOG_SIDEKIQ=1 ajudou e eu vejo um /shared/log/rails/sidekiq.log. Isso é ótimo!

Também notei que o sidekiq está rodando há um tempo e não reiniciou devido a OOM desde que aumentei a alocação de memória e reduzi para apenas 1 processo.

Essa parece ser a solução para o meu problema com o sidekiq, continuarei monitorando e atualizarei aqui caso ainda veja algum problema em relação ao sidekiq.

Enquanto isso, agradeço muito sua ajuda @trobiyo, ótimo suporte da sua parte!

Tenha um ótimo dia!

:slight_smile:

Essa é uma excelente notícia :clap: , fico feliz que isso tenha ajudado a resolver o problema!

Abraços,
Ismael

Olá novamente @trobiyo,

Infelizmente, meu sidekiq ainda está parando, parece que as mudanças não foram suficientes. =/

Vejo nos logs o seguinte erro:

info:
Job exception: FinalDestination: all resolved IPs were disallowed

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'
rails_multisite-4.0.1/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'

Alguma ideia do que está dando errado com base nisso?

Obrigado mais uma vez pelo seu apoio.

:slight_smile:

Olá Denis,

Isso me parece um problema com sockets/DNS que resulta em timeout? Você tem algo configurado em allowed internal hosts?

Analisando o stacktrace, ao fazer um lookup dos IPs, parece que essa lista está vazia (veja discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub), acionado em discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub, por isso, eu diria que isso pode estar associado à sua instalação (que não consegue alcançar o IP dos pods do sidekiq?)

Ou verifique se você está usando alguma NetworkPolicy instalada em seu cluster, este pode ser outro motivo.

Abraços