Sidekiq se detiene después de un tiempo

Hola a todos:

Tengo una instalación con 3 despliegues de Openshift, uno para Redis (7.0.10), uno para Postgress (13.10) y otro para discourse (estable 3.0.3), todo funciona bien cuando se despliega, sin embargo, después de un par de horas o días, los procesos de sidekiq (UNICORN_SIDEKIQS=3) se detienen. Hay algunas cosas que he notado: en /shared/log/rails/, no se está generando sidekiq.log, y creo que esto es la razón por la que sidekiq no se reinicia automáticamente:

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

Cuando sidekiq se detiene, veo el siguiente mensaje en los 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>'

Luego, puedo ver en el log del pod de discourse el mensaje:

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

Sin embargo, como no hay sidekiq.log en /shared/log/rails/, no se reinicia.

Mi conocimiento de Rails es casi nulo, por lo que me resulta difícil solucionarlo, pero veo que sidekiq no está pausado:

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

Y cuando lo inicio manualmente, 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

Hay un par de cosas que imagino que me ayudarían a resolver este problema:

  1. ¿Cómo hago para que cree /shared/log/rails/sidekiq.log?
  2. ¿Cómo hago para permitir que sidekiq use más de 530M de memoria?

Si alguien tuviera alguna sugerencia, por favor, hágamelo saber y le agradezco de antemano por tomarse el tiempo de apoyarme.

¡Que tengan un excelente día! :slight_smile:

1 me gusta

Hola Denis,

Me centraré en proporcionarte información sobre cómo aumentar la RSS para Sidekiq.

Para ello, echa un vistazo a la variable de entorno UNICORN_SIDEKIQ_MAX_RSS (ffi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub) (por ejemplo, UNICORN_SIDEKIQ_MAX_RSS: 1000), esto te permitirá asignar más memoria. En cualquier caso, te recomiendo que disminuyas un poco el valor de UNICORN_SIDEKIQS a 1 o 2, a menos que tengas varios trabajos en cola durante mucho tiempo.

No sé cuál puede ser la causa de los reinicios de tu sidekiq, normalmente solo se reinicia en segundo plano después de OOM (según discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub), pero consulta your-forum.com/logs para obtener más información, espero que esto ayude.

Saludos,
Ismael

4 Me gusta

Hola @trobiyo, ¡muchas gracias por el soporte rápido y directo!

Sí, mi sidekiq se está reiniciando debido a OOM, pero ahora he seguido tu consejo y he reducido UNICORN_SIDEKIQS=1 y he asignado más memoria a RSS usando la variable de entorno UNICORN_SIDEKIQ_MAX_RSS.

Espero que eso ayude y evite que sidekiq se reinicie.

¿Tienes alguna idea de por qué sidekiq no está generando ningún log en /shared/log/rails/sidekiq.log?

¡Gracias de nuevo y que tengas un buen día! :slight_smile:

Saludos,
Denis

Hola,

Si no me equivoco, tienes que configurar la variable de entorno DISCOURSE_LOG_SIDEKIQ a 1, según discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub, de lo contrario la función write_to_log devolverá sin volcar el registro (ver discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub)

Espero que esto ayude.

2 Me gusta

Hola,

Sí, DISCOURSE_LOG_SIDEKIQ=1 ayudó y veo un /shared/log/rails/sidekiq.log. ¡Eso es genial!

También he visto que sidekiq ha estado funcionando durante un tiempo y no se ha reiniciado debido a OOM desde que aumenté la asignación de memoria y la reduje a 1 proceso solamente.

Esa parece ser la solución a mi problema con sidekiq, lo seguiré monitoreando y actualizaré aquí en caso de que todavía vea algún problema relacionado con sidekiq.

Mientras tanto, realmente aprecio tu ayuda @trobiyo, ¡un soporte increíble de tu parte!

¡Que tengas un buen día!

:slight_smile:

2 Me gusta

¡Excelentes noticias :clap: , me alegra que esto haya ayudado a resolver el problema!

Saludos,
Ismael

3 Me gusta

Hola de nuevo @trobiyo,

Lamentablemente, mi sidekiq sigue deteniéndose, parece que los cambios no fueron suficientes. =/

Veo en los registros el siguiente error:

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

¿Alguna idea de qué está saliendo mal basándonos en esto?

Gracias una vez más por tu apoyo.

:slight_smile:

Hola Denis:

¿Esto me parece un problema con los sockets/DNS que dan tiempo de espera agotado? ¿Tienes algo configurado en el ajuste de hosts internos permitidos?

Mirando el rastreo de la pila, al buscar las IPs, parece que esta lista está vacía (ver discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub), activado en discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub, por lo tanto, me inclino a decir que esto podría estar asociado a tu instalación (¿que no puede alcanzar la IP de los pods de sidekiq?)

O comprueba si estás utilizando alguna NetworkPolicy instalada en tu clúster, esta puede ser otra razón.

Saludos.

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