Sidekiq stoppt nach einiger Zeit

Hallo zusammen,

ich habe eine Installation mit 3 Openshift-Deployments, eines für Redis (7.0.10), eines für Postgress (13.10) und ein weiteres für Discourse (stable 3.0.3). Alles funktioniert einwandfrei, sobald es bereitgestellt ist. Nach ein paar Stunden oder Tagen stoppen jedoch die Sidekiq-Prozesse (UNICORN_SIDEKIQS=3). Mir sind einige Dinge aufgefallen: Unter /shared/log/rails wird keine sidekiq.log-Datei generiert, und ich glaube, das ist der Grund, warum Sidekiq nicht automatisch neu startet:

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

Wenn sidekiq stoppt, sehe ich folgende Meldung in den 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>'

Dann sehe ich in den Discourse-Pod-Logs die Meldung:

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

Da jedoch keine sidekiq.log-Datei unter /shared/log/rails/ vorhanden ist, startet sie nicht neu.

Meine Kenntnisse in Rails sind fast null, daher fällt es mir schwer, das Problem zu beheben, aber ich sehe, dass Sidekiq nicht pausiert ist:

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

Und wenn ich es manuell starte, funktioniert es:

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

Es gibt ein paar Dinge, die mir helfen würden, dieses Problem zu lösen:

  1. Wie kann ich erreichen, dass /shared/log/rails/sidekiq.log erstellt wird?
  2. Wie kann ich Sidekiq erlauben, mehr als 530 MB Speicher zu verwenden?

Wenn jemand einen Vorschlag hat, lassen Sie es mich bitte wissen, und ich danke Ihnen im Voraus für Ihre Zeit und Unterstützung!

Ich wünsche Ihnen einen schönen Tag! :slight_smile:

1 „Gefällt mir“

Hallo Denis,

Ich werde mich darauf konzentrieren, dir Informationen zur Erhöhung des RSS für Sidekiq zu geben.

Schau dir dazu die Umgebungsvariable UNICORN_SIDEKIQ_MAX_RSS an (ffi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub) (z. B. UNICORN_SIDEKIQ_MAX_RSS: 1000), damit du mehr Speicher zuweisen kannst. Auf jeden Fall empfehle ich dir, den Wert von UNICORN_SIDEKIQS auf 1 oder 2 zu reduzieren, es sei denn, du hast viele Jobs, die lange in der Warteschlange stehen.

Ich weiß nicht, was die Ursache für die Neustarts deines Sidekiqs sein könnte. Normalerweise startet es im Hintergrund nach einem OOM neu (gemäß discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub), aber überprüfe your-forum.com/logs für weitere Informationen. Ich hoffe, das hilft.

Viele Grüße,
Ismael

4 „Gefällt mir“

Hallo @trobiyo, vielen Dank für die schnelle und unkomplizierte Unterstützung!

Ja, mein Sidekiq startet wegen OOM neu, aber ich habe jetzt Ihren Rat befolgt und UNICORN_SIDEKIQS=1 reduziert und mehr Speicher für RSS mit der Umgebungsvariable UNICORN_SIDEKIQ_MAX_RSS zugewiesen.

Ich hoffe, das hilft und verhindert, dass Sidekiq neu startet.

Haben Sie eine Idee, warum Sidekiq keine Protokolle in /shared/log/rails/sidekiq.log generiert?

Vielen Dank nochmals und einen schönen Tag! :slight_smile:

Viele Grüße,
Denis

Hallo,

Wenn ich mich nicht irre, müssen Sie die Umgebungsvariable DISCOURSE_LOG_SIDEKIQ auf 1 setzen, gemäß discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub, andernfalls gibt die Funktion write_to_log zurück, ohne das Protokoll auszugeben (siehe discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub).

Ich hoffe, das hilft.

2 „Gefällt mir“

Hallo,

Ja, DISCOURSE_LOG_SIDEKIQ=1 hat geholfen und ich sehe eine /shared/log/rails/sidekiq.log. Das ist großartig!

Ich habe auch gesehen, dass Sidekiq eine Weile lief und nicht wegen OOM neu gestartet wurde, seit ich die Speicherzuweisung erhöht und auf nur 1 Prozess reduziert habe.

Das scheint die Lösung für mein Sidekiq-Problem zu sein. Ich werde es weiter beobachten und hier Bescheid geben, falls ich doch noch Probleme mit Sidekiq sehe.

In der Zwischenzeit schätze ich deine Hilfe @trobiyo sehr, großartiger Support von deiner Seite!

Schönen Tag noch!

:slight_smile:

2 „Gefällt mir“

Das sind ausgezeichnete Neuigkeiten :clap: , ich freue mich, dass dies bei der Lösung des Problems geholfen hat!

Viele Grüße,
Ismael

3 „Gefällt mir“

Hallo @trobiyo,

Leider stoppt mein Sidekiq immer noch, es sieht so aus, als wären die Änderungen nicht ausreichend gewesen. =/

Ich sehe im Log die folgende Fehlermeldung:

info:
Job exception: FinalDestination: alle aufgelösten IPs waren nicht zulässig

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'

Haben Sie basierend darauf eine Idee, was schief läuft?

Vielen Dank nochmals für Ihre Unterstützung.

:slight_smile:

Hallo Denis,

Sieht das für mich wie ein Problem mit Sockets/DNS aus, das ein Timeout verursacht? Haben Sie etwas unter der Einstellung allowed internal hosts festgelegt?

Wenn ich mir den Stacktrace ansehe, scheint diese Liste leer zu sein, wenn die IPs nachgeschlagen werden (siehe discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub), ausgelöst bei discourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHub. Daher neige ich dazu zu sagen, dass dies mit Ihrer Installation zusammenhängen könnte (die die IP der Sidekiq-Pods nicht erreichen kann?)

Oder prüfen Sie, ob Sie eine NetworkPolicy in Ihrem Cluster verwenden, dies kann ein weiterer Grund sein.

Viele Grüße

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