Sidekiqがしばらくすると停止する

皆さん、こんにちは。

Redis (7.0.10)、Postgress (13.10)、および Discourse (stable 3.0.3) の 3 つの OpenShift デプロイメントを持つインストール環境があります。デプロイ時はすべて正常に動作しますが、数時間または数日後に Sidekiq プロセス (UNICORN_SIDEKIQS=3) が停止します。気づいた点がいくつかあります。/shared/log/railssidekiq.log が生成されておらず、これが Sidekiq が自動的に再起動しない理由だと考えています。

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

sidekiq が停止すると、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>'

次に、Discourse Pod のログで次のメッセージを確認できます。

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

しかし、/shared/log/rails/sidekiq.log がないため、再起動しません。

私の Rails の知識はほとんどゼロなので、トラブルシューティングが難しいのですが、Sidekiq が一時停止していないことがわかります。

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

手動で起動すると、正常に動作します。

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

この問題を解決するために役立つと思われることがいくつかあります。

  1. /shared/log/rails/sidekiq.log を作成するにはどうすればよいですか?
  2. Sidekiq が 530M 以上のメモリを使用できるようにするにはどうすればよいですか?

誰か提案があれば教えてください。時間を割いてサポートしていただき、事前に感謝いたします。

素晴らしい一日を! :slight_smile:

「いいね!」 1

Denis様

SidekiqのRSSを増やす方法について情報を提供します。

UNICORN_SIDEKIQ_MAX_RSS 環境変数(ffi: discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub UNICORN_SIDEKIQ_MAX_RSS: 1000)を確認してください。これにより、より多くのメモリを割り当てることができます。いずれにしても、複数のジョブが長時間キューに入れられている場合を除き、UNICORN_SIDEKIQS の値を1または2に少し減らすことをお勧めします。

Sidekiqが再起動する原因については不明ですが、通常はOOM(メモリ不足)の後にバックグラウンドで再起動します(discourse/config/unicorn.conf.rb at 89d7b1861d1625352e82e82c19f93e7272c965ef · discourse/discourse · GitHub your-forum.com/logs を確認してください。お役に立てば幸いです。

よろしくお願いいたします。
Ismael

「いいね!」 4

Hello @trobiyo 様、迅速かつ的確なサポートをいただき、誠にありがとうございます!

はい、sidekiq は OOM により再起動していますが、アドバイスに従い UNICORN_SIDEKIQS=1 を減らし、UNICORN_SIDEKIQ_MAX_RSS 環境変数を使用して RSS のメモリを増やしました。

これで sidekiq の再起動が回避できることを願っています。

sidekiq が /shared/log/rails/sidekiq.log にログを生成しない理由について、何かお分かりになることはありますでしょうか?

重ねて御礼申し上げます。良い一日をお過ごしください! :slight_smile:

よろしくお願いいたします。
Denis

こんにちは。

私の記憶が正しければ、DISCOURSE_LOG_SIDEKIQ 環境変数を 1 に設定する必要があるはずです。これは discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub に記載されており、そうしないと write_to_log 関数がログを出力せずに終了してしまいます(discourse/app/jobs/base.rb at 7c768a2ff99f45ab5008c16cf6982652d576a0e2 · discourse/discourse · GitHub を参照)。

お役に立てば幸いです。

「いいね!」 2

こんにちは。

はい、DISCOURSE_LOG_SIDEKIQ=1 は役立ちました。/shared/log/rails/sidekiq.log が表示されています。素晴らしいです!

また、メモリ割り当てを増やし、プロセスを1つだけに減らしてから、sidekiq が OOM によって再起動することなくしばらく実行されていることもわかりました。

これが sidekiq の問題の解決策のようです。引き続き監視し、sidekiq に関して問題が発生した場合は、ここで更新します。

その間、@trobiyo さん、あなたの助けに本当に感謝しています。素晴らしいサポートでした!

良い一日を!

:slight_smile:

「いいね!」 2

それが素晴らしいニュースであること :clap: 、問題の解決に役立ったことを嬉しく思います!

よろしく、
イスマエル

「いいね!」 3

こんにちは、@trobiyoさん

残念ながら、私のsidekiqはまだ停止しています。変更は十分ではなかったようです。=/

ログで以下のエラーを確認しました。

info:
Job exception: FinalDestination: すべての解決済みIPが無効とされました

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'

このエラーに基づいて、何が間違っているか何か考えはありますか?

サポートに改めて感謝します。

:slight_smile:

Denis様

これはソケット/DNSの問題でタイムアウトが発生しているように思われます。allowed internal hosts設定で何か設定されていますか?

スタックトレースを見ると、IPのルックアップ時にこのリストが空になっているようです(discourse/lib/final_destination/ssrf_detector.rb at main · discourse/discourse · GitHub参照)。これはdiscourse/lib/final_destination/http.rb at tests-passed · discourse/discourse · GitHubでトリガーされているため、サイドカーポッドのIPに到達できない、お客様のインストールに関連している可能性があると言わざるを得ません。

または、クラスターにインストールされているNetworkPolicyを使用しているかどうかを確認してください。これも別の理由である可能性があります。

よろしくお願いいたします。

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