يتوقف Sidekiq بعد فترة زمنية

أهلاً بالجميع،

لدي تثبيت به 3 عمليات نشر لـ Openshift، واحدة لـ Redis (7.0.10)، وواحدة لـ Postgress (13.10)، وأخرى لـ discourse (stable 3.0.3)، كل شيء يعمل بشكل جيد عند النشر، ومع ذلك، بعد بضع ساعات أو أيام، تتوقف عمليات sidekiq (UNICORN_SIDEKIQS=3)، وهناك بعض الأشياء التي لاحظتها، تحت /shared/log/rails، لا يتم إنشاء ملف sidekiq.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>'

ثم يمكنني رؤية الرسالة التالية في سجل pod الخاص بـ discourse:

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

ومع ذلك، نظرًا لعدم وجود ملف sidekiq.log تحت /shared/log/rails/، فإنه لا يعاد تشغيله.

معرفتي بـ 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 يسمح باستخدام أكثر من 530 ميجابايت من الذاكرة؟

إذا كان لدى أي شخص اقتراح، فيرجى إخباري وأشكركم مقدمًا على وقتكم في دعم هذا!

أتمنى لكم يومًا رائعًا! :slight_smile:

إعجاب واحد (1)

مرحباً دينيس،

سأركز على تزويدك بمعلومات حول كيفية زيادة ذاكرة الوصول العشوائي (RSS) لـ Sidekiq.

لهذا الغرض، ألقِ نظرة على المتغير البيئي UNICORN_SIDEKIQ_MAX_RSS (رابط: 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 لمزيد من المعلومات، آمل أن يساعد هذا.

تحياتي،
إسماعيل

4 إعجابات

مرحباً @trobiyo، شكراً جزيلاً على الدعم السريع والمباشر!

نعم، إعادة تشغيل الـ sidekiq لدي بسبب OOM، لكنني الآن اتبعت نصيحتك وقللت UNICORN_SIDEKIQS=1 وخصصت المزيد من الذاكرة لـ RSS باستخدام البيئة UNICORN_SIDEKIQ_MAX_RSS.

آمل أن يساعد ذلك في تجنب إعادة تشغيل الـ sidekiq.

هل لديك أي فكرة عن سبب عدم قيام الـ sidekiq بإنشاء أي سجلات في /shared/log/rails/sidekiq.log؟

شكراً مرة أخرى، أتمنى لك يوماً رائعاً! :slight_smile:

مع خالص تحياتي،
دينيس

مرحباً،

إذا لم أكن مخطئاً، يجب عليك تعيين متغير البيئة 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. هذا رائع!

لقد لاحظت أيضاً أن sidekiq يعمل منذ فترة ولم يتم إعادة تشغيله بسبب نفاد الذاكرة (OOM) منذ أن زدت تخصيص الذاكرة وقللت إلى عملية واحدة فقط.

يبدو أن هذا هو الحل لمشكلة sidekiq الخاصة بي، وسأستمر في مراقبته وسأقوم بالتحديث هنا في حال واجهت أي مشكلة أخرى تتعلق بـ sidekiq.

في هذه الأثناء، أقدر حقاً مساعدتك @trobiyo، دعم رائع من جانبك!

أتمنى لك يوماً رائعاً!

:slight_smile:

إعجابَين (2)

هذه أخبار ممتازة :clap: ، سعيد لأن هذا ساعد في حل المشكلة!

تحياتي،
إسماعيل

3 إعجابات

مرحباً مرة أخرى @trobiyo،

للأسف، لا يزال جهاز sidekiq الخاص بي يتوقف، يبدو أن التغييرات لم تكن كافية. =/

أرى في السجلات الخطأ التالي:

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'

أي فكرة عما يحدث خطأ بناءً على هذا؟

شكراً جزيلاً لدعمك مرة أخرى.

:slight_smile:

مرحباً دينيس،

يبدو لي أن هذه مشكلة في المقابس/نظام أسماء النطاقات (DNS) التي تعطي مهلة؟ هل لديك أي شيء تم تعيينه ضمن إعداد المضيفين الداخليين المسموح بهم؟

بالنظر إلى تتبع المكدس، عند إجراء بحث عن عناوين 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 الخاص بـ sidekiq pods؟)

أو تحقق مما إذا كنت تستخدم أي سياسة شبكة (NetworkPolicy) مثبتة في مجموعتك، فقد يكون هذا سببًا آخر.

تحياتي

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