لماذا يستخدم Plex قدرًا كبيرًا من وحدة المعالجة المركزية بعد التحديث؟
قد يكون ارتفاع استخدام وحدة المعالجة المركزية مباشرةً بعد تحديث Plex ناتجًا مؤقتًا عن عملية ترحيل أو تحليل، لكن لا ينبغي افتراض أنه طبيعي إلى أجل غير مسمى.
التشخيص الأكثر أمانًا يعتمد على فترة زمنية محددة. سجّل إصدار التحديث، ووقت بدء التشغيل، وعمليات Plex النشطة، ونشاط القرص. انتظر حتى يكتمل عمل الترحيل أو التحليل صراحةً، ثم قارن استخدام وحدة المعالجة المركزية أثناء إعادة تشغيل نظيفة ثانية. إذا استمر الحمل من دون تنفيذ المهمة نفسها، فانتقل من تشخيص «مرحلة انتقالية بعد التحديث» إلى تشخيص خلل في الإصدار أو عبء العمل.
ابحث عن ترحيل قاعدة البيانات قبل تغيير الإعدادات
تتطلب بعض إصدارات Plex فحص حالة قاعدة البيانات الحالية أو تحويلها قبل أن يصبح الخادم جاهزًا بالكامل. وقد يستهلك هذا العمل وحدة المعالجة المركزية وعمليات الإدخال والإخراج لبيانات التطبيق لفترة محدودة.
تتطلب بعض الإصدارات إجراء فحص كامل لسجلات قاعدة البيانات الحالية قبل اكتمال بدء التشغيل، لذلك ينبغي تقييم الاستخدام المؤقت لوحدة المعالجة المركزية وعمليات الإدخال والإخراج لبيانات التطبيق بعد انتهاء عملية الترحيل، لا مقارنة ذلك بسلوك الخمول المعتاد.
تحقق من السجلات بحثًا عن نشاط الترحيل، ولاحظ ما إذا كان استخدام وحدة المعالجة المركزية ينخفض عند عودة الجاهزية. لا تقاطع عملية ترحيل معروفة لمجرد أن إعادة التشغيل الأولى أبطأ من المعتاد.
ميّز بين إعادة التحليل والعملية العالقة
قد يؤدي التحديث أيضًا إلى تشغيل تحليل جديد أو متكرر للوسائط، أو إنشاء المعاينات، أو معالجة بيانات التعريف. وقد يستمر هذا الحمل بعد أن تصبح واجهة الويب قابلة للوصول، مما قد يجعله يبدو كأنه خلل في الخادم.
قد يستهلك التحليل بعد التحديث وحدة المعالجة المركزية لفترة طويلة؛ لذا اعتبر مجموعات العمل الباردة والتي يعاد بناؤها أحد أسباب اختلاف سلوك التشغيل الأول عن سلوك الخمول اللاحق، بينما تحدد مهمة Plex الفعلية.
أوقف المهام المجدولة الاختيارية مؤقتًا أو انتظر حتى انتهاء المهمة النشطة، ثم كرر ملاحظة الخمول نفسها. إذا انخفض استخدام وحدة المعالجة المركزية، فأعد جدولة المهمة بدلًا من تغيير حدود وحدة المعالجة المركزية العامة.
قارن عملية إعادة التشغيل الثانية
ينبغي ألا يتكرر العمل الذي يُنفذ مرة واحدة بالطريقة نفسها عند كل بدء تشغيل نظيف. وتُعد إعادة التشغيل الثانية بعد اكتمال العمل أسرع اختبار تحكمي للتمييز بين الترحيل والسلوك المستمر.
أبقِ مسار بيانات التطبيق دون تغيير أثناء المقارنة، وراقب أسماء العمليات والمقاييس نفسها. ينبغي أن يظل مسار بيانات التطبيق الدائم ثابتًا، بحيث يكون المتغير المقصود الوحيد هو اكتمال التحديث.
إذا ظل استخدام وحدة المعالجة المركزية مرتفعًا إلى الحد الأقصى عند التشغيل الثاني، فاجمع السجلات وحدد ما إذا كان الحمل ناتجًا عن البحث أو الفحص أو التحويل أو عملية أخرى. واصل التشخيص انطلاقًا من عبء العمل المحدد، لا من تاريخ التحديث وحده.
لا تُجرِ الرجوع إلى إصدار سابق إلا مع وجود نقطة حالة آمنة
قد يكون الرجوع الثنائي إلى إصدار سابق محفوفًا بالمخاطر إذا غيّر الإصدار الأحدث الحالة المخزنة بطريقة لا يفهمها الإصدار الأقدم. احمِ قاعدة البيانات السابقة للتحديث قبل استخدام الرجوع إلى إصدار سابق كاختصار لاستكشاف الأخطاء وإصلاحها.
ينبغي أن تؤدي عملية الرجوع إلى إصدار سابق إلى استعادة نسخة حالة مطابقة، لأن نقاط الاسترداد النظيفة تحمي من التغييرات التي قد لا يتمكن الملف التنفيذي الأقدم من فهمها بأمان.
عند الحاجة إلى الرجوع إلى إصدار سابق، استعد الحالة المعروفة بأنها سليمة قبل التحديث باستخدام الإصدار المطابق. لا تتناوب بين الملفات التنفيذية القديمة والجديدة على قاعدة بيانات حية واحدة أثناء محاولة عزل سبب ارتفاع استخدام وحدة المعالجة المركزية.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
هل يمكن لـ Jellyfin مشاركة وحدة معالجة رسومات أو مسرّع بأمان مع حاوية أخرى؟
مشاركة وحدة معالجة الرسومات (GPU) مشروطة: تحقّق من ظهور الجهاز ودعم برنامج التشغيل، ثم شغّل كلا الحملين وراقب التحوّل إلى بديل برمجي.
كيفية معرفة ما إذا كان خطأ Jellyfin ناتجًا عن العميل أم الخادم
يكون خطأ Jellyfin من جهة العميل عندما يحدث مع جهاز واحد؛ ويكون من جهة الخادم عندما تفشل عدة عملاء عبر المسار نفسه وتتوافق السجلات.
كيفية تهيئة ذاكرة التخزين المؤقت والتخزين المؤقت في Jellyfin
افصل بين الحالة الدائمة وذاكرة التخزين المؤقت القابلة لإعادة البناء وتخزين التحويل المؤقت، ثم تحقّق من السعة والأذونات باستخدام اختبار تشغيل فعلي.
