أنا أستضيف جميع ملفاتي التي تم تحميلها على تخزين NAS (glusterfs).
مؤخرًا وجدت أن هناك حركة مرور شبكة ضخمة وثابتة على NAS. وقمت بتتبعها إلى Discourse الذي يطلب صورًا محسّنة. هل هناك مهمة تبحث باستمرار عن هذه الصور؟ لماذا؟ وكيف يمكنني إيقافها؟
بالمناسبة، تم تعطيل إعدادات موقع التحميلات النظيف في منتداي.
ربما يكون الملء الاحتياطي الذي أضافه @david للبحث عن لون الصورة الأساسي.
سينتهي في النهاية ويعود إلى حالة مستقرة.
نحتاج إلى المرور على جميع الصور للملء الاحتياطي، قد تتمكن من العمل حول ذلك عن طريق فرض اللون على جميع الصور ليكون أبيض أو شيء من هذا القبيل.
على حد علمي،
إنه يعمل على 25 صورة كل 15 دقيقة. نعم؟ يجب أن يكون هذا ضئيلاً للغاية. أرى آلاف الملفات التي يتم البحث عنها كل دقيقة.
وأيضًا بالنظر إلى النطاق الترددي قبل 6 أشهر، أرى نفس السلوك. لذلك أعتقد أنه يجب أن يكون شيئًا آخر.
ومع ذلك، أنا متأكد تمامًا من أن وظيفة discourse أو شيء مشابه هي التي تقوم بذلك، لأنه عندما أوقف تطبيق discourse، يختفي النطاق الترددي. ومع ذلك، عندما أوقف تطبيق discourse nginx فقط، يظل النطاق الترددي موجودًا.
إعجاب واحد (1)
تفقّد /sidekiq، يجب أن يخبرك بالمهام التي قيد التشغيل، وتأكد من النقر على جميع علامات التبويب
إعجاب واحد (1)
لا توجد وظائف قيد التشغيل. 
. هل هناك وظائف أخرى لن يتم سردها هنا؟
أو ربما هناك شيء في الحاوية يحاول فهرسة الملفات؟
تتم كل منطق الخلفية لدينا في مهام Sidekiq. إذا لم تكن هناك مهمة قيد التشغيل ولا يزال لديك نشاط عالٍ على القرص، فهل يمكن أن يكون المستخدمون يزورون موقعك على الويب ويتم تقديم الصور بواسطة nginx؟
هل لديك شبكة توصيل محتوى (CDN) للتخزين المؤقت أمام الأصول الثابتة؟
لقد اختبرت هذا سابقًا.
لذلك ليس بسبب زيارة المستخدمين للموقع. إذا كان الأمر كذلك، فعندما أوقفت nginx، كان يجب أن يختفي المرور.
ستحتاج إلى استخدام أدوات الفحص في لينكس لمعرفة ما هي معرفات العمليات (PIDs) واستدعاءات النظام (syscalls) التي يتم إجراؤها بالضبط بعد ذلك.
إعجابَين (2)
@Falco @sam أعتقد أنني وجدت السبب الجذري.
أولاً، قمت بإعادة تشغيل تطبيق discourse حتى يختفي الازدحام المستمر. ثم ذهبت إلى لوحة الإدارة وانتقلت إلى قسم التقارير المجمعة. لقد مر وقت طويل منذ أن لم تظهر التقارير بشكل صحيح هنا:
مباشرة بعد انتهاء مهلة التقارير، أرى القفزة في عرض النطاق الترددي للشبكة. وأرى هذا الخطأ في سجلات الأخطاء:
'hijack admin/reports bulk ' لا يزال قيد التشغيل بعد 90 ثانية على قاعدة البيانات الافتراضية، قد تحتاج هذه العملية إلى إعادة التشغيل!
ما الخطأ الذي يحدث هنا؟
هل قاعدة البيانات موجودة في نفس وحدة تخزين NAS؟
لا، قاعدة البيانات موجودة على القرص SSD الفعلي.
المجلد الوحيد الذي يتم تحميله موجود على NAS.
إذًا لا توجد علاقة بينهما. بالعودة إلى
في الواقع، أعتقد أنه ربما تكون هناك علاقة. في بيئة الاختبار الخاصة بي هنا، يقوم بحساب المساحة المستخدمة.
أعتقد أن حساب المساحة المستخدمة في مجلد NAS يحتوي على الكثير من الملفات سيكون مستهلكًا للوقت للغاية والسبب الجذري لعرض النطاق الترددي العالي.
هل أنا على حق؟
إعجابَين (2)
هل يستغرق تشغيل
df -Pk
df -P
du -s
وقتًا طويلاً بشكل ملحوظ على مشاركة الشبكة؟
كان هذان فوريين
df -Pk
df -P
ومع ذلك ، أدى du -s إلى سلوك مشابه أبلغت عنه أعلاه.
وكان يعمل لمدة 5 دقائق ولم ينتهِ واحتجت إلى إنهائه يدويًا.
إعجاب واحد (1)
أوه، فهمت. نتيجة هذا التقرير مخزنة مؤقتًا، لكنني أفترض أنها لا تنتهي أبدًا ولا يمكن تخزينها مؤقتًا لأن مشاركة الشبكة لديك بطيئة جدًا.
إذًا، هل هناك أي شيء يمكننا فعله لمنع حدوث ذلك؟ على سبيل المثال، التعامل معه مثل عمليات تحميل s3 حيث لا نحسب حجم القرص
إعجاب واحد (1)