الاتصال بشبكة Redis الخاص بك يؤدي أداءً ضعيفًا جدًا

markersocial · 12 ديسمبر 2024، 10:26م

أواجه هذا باستمرار في السجلات - بقيم تتراوح بين ~ 100 ألف و ~ 1.35 مليون - ولكن القراءات القريبة من 100 ألف تبدو شائعة جدًا:

اتصال شبكة Redis الخاص بك ضعيف للغاية. كانت قراءات RTT الأخيرة [97069, 103986, 98459, 100762, 381617]، ومن المثالي أن تكون هذه أقل من 1000. تأكد من تشغيل Redis في نفس المنطقة المتاحة (AZ) أو مركز البيانات مثل Sidekiq. إذا كانت هذه القيم قريبة من 100,000، فهذا يعني أن عملية Sidekiq الخاصة بك قد تكون مشبعة بوحدة المعالجة المركزية؛ قلل من تزامنك و/أو راجع https://github.com/mperham/sidekiq/discussions/5039

يشير هذا إلى أن Redis قد لا يكون قادرًا على استخدام وحدة معالجة مركزية كافية؟ يبدو أن هناك متسعًا كبيرًا لوحدة المعالجة المركزية والذاكرة العشوائية على الخادم نفسه.

أيضًا:
يستهلك Sidekiq الكثير من الذاكرة (باستخدام: 3570.19M) لـ 'www.example.com'، وإعادة التشغيل

هذا يستخدم تطبيق app.yml الكل في واحد مع Discourse stable 3.3.2.

من app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

أضفت هذا التكوين إلى المضيف أيضًا:

Michael K Johnson:

تكوين النواة

يوصي Redis (أحد المكونات الرئيسية التي يعتمد عليها Discourse) بشدة بتعطيل الصفحات الضخمة الشفافة عند استخدام الاستمرارية على القرص (وهو ما يفعله Discourse)، وأنا أيضًا أسمح بتجاوز الذاكرة.
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

معلومات لوحة تحكم Sidekiq:

يبدو أن Redis غير قادر على تجاوز استخدام الذاكرة البالغ 1024 ميجابايت.

إذا كان لدى أي شخص أي أفكار، فسأكون ممتنًا!

markersocial · 19 ديسمبر 2024، 2:38م

للمتابعة بشأن هذا الأمر، أواجه نفس المشكلة مع Jobs::PostAlert:

مع هذه المهام التي غالبًا ما تستغرق ما يصل إلى 15 دقيقة عند استخدام 4 من عمال Sidekiq مع 5 (افتراضي) خيوط مع الاختبار الحالي. يبدو أن سرعة المهام في الثانية لـ Sidekiq تعتمد بشكل كبير على عدد هذه المهام التي يتم تشغيلها في وقت واحد وعدد الخيوط المتاحة للمهام الأخرى.

زيادة عدد عمال Sidekiq إلى 6 أو أعلى (5 خيوط) ستزيد من سرعة مسح قائمة الانتظار، ولكن قاعدة بيانات postgres ستتعطل بانتظام (أفترض بسبب تشغيل عدد كبير جدًا من مهام Jobs::PostAlert في وقت واحد).

هذا على الإصدار المستقر 3.3.2. يبدو أن التغييرات والإصلاحات من الموضوع المرتبط قد تم تنفيذها بالفعل في الإصدار 3.3.2، إذا لم أكن مخطئًا.

supermathie · 19 ديسمبر 2024، 4:11م

لا ينبغي أن يتعطل Postgres ويشير بشكل عام إلى خطأ في Postgres أو نوع من المشاكل الأكبر.

هل لديك سجلات؟

Ed_S · 19 ديسمبر 2024، 5:10م

هل قمت بإعادة تشغيل الخادم منذ إجراء تغييرات تكوين النواة؟

ربما

lscpu

سيكون مفيدًا أيضًا

Falco · 19 ديسمبر 2024، 5:21م

لا يجب عليك أبدًا زيادة UNICORN_SIDEKIQS إلى هذا الحد، وزيادة العمال فقط ولكن

لا ينبغي أن يحدث هذا أبدًا.

الاحتمالات هي:

أنت مقيد بالموارد لأن إما
أ) موقعك قد تجاوز موارد الخادم
ب) أنت تسيء تخصيص الموارد
هناك خطأ ما في المكدس

أود أن أبدأ بـ

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

مما يجب أن يحرر بعض ذاكرة الوصول العشوائي من الخادم الخاص بك.

لمزيد من المعلومات، ستحتاج إلى تشغيل الوظائف المخالفة في وحدة تحكم PostgreSQL والإبلاغ عن عنق الزجاجة.

markersocial · 16 فبراير 2026، 7:10ص

أعتذر عن الاختفاء وشكراً لكم على الردود.

أعتقد أن المشكلة الرئيسية لبطء Redis كانت أن خاصية THP كانت لا تزال مُفعلة (على الرغم من أنني كنت أعتقد خلاف ذلك):

بالنسبة لتعطل PG، كان الحل الرئيسي بالنسبة لي هو إضافة هذا إلى ملف app.yml:

docker_args:
  - "--shm-size=34g"

مع ضبط القيمة على db_shared_buffers + 2GB، حيث أن db_shared_buffers يمثل 25% من ذاكرة الوصول العشوائي (RAM) الإجمالية للجهاز المضيف.

تجاوز القيمة الافتراضية 512m:

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
               if [ -z "$SKIP_MAC_ADDRESS" ] ; then
                mac_address="--mac-address $($docker_path run $user_args -i --rm -a stdout -a stderr $image /bin/sh -c "echo $hostname | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/02:\1:\2:\3:\4:\5/'")"
               fi
          
               if [ ! -z "$START_CMD_ONLY" ] ; then
                 docker_path="true"
               fi
          
               set -x
          
               $docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
                  -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
                  $run_image $boot_command
          
             )
             exit 0
          
          }
          
          run_run() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
          
          }
          
          run_run() {
            set_template_info
            set_volumes
            set_links
            set_run_image
          
            unset ERR
            (exec $docker_path run --rm --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" -i -a stdin -a stdout -a stderr $volumes $run_image \
              /bin/bash -c "$run_command") || ERR=$?
          
            if [[ $ERR > 0 ]]; then
              exit 1
            fi
          }
          
          run_bootstrap() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
              pups_command="$pups_command git pull && git checkout $pups_version &&"
            fi
            pups_command="$pups_command /pups/bin/pups --stdin"
          fi
          
          echo $pups_command
          
          declare -i BOOTSTRAP_EXITCODE
          rm -f $cidbootstrap
          
          echo "$input" | $docker_path run --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" --cidfile "$cidbootstrap" -i -a stdin -a stdout -a stderr $volumes $image \
            /bin/bash -c "$pups_command"
          BOOTSTRAP_EXITCODE=$?
          
          CONTAINER_ID=$(cat "$cidbootstrap")
          rm -f "$cidbootstrap"
          
          # magic exit code that indicates a retry
          if [[ $BOOTSTRAP_EXITCODE -eq 77 ]]; then
            $docker_path rm "$CONTAINER_ID"
            exit 77

Ed_S · 16 فبراير 2026، 12:13م

لقد اطلعت على سجل منشوراتك، وأرى في مشكلة Sidekiq بطيئة جدًا … أعداد هائلة من إشعارات المستخدمين غير المقروءة أنك كنت تدير خادمًا بـ 32 نواة و 128 جيجابايت، مع قاعدة مستخدمين كبيرة ونشطة جدًا. لذلك في هذا السياق، أرى لماذا لا يعتبر 34 جيجابايت رقمًا كبيرًا جدًا! على سبيل التوضيح، قد يكون من المفيد (والمثير للاهتمام) معرفة حجم إعدادك - ربما هنا أو حتى في سيرتك الذاتية؟ (ربما عدد المستخدمين النشطين يوميًا وشهريًا، وحجم نسخ احتياطي قاعدة البيانات، وإعداد الخادم من حيث ذاكرة الوصول العشوائي (RAM)، والمبادلة (swap)، والقرص، ووحدات المعالجة المركزية (CPUs)). ربما حتى موضوع نشارك فيه إحصائياتنا - الكبيرة والصغيرة.

الموضوع		الردود	مرات العرض
Redis used_memory limited to 1024mb? Support	2	136	16 فبراير 2026
Could sidekiq queue be reason for 500 errors? Self-hosting support server-resources	31	3925	13 يوليو 2018
Sidekiq is consuming too much memory, restarting Self-hosting support	40	8839	13 أكتوبر 2020
Redis connection timed out Self-hosting support	30	9610	8 يونيو 2024
Sidekiq is consuming too much memory Self-hosting support	10	2502	9 نوفمبر 2023

الاتصال بشبكة Redis الخاص بك يؤدي أداءً ضعيفًا جدًا

الموضوعات ذات الصلة