كيفية معرفة ما إذا كان Plex مقيّدًا بوحدة المعالجة المركزية أو ذاكرة الوصول العشوائي أو مساحة التخزين أو الشبكة

يمكنك تحديد ما يحدّ من Plex من خلال إعادة إنتاج حمل عمل معروف واحد، والبحث عن المورد الذي يرتفع ضغطه في الوقت نفسه الذي يتباطأ فيه البث. لا تُرقِّ المكوّن الذي يبدو الأكثر انشغالًا أولًا؛ فالاستخدام المرتفع لا يكون مهمًا إلا عندما يتزامن مع فشل التشغيل.

ابدأ بملف واحد، وعميل واحد، ووضع تشغيل واحد، وفترة زمنية واحدة. ثم افصل بين أعمال تحويل Plex وإشارات نظام التشغيل الخاصة بالمعالج والذاكرة والتخزين والشبكة. لا يكتمل الاختبار إلا عندما يؤدي تغيير مورد واحد مشتبه به إلى تغيير أعراض Plex الأصلية، مع بقاء الظروف الأخرى ثابتة.

أعِد إنتاج حمل عمل واحد في Plex قبل قراءة مقاييس النظام

اختر ملفًا وعميلًا يعيدان إنتاج المشكلة بشكل موثوق. سجّل ما إذا كان العَرَض يتمثل في بطء بدء التشغيل، أو التخزين المؤقت المتكرر، أو تأخر التحويل عن مجاراة التشغيل، أو تسبب الفحص في بطء التشغيل، أو فشل لا يظهر إلا عن بُعد؛ لأن كل عَرَض يشير إلى مسار انتظار مختلف.

ينبغي أن يبدأ مسار استكشاف أخطاء Plex من الجلسة النشطة، لا من مخطط عام للمعالج. يفصل فحص يبدأ بلوحة المعلومات عمليًا بين فروع التشغيل المباشر والتحويل والشبكة والتخزين قبل أن تبدأ في تغيير الخادم.

أبقِ الملف والمسارات المحددة وجودة العميل وحمل العمل المتزامن دون تغيير أثناء جمع مقاييس النظام. إذا تغيّر العَرَض بين الاختبارات، فبسّط حمل العمل حتى يتكرر الفشل نفسه؛ وإلا فقد تكون زيادة لاحقة في المعالج أو القرص ناتجة عن مهمة مختلفة.

استخدم جلسة Plex للفصل بين التسليم والتحويل

اقرأ جلسة Plex أثناء حدوث المشكلة. يعني التشغيل المباشر أن الخادم يسلّم الوسائط المخزنة في الغالب، بينما يضيف تحويل الفيديو مسار تحويل فعليًا في الوقت الحقيقي، وقد ينقل عنق الزجاجة نحو المعالج أو محركات الفيديو العتادية.

استخدم هذا الوضع كفرع، لا كخلاصة نهائية. فالتحويل المتأخر يجعل القدرة الحاسوبية مرشحًا قويًا، لكن التخزين المؤقت أثناء التشغيل المباشر يبقي التخزين والشبكة ضمن الاحتمالات. إذا بدّل الملف نفسه وضع التشغيل عند تغيير الترجمة أو الصوت أو الجودة، فأعِد إنتاج المشكلة مرة أخرى بالطلب الأصلي قبل مقارنة مقاييس المضيف.

ينبغي أن تخرج من هذا القسم بوضع تشغيل ثابت مرتبط بالعَرَض. إذا لم تستطع تحديد ما إذا كان الاختبار الفاشل يعتمد على التشغيل المباشر أو التحويل، فتوقف هنا؛ فمقارنة بيانات الذاكرة والقرص والشبكة قبل استقرار مسار الوسائط تجعل تفسير المقاييس المتبقية أصعب.

اختبر ضغط المعالج وذاكرة الوصول العشوائي معًا

راقب استخدام المعالج، وطابور التشغيل أو الحمل، والذاكرة المتاحة، ونشاط المبادلة أثناء اختبار Plex الثابت. يكون ضغط المعالج هو الاحتمال الأقوى عندما تستهلك عملية Plex أو محوّلها قدرة حاسوبية مستمرة بينما يتأخر الإخراج؛ ويكون ضغط الذاكرة أقوى عندما يبدأ النظام في استعادة الذاكرة أو استخدام المبادلة ويتدهور زمن الاستجابة، حتى لو لم يكن المعالج هو المورد الوحيد المشغول.

يستخدم مسار عام لتحسين أداء Linux أدوات مثل top وvmstat وiostat وsar للفصل بين ضغوط الموارد. وعلى وجه الخصوص، تحتاج المعالج والذاكرة والقرص والشبكة إلى إشارات تشبع مختلفة، لا إلى رقم واحد للاستخدام الإجمالي.

إذا ظل المعالج قريبًا من حده فقط أثناء التحويل الفاشل، وتعافى البث عند إزالة التحويل أو تسريعه، فاعتبر القدرة الحاسوبية عنق الزجاجة الرئيسي. أما إذا ارتفع استخدام المبادلة أو استعادة الذاكرة بدلًا من ذلك، فخفّض عدد المهام الخلفية الكثيفة استهلاك الذاكرة أو أضف ذاكرة، ثم أعد حمل عمل Plex نفسه قبل تعديل إعدادات التخزين أو الشبكة.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

اختبر التخزين باستخدام مسار الوسائط نفسه

بالنسبة إلى التخزين، اقرأ الوسائط نفسها من نظام الملفات نفسه أثناء إعادة ظهور العَرَض، وراقب زمن استجابة الجهاز والانتظار في الطابور وانتظار الإدخال والإخراج. السعة والأداء أمران منفصلان: فقد يملك القرص مساحة حرة، لكنه يظل بطيئًا في الاستجابة لأن مهمة أخرى تنشئ إدخالًا وإخراجًا عشوائيًا، أو لأن مسار الوسائط يمر عبر مجموعة تخزين مشغولة أو نقطة تحميل شبكية.

تُعد أدوات Linux مثل iostat وiotop مفيدة لأن انتظار إدخال وإخراج القرص ومعدل نقل الجهاز يكشفان نمط فشل مختلفًا عن ارتفاع استخدام المعالج أو نشاط المبادلة. قارن هذه الأرقام بفترة التخزين المؤقت المحددة، لا بمتوسط وقت الخمول.

إذا قُرئ الملف بسلاسة بينما يواجه Plex تخزينًا مؤقتًا، يصبح التخزين أقل احتمالًا. وإذا ارتفع زمن الاستجابة والانتظار في الطابور مع ظهور العَرَض، فأوقف مهمة القرص المنافسة أو انقل ملف الاختبار إلى مسار محلي سريع معروف؛ فإذا تعافى Plex فورًا في وضع التشغيل نفسه، يكون التخزين قد انتقل من مجرد اشتباه إلى دليل.

اختبر معدل نقل الشبكة على المسار الفعلي

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

استخدم أداة مثل iperf3 عندما تتحكم في الطرفين. ينبغي أن ينظر اختبار الشبكة إلى معدل النقل وفقدان الحزم وزمن الاستجابة، لأن سرعة الارتباط المعلنة لا تثبت أن المسار الفعلي يوفّر حركة تطبيق مستقرة.

إذا انهار اختبار الشبكة المستقل بينما بقيت المعالجة والذاكرة والتخزين في حالة جيدة، فأصلح المسار قبل ضبط المحوّل. وإذا كانت الشبكة تملك هامشًا مريحًا ومستقرًا واستمر عَرَض Plex في اختبار محلي سلكي، فارجع إلى فرع موارد الخادم بدلًا من شراء موجه أسرع.

غيّر المورد الذي فشل في الاختبار فقط

اختر أول مورد فشل في اختبار التمييز، وأجرِ تغييرًا واحدًا ينبغي أن يؤثر في ذلك الفرع وحده. تشمل الأمثلة تفعيل تحويل عتادي تم التحقق منه لبث محدود بالقدرة الحاسوبية، أو تقليل مهمة خلفية كثيفة استهلاك الذاكرة، أو إعادة جدولة مهمة مكثفة استخدام القرص، أو تجاوز قفزة شبكية ضعيفة.

بالنسبة إلى المتابعة الخاصة بـ Plex، يوفّر مسار تشخيص التخزين المؤقت من ZimaSpace متابعة أعمق بمجرد أن تعرف ما إذا كان الفرع الذي تحتاج إلى تغييره هو وضع التشغيل أو حمل التحويل أو استقرار الشبكة أو سرعة استجابة التخزين.

أعد تشغيل الملف والعميل ووضع التشغيل الأصلي بعد التغيير. لا تعتبر مكوّنًا ما عنق الزجاجة إلا عندما يتحسن العَرَض الأصلي وتنخفض إشارة الضغط المطابقة أو يزداد هامشها. وإذا لم يتغير العَرَض، فأعد الإعداد الأساسي واختبر الفرع التالي بدلًا من تكديس الترقيات حتى يختفي السبب الحقيقي مصادفة.