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:

1 curtida

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

4 curtidas

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.

2 curtidas

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:

2 curtidas

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

Abraços,
Ismael

3 curtidas

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

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