هل تمنح الصفحات الضخمة للأجهزة الافتراضية في المختبر المنزلي ميزة أداء قابلة للقياس؟

يمكن للصفحات الضخمة أن تحقق ميزة قابلة للقياس لبعض الأجهزة الافتراضية في المختبرات المنزلية، لكنها ليست مفتاحًا شاملًا لتسريع المحاكاة الافتراضية. وأفضل المرشحين هي أعباء العمل ذات الذاكرة الكبيرة والحساسة لذاكرة TLB، مثل قواعد البيانات والخدمات الموجودة في الذاكرة وأجهزة معالجة الحزم والأجهزة الافتراضية التي تظل نشطة بما يكفي لجعل عبء جداول الصفحات مهمًا. أما جهاز Home Assistant الافتراضي قليل الحمل، أو جهاز Linux الافتراضي الصغير للأدوات المساعدة، أو جهاز الاختبار العرضي، فقد يكون الفرق صغيرًا جدًا بحيث لا يبرر حجز ذاكرة الوصول العشوائي.

القاعدة العملية هي اختبار الجهاز الافتراضي نفسه باستخدام الذاكرة العادية والصفحات الضخمة قبل اعتمادها نهائيًا. يتضمن Linux بالفعل الصفحات الضخمة الشفافة (THP)، بينما يمكن لـ KVM/libvirt أيضًا إسناد الضيف إلى صفحات HugeTLB صريحة. تستبدل الصفحات الضخمة الثابتة مرونة المضيف بإسناد أكثر قابلية للتنبؤ للصفحات الكبيرة، ولذلك قد يخسر الخادم المنزلي ذو الذاكرة المحدودة أو التجاوز المكثف أكثر مما يكسب.

تقلل الصفحات الضخمة من عمل ترجمة العناوين، لا من كل اختناقات الأجهزة الافتراضية

تستخدم معظم أنظمة Linux المستندة إلى x86 صفحات أساسية بحجم 4 KiB، بينما يمكن لأحجام الصفحات الأكبر مثل 2 MiB و1 GiB أن تعين قدرًا أكبر بكثير من الذاكرة بترجمة واحدة. يشرح توثيق الصفحات الضخمة الشفافة لنواة Linux الفائدة الأساسية: إذ يمكن للتعيين الأكبر أن يقلل حالات فقدان ذاكرة TLB، كما قد تصبح حالات الفقدان هذه أقل تكلفة في بيئات المحاكاة الافتراضية التي تستخدم جداول صفحات متداخلة.

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

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

ما الأجهزة الافتراضية في المختبر المنزلي الأكثر احتمالًا للاستفادة؟

تصبح الآلة الافتراضية مرشحًا أفضل للصفحات الضخمة كلما كبرت مجموعة ذاكرتها النشطة وظلت قيد الاستخدام المستمر. فقد تلمس قواعد البيانات ذات مخازن التخزين المؤقت الكبيرة، وذاكرات التخزين المؤقت داخل الذاكرة، ومحركات التحليلات، وأجهزة التوجيه الافتراضية عالية الإنتاجية، وبعض أعباء الألعاب أو الإنشاء، قدرًا كافيًا من الذاكرة بصورة متكررة بحيث تصبح قلة إدخالات TLB مفيدة. وتصف إرشادات KVM من Red Hat الصفحات الضخمة بالمثل بأنها مهمة بصفة خاصة لأعباء العمل الافتراضية ذات الذاكرة الكبيرة وكثيفة استخدام الذاكرة، وذلك في وثائق ضبط المحاكاة الافتراضية.

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

إذا كنت لا تزال تقرر مقدار سعة المحاكاة الافتراضية التي ينبغي أن يستضيفها الخادم نفسه، فإن مثال إعداد ZimaCube وProxmox من ZimaSpace يوفر سياقًا مفيدًا: ينبغي أن يأتي ضبط الذاكرة بعد أن يمتلك المضيف قدرًا كافيًا من ذاكرة RAM وسعة تخزين وإمكانات إدخال/إخراج لتشغيل الأجهزة الافتراضية التي تخطط لها فعليًا.

ينبغي أن تكون الصفحات الضخمة الشفافة جزءًا من خط الأساس

من الأخطاء الشائعة في القياس المعياري مقارنة الصفحات الضخمة الثابتة بنظام كان يستفيد بالفعل من الصفحات الضخمة الشفافة (THP) دون إدراك ذلك. يستطيع Linux الحديث دمج الذاكرة المناسبة بشفافية في تعيينات أكبر. وتوضح وثائق النواة أن THP تُبقي مزيدًا من ميزات إدارة الذاكرة متاحًا مقارنةً بحجز HugeTLB الثابت، كما يمكنها استخدام الذاكرة الحرة بمرونة أكبر.

وهذا يعني أن المقارنة الفعلية غالبًا ليست بين «صفحات بسعة 4 كيلوبايت وصفحات بسعة 2 ميبيبايت»، بل بين «سلوك THP المعتاد لدى المضيف وصفحات HugeTLB المحجوزة صراحةً لهذا الجهاز الافتراضي». وإذا كان THP يستوعب بالفعل جزءًا كبيرًا من نطاق الذاكرة الكبير المفيد، فقد يكون المكسب الإضافي من الصفحات الضخمة الثابتة محدودًا.

تحقق من المضيف قبل الاختبار:

cat /sys/kernel/mm/transparent_hugepage/enabled
grep -E 'AnonHugePages|HugePages|Hugepagesize' /proc/meminfo

كما تعرض نواة Linux عدادات THP في /proc/vmstat، ما يساعد على التأكد من أن المضيف يخصص الصفحات الضخمة ويدمجها فعليًا بدلًا من افتراض أن الميزة نشطة.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

تستبدل الصفحات الضخمة الثابتة المرونةَ بقابلية التنبؤ

يمكن لـ Libvirt طلب الصفحات الضخمة صراحةً من خلال إعداد <memoryBacking>. وتدعم وثائق XML للنطاق الحالية اختيار أحجام الصفحات وربطها بعُقد NUMA الخاصة بالضيف.

يُظهر Proxmox الفكرة الأساسية نفسها من خلال إعداد QEMU الخاص به. يوثّق مخطط qemu-server الحالي خياري الصفحات الضخمة بسعة 2 ميبيبايت و1 جيبيبايت، بالإضافة إلى وضع اختيار تلقائي. وهذا مفيد لأنه يجعل تفعيل الميزة سهلًا، لكن لا ينبغي الخلط بين سهولة الإعداد وضمان تحقيق زيادة في السرعة.

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

تصبح محاذاة NUMA أكثر أهمية كلما ازداد حجم المضيف

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

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

استخدم اختبار A/B قابلًا للتكرار بدلًا من رقم اصطناعي بارز

السؤال الصحيح ليس ما إذا كانت الصفحات الضخمة قد حسّنت أداء KVM من قبل. يمكنها ذلك. السؤال الصحيح هو ما إذا كانت تحسّنه في آلتك الافتراضية بما يكفي لتعويض فقدان مرونة الذاكرة.

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

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

متى تكون الأفضلية كبيرة بما يكفي للإبقاء عليها؟

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

الصفحات الضخمة تحسين يأتي بعد الاختناقات الأكبر

لا تفعّل الصفحات الضخمة قبل التحقق مما إذا كانت الآلة الافتراضية مقيّدة بالمعالج أو بسعة الذاكرة أو بالتخزين أو بالشبكة. وعادةً ما يستفيد مختبر المنزل أكثر من إصلاح الاختناقات الواضحة أولًا: توفير ذاكرة RAM كافية لتجنب الترحيل، واستخدام تخزين سريع لأقراص الآلات الافتراضية، وضبط أجهزة VirtIO ضبطًا صحيحًا، وتحديد عدد وحدات vCPU بشكل معقول، واستخدام التمرير المباشر للأجهزة فقط عندما يحل مشكلة حقيقية في عبء العمل.

يطرح استعراض ZimaSpace حول الخوادم المستعملة وأجهزة الكمبيوتر الصغيرة وأجهزة NAS لمختبرات المنزل النقطة الأوسع نفسها: يبدأ أداء المحاكاة الافتراضية باختيار أجهزة تناسب عبء العمل. ويأتي ضبط حجم الصفحات كتحسين من الدرجة الثانية بعد التأكد من سلامة بنية المضيف.

الحكم النهائي

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

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

الأسئلة الشائعة

هل تكون الصفحات الضخمة بحجم 1 غيغابايت أسرع دائمًا من الصفحات الضخمة بحجم 2 ميغابايت؟

لا. تغطي الصفحات الأكبر مساحة عناوين أكبر لكل إدخال في TLB، لكن تخصيصات 1 غيغابايت أكثر خشونة وأصعب حجزًا. ويحدد عبء العمل وتخطيط ذاكرة المضيف ما إذا كانت ستساعد.

هل ينبغي أن تستخدم كل آلة افتراضية في Proxmox الصفحات الضخمة؟

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

هل تجعل الصفحات الضخمة الشفافة الصفحات الضخمة الثابتة غير ضرورية؟

ليس دائمًا. تُعد صفحات THP الضخمة الشفافة آلية تلقائية مرنة، بينما توفر صفحات HugeTLB الثابتة دعمًا أكثر وضوحًا وقابلية للتنبؤ. قارن بينهما تحت عبء العمل نفسه.

ما الذي ينبغي أن أختبره أولًا؟

اختبر أولًا معدل نقل التطبيق أو زمن استجابته، ثم أكّد الآلية باستخدام مقاييس ذاكرة المضيف وذاكرة TLB. لا يكون انخفاض عدد حالات فقدان TLB مهمًا إلا إذا حسّن الخدمة التي تهمك.