Sidekiq s'arrête après un certain temps

Bonjour à tous,

J’ai une installation avec 3 déploiements Openshift, un pour Redis (7.0.10), un pour Postgress (13.10) et un autre pour discourse (stable 3.0.3). Tout fonctionne bien lors du déploiement, cependant, après quelques heures ou jours, les processus sidekiq (UNICORN_SIDEKIQS=3) s’arrêtent. J’ai remarqué certaines choses : sous /shared/log/rails/, aucun fichier sidekiq.log n’est généré, et je pense que c’est la raison pour laquelle sidekiq ne redémarre pas automatiquement :

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

Lorsque sidekiq s’arrête, je vois le message suivant dans les logs de l'hôte :

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

Ensuite, je peux voir dans le log du pod discourse le message :

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

Cependant, comme il n’y a pas de sidekiq.log sous /shared/log/rails/, il ne redémarre pas.

Mes connaissances en Rails sont quasi nulles, ce qui rend le dépannage difficile, mais je vois que sidekiq n’est pas en pause :

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

Et quand je le démarre manuellement, cela fonctionne :

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

Il y a quelques points qui, je pense, m’aideraient à résoudre ce problème :

  1. Comment faire pour qu’il crée /shared/log/rails/sidekiq.log ?
  2. Comment permettre à sidekiq d’utiliser plus de 530 Mo de mémoire ?

Si quelqu’un a une suggestion, faites-le moi savoir et je vous remercie d’avance de prendre le temps de m’aider !

Passez une excellente journée ! :slight_smile:

1 « J'aime »

Salut Denis,

Je vais me concentrer sur te fournir des informations sur la façon d’augmenter le RSS pour Sidekiq.

Pour cela, regarde la variable d’environnement UNICORN_SIDEKIQ_MAX_RSS (ffi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub) (par exemple, UNICORN_SIDEKIQ_MAX_RSS: 1000) afin de pouvoir allouer plus de mémoire. Dans tous les cas, je te recommande de diminuer un peu la valeur de UNICORN_SIDEKIQS à 1 ou 2, à moins que tu n’aies plusieurs jobs mis en file d’attente pendant longtemps.

J’ignore cependant ce qui pourrait causer les redémarrages de ton sidekiq, normalement il redémarre en arrière-plan après un OOM (selon discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub), mais vérifie your-forum.com/logs pour plus d’informations, j’espère que cela t’aidera.

Cordialement,
Ismael

4 « J'aime »

Bonjour @trobiyo, merci beaucoup pour votre support rapide et direct !

Oui, mon sidekiq redémarre à cause de OOM, mais j’ai maintenant suivi votre conseil et j’ai réduit UNICORN_SIDEKIQS=1 et j’ai alloué plus de mémoire à RSS en utilisant l’environnement UNICORN_SIDEKIQ_MAX_RSS.

J’espère que cela aidera à éviter le redémarrage de sidekiq.

Avez-vous une idée pourquoi sidekiq ne génère aucun log dans /shared/log/rails/sidekiq.log ?

Merci encore et passez une excellente journée ! :slight_smile:

Cordialement,
Denis

Salut,

Si je ne me trompe pas, vous devez définir la variable d’environnement DISCOURSE_LOG_SIDEKIQ sur 1, conformément à discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub, sinon la fonction write_to_log retournera sans enregistrer le log (voir discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub).

J’espère que cela vous aidera.

2 « J'aime »

Bonjour,

Oui, DISCOURSE_LOG_SIDEKIQ=1 a aidé et je vois un /shared/log/rails/sidekiq.log. C’est super !

J’ai également remarqué que sidekiq fonctionne depuis un certain temps et qu’il n’a pas redémarré en raison d’un manque de mémoire (OOM) depuis que j’ai augmenté la mémoire allouée et réduit à 1 processus seulement.

Cela semble être la solution à mon problème de sidekiq, je vais continuer à le surveiller et je mettrai à jour ici au cas où je rencontrerais encore des problèmes concernant sidekiq.

En attendant, j’apprécie vraiment votre aide @trobiyo, excellent support de votre part !

Passez une excellente journée !

:slight_smile:

2 « J'aime »

C’est une excellente nouvelle :clap: , je suis content que cela ait aidé à résoudre le problème !

Cordialement,
Ismael

3 « J'aime »

Bonjour @trobiyo,

Malheureusement, mon sidekiq s’arrête toujours, il semble que les changements n’aient pas été suffisants. =/

Je vois l’erreur suivante dans les logs :

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'

Avez-vous une idée de ce qui ne va pas d’après cela ?

Merci encore pour votre aide.

:slight_smile:

Salut Denis,

Cela me ressemble à un problème de sockets/DNS qui provoque un délai d’attente ? Avez-vous configuré quelque chose sous le paramètre allowed internal hosts ?

En regardant la trace de la pile, lors de la recherche des adresses IP, il semble que cette liste soit vide (voir discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub), déclenchée à discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub, par conséquent, je suis tenté de dire que cela pourrait être associé à votre installation (qui ne peut pas atteindre l’adresse IP des pods sidekiq ?)

Ou vérifiez si vous utilisez une NetworkPolicy installée dans votre cluster, cela pourrait être une autre raison.

Cordialement

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