ما حد الذاكرة الذي ينبغي تعيينه لـ Jellyfin؟
لا تختَر حدًا موحدًا لذاكرة Jellyfin؛ ابدأ بحِمل عمل مقاس، واحجز ذاكرة للمضيف والحاويات المجاورة، ولا تضع حدًا أقصى صارمًا إلا بعد رصد الذروات الفعلية.
هل تستمر حاويتك في النمو حتى يبدأ المضيف باستخدام الذاكرة التبادلية، أم يتسبب الحد المنخفض في عمليات قتل متكررة بسبب نفاد الذاكرة؟ قِس الاستخدام في وضع الخمول، وفحص المكتبة، ومعالجة البيانات الوصفية، وعمليات التحويل المتزامنة، والذاكرة المتاحة لـ Docker أو الجهاز الافتراضي قبل تغيير الحد. لا يكون الحد آمنًا إلا عندما يكتمل حمل العمل الأصلي ويحتفظ المضيف بهامش كافٍ للتعافي.
ميّز بين نمو ذاكرة التخزين المؤقت الطبيعي وضغط الذاكرة المقيمة
قارن أولًا بين RSS للحاوية، وذاكرة التخزين المؤقت، والذاكرة التبادلية، والذاكرة الحرة لدى المضيف أثناء الخمول وأثناء أكثر مهمة قابلة للتكرار استهلاكًا. قد تبدو ذاكرة التخزين المؤقت لنظام الملفات كبيرة من دون أن تكون تسربًا، بينما يشير نمو الذاكرة المقيمة، إلى جانب أحداث نفاد الذاكرة، إلى وجود قيد فعلي.
عادةً ما يبدأ نشر Jellyfin الأساسي عبر Docker ببضعة غيغابايتات، ويحتاج إلى المزيد عند إجراء التحويل، لكن القيمة الصحيحة تعتمد على حمل العمل (خط أساس للذاكرة قائم على حمل العمل).
إذا ظل RSS ثابتًا بينما ترتفع ذاكرة التخزين المؤقت وكان لدى المضيف ذاكرة يمكن استردادها، فراقب الوضع بدلًا من تشديد الحد. وإذا ارتفع RSS مع الذاكرة التبادلية أو رسائل قتل العمليات بسبب نفاد الذاكرة، فتابع إلى اختبارات التحويل وفحص المكتبة.
اختبر الحد تحت العامل المسبب للفشل
شغّل فحصًا واحدًا للمكتبة، وعملية تحويل نموذجية واحدة، وعدد التدفقات المتزامنة المتوقع، مع تسجيل استخدام ذاكرة cgroup، وأحداث الذاكرة، والذاكرة التبادلية، والضغط على المضيف. غيّر حد الذاكرة فقط بين كل تشغيل وآخر.
الحد الذي ينجح أثناء تشغيل الخمول لكنه يفشل عند عرض الترجمة النصية أو تحويل HDR أو الفهرسة ليس إعدادًا صالحًا للإنتاج. سجّل العامل الذي تسبب في الفشل حتى لا ترفع الحد لمعالجة اختناق غير ذي صلة.
إذا قُتلت الحاوية، فارفع الحد فقط بعد تقليل ذاكرة التخزين المؤقت غير الضرورية لعمليات التحويل أو فصل المهام الثقيلة. وإذا بدأ المضيف نفسه باستخدام الذاكرة التبادلية، فخفّض التزامن أو انقل إحدى المهام؛ إذ إن منح Jellyfin كل ذاكرة RAM المتبقية ينقل الفشل ببساطة إلى خدمة أخرى.
حدّد نقطة توقف وتحقق من استمرارية الإعداد
أبقِ تنبيهًا مرنًا دون الحد الصارم، واترك ذاكرة كافية للمضيف وخدمات التخزين وإعادة التشغيل النظيفة. ينبغي أن يحمي الحد الصارم المضيف، لا أن يخفي عملية غير محدودة النمو أو جهازًا بموارد غير كافية.
بعد تغيير الحد، أوقِف الحاوية وأعِد إنشاءها مرة واحدة، ثم كرر اختبار فحص المكتبة والتشغيل الأصلي. تحقق من أن الحد المهيأ لا يزال فعالًا بعد إعادة الإنشاء، وأن قاعدة البيانات تظل قابلة للكتابة.
أوقف الضبط واطلب التصعيد عندما تستمر أحداث نفاد الذاكرة عند حد لا يترك هامشًا للمضيف، أو تتلف قاعدة البيانات، أو تنمو العملية دون حمل عمل قابل للتكرار. احتفظ بالسجلات وبآخر إعداد معروف بأنه سليم قبل إجراء تغيير أكبر.
أعِد التحقق من ذروة التشغيل بعد إعادة تشغيل باردة
أعِد تشغيل المضيف، وانتظر حتى تُثبَّت وحدات التخزين وتبدأ الحاويات المجاورة، ثم أعد إنتاج مزيج التدفقات متعدد المستخدمين نفسه الذي كشف الحد في الأصل. لا تكتفِ بالتحقق من لوحة تحكم في وضع الخمول أو جلسة Direct Play واحدة.
يتأكد التعافي عندما يظل التشغيل مستقرًا، ولا تظهر عاصفة من استخدام الذاكرة التبادلية، وتبقى الحاوية دون حدها الأقصى، وتكتمل نسخة احتياطية جديدة أو عملية إعادة تشغيل من دون أخطاء مرتبطة بالذاكرة. قارن النتيجة بخط الأساس المسجل قبل الضبط.
أبقِ الإعداد عندما ينجح حمل العمل في ذروته مع وجود هامش قابل للقياس لدى المضيف. وإذا فشل فقط بعد بدء حاوية أخرى، فقسّم ميزانية الموارد أو أعد جدولة المهمة المتنافسة بدلًا من زيادة حد Jellyfin مرة أخرى.
المنتجات الموصى بها
الدعم والنصائح
المزيد للقراءة
كيفية تحسين اتصالات قاعدة بيانات Jellyfin للحاويات المتزامنة
ابدأ بمالك واحد لقاعدة البيانات، وقِس سلوك القفل في SQLite؛ ولا تُضف واجهة خلفية مختلفة إلا عندما يبرّر التزامن والاسترداد هذا التعقيد.
كيفية منع تكرار المهام أو عمليات الاستيراد في Jellyfin
ينشأ العمل المكرر عادةً بسبب تداخل أدوات الجدولة أو وجود أكثر من جهة كتابة؛ عيّن مسؤولًا واحدًا، ومسارًا واحدًا، وفحصًا واحدًا لاكتمال العمل.
كيفية إصلاح Jellyfin بعد امتلاء وحدة تخزين قاعدة البيانات الخاصة به
أوقف عمليات الكتابة، وحافظ على قاعدة البيانات وملفات WAL، وحرّر مساحةً دون حذف الحالة عشوائيًا، ثم تحقّق من السلامة والتكامل ومن عبء العمل الأصلي.
