عندما تبدأ بالتعامل بجدية مع تقنيات المحاكاة الافتراضية الحديثة، ستواجه عاجلاً أم آجلاً مشكلة متكررة: نادراً ما توفر الأجهزة الافتراضية نفس أداء الرسومات الذي يوفره نظام التشغيل المثبت مباشرة على الجهاز.بينما قد يعمل سطح المكتب المضيف بسلاسة حتى بدقة 4K، قد يكون سطح مكتب الجهاز الظاهري متقطعًا، مع تأخر في حركة الماوس، أو تمزق في الشاشة، أو مقاطع فيديو لا تعمل بسلاسة كما ينبغي.
يتكرر هذا السيناريو في البيئات المنزلية وفي منصات المؤسسات التي تستخدم KVM أو Proxmox أو VMware أو Hyper-V أو السحابة العامة.والشعور هو نفسه: "الخادم المضيف يعمل بشكل مثالي، لكن الجهاز الظاهري بطيء... ما الخطأ الذي أرتكبه؟ هل أحتاج إلى وحدة معالجة رسومات مخصصة، أو تقنية SR-IOV، أو تغيير برامج إدارة الأجهزة الافتراضية، أو ببساطة المزيد من قوة المعالجة المركزية الخام؟"
أداء الرسومات في الأجهزة الافتراضية: ما يمكن توقعه فعلاً
الخطوة الأولى هي تعديل التوقعات: لا تزال عملية تحويل أجهزة سطح المكتب إلى بيئة افتراضية مع تسريع ثلاثي الأبعاد "شبه أصلي" تشكل تحديًا.خاصة إذا كنت ترغب في مشاركة وحدة معالجة رسومات واحدة بين جهاز مضيف والعديد من الأجهزة الافتراضية دون اللجوء إلى حلول باهظة الثمن أو معقدة للغاية.
في حالة نموذجية مع نظام التشغيل Debian 12 كنظام مضيف عبر KVM، وجهاز كمبيوتر محمول Ryzen 7 PRO مزود بمعالج رسومات Radeon مدمج وشاشة بدقة 4Kيعمل سطح المكتب الفعلي بشكل مثالي: تحريك النوافذ فوري، وتحميل المواقع الإلكترونية سريع، وتشغيل فيديوهات يوتيوب بدقة 4K بسلاسة. مع ذلك، ينخفض الأداء على الأجهزة الافتراضية التي تعمل بنظام لينكس والمزودة برسومات virtio أو SPICE. تعاني صفحات الويب الثقيلة ومقاطع الفيديو عبر الإنترنت من المزيد من التأخير، كما أن سلاسة الأداء ليست جيدة مثل أداء الخادم المضيف..
عند اختبار تكوينات مختلفة (برنامج تشغيل VirtIO-GPU، وSPICE، وvirgl، وبرامج عرض عن بُعد مختلفة مثل virt-viewer، وعملاء Windows، وما إلى ذلك) لوحظ أن تم تحسين المؤشر والاستجابة العامة إلى حد ما، ولكن لا يزال هناك تمزق في الصورة، وفقدان الإطارات، وشعور واضح بأن سطح المكتب أقل "حيوية".يدفع هذا الكثيرين إلى التفكير فوراً في تمرير وحدة معالجة الرسومات (GPU passthrough). أو حتى تغيير المنصات.
من المهم أن نفهم أنه حتى في البنى التحتية القوية، تُضيف تقنية المحاكاة الافتراضية عبئًا بسيطًا على وحدة المعالجة المركزية وذاكرة الوصول العشوائي، وخاصة على عمليات الإدخال/الإخراج للقرص والرسومات.في أحمال الخوادم التقليدية (الويب، قواعد البيانات، الخدمات المصغرة) يكون هذا العبء مقبولاً؛ ولكن عندما تبدأ في طلب تفاعل رسومي دقيق، زمن استجابة منخفض، وفيديو سلسكل ميلي ثانية لها أهميتها.
الأجهزة الافتراضية مقابل الخوادم الفعلية: التأثير الحقيقي على الأداء
على الرغم من أننا نركز هنا على الرسومات، إلا أنه يجدر وضع المحاكاة الافتراضية في سياقها. تظل الخوادم المادية (الخوادم المعدنية المجردة) هي المعيار عندما تبحث عن الأداء الخام والحد الأدنى من زمن الاستجابة.وخاصة في قواعد البيانات عالية الأداء، والعرض ثلاثي الأبعاد، والذكاء الاصطناعي، أو البث المباشر في الوقت الفعلي.
تُظهر اختبارات الأداء النموذجية أن أداء الجهاز الظاهري المُهيأ جيدًا على KVM أو VMware قريب جدًا من أداء الجهاز الفعلي من حيث وحدة المعالجة المركزية وذاكرة الوصول العشوائي: خسائر تقريبية تتراوح بين 5-8% في وحدة المعالجة المركزية و7-13% في الذاكرةتكمن الفجوة الأكبر في التخزين. يمكن أن ينخفض معدل عمليات الإدخال/الإخراج في الثانية (IOPS) لـ 4K بنسبة 17-25%، وهو أمر بالغ الأهمية إذا كان عبء العمل لديك كثيفًا جدًا على القرص.
توجد هذه العقوبة أيضًا في التصميم الجرافيكي، مع اختلاف طفيف يتمثل في عادةً ما تشارك وحدة معالجة الرسومات الموارد مع العديد من الأجهزة الافتراضية، ويضيف مسار العرض (SPICE، VNC، RDP، البروتوكول الخاص بالمشرف، وما إلى ذلك) زمن الوصول والضغط.والنتيجة: النظام "ليس غير قابل للاستخدام"، ولكن عند مقارنته بالنظام المضيف، يبدو أقل سلاسة.
ولهذا السبب توجد حالات يكون فيها من المفيد التمسك بالأجهزة المعدنية المجردة: قواعد البيانات الكبيرة للمعاملات (مثل Oracle وSQL Server Enterprise وSAP HANA)، ومحركات الذكاء الاصطناعي/التعلم الآلي المزودة بوحدات معالجة رسومية ثقيلة، أو خوادم الألعاب/البث المباشر. مع متطلبات زمن استجابة صارمة للغاية. في هذه الحالات، يصبح عبء وحدة المعالجة المركزية والذاكرة والإدخال/الإخراج ووحدة معالجة الرسومات في طبقة المحاكاة الافتراضية أكثر وضوحًا.
بدلا من ذلك، تطبيقات الويب، والخدمات المصغرة، وبيئات التطوير، وأجهزة سطح المكتب المكتبية الافتراضية —حتى سطح مكتب خفيف الوزن في أوبونتو— إنها تتناسب بشكل جيد للغاية مع الأجهزة الافتراضية. فهي تستفيد من اللقطات، والتوافر العالي، والتوسع السريع، كما أن الانخفاض الطفيف في الأداء مقبول تمامًا.
وحدة المعالجة المركزية، وذاكرة الوصول العشوائي، والقرص، والشبكة: ما هي المقاييس التي يجب النظر إليها في جهاز افتراضي بطيء؟
قبل إلقاء اللوم على وحدة معالجة الرسومات، نحتاج إلى التأكد من أن أنت لست مقيدًا بوحدة المعالجة المركزية أو الذاكرة أو القرص أو الشبكةالعديد من مشاكل "بطء سطح المكتب" هي في الواقع تشبع مورد آخر: وحدة المعالجة المركزية تنتظر دورها، أو التبديل المكثف، أو القرص عند حده الأقصى.
في VMware vSphere، على سبيل المثال، تمر وحدة المعالجة المركزية لكل وحدة معالجة مركزية افتراضية بأربع حالات: تشغيل (عمل)، انتظار (انتظار/إدخال/إخراج أو خمول)، جاهز (في قائمة الانتظار بدون وحدة معالجة مركزية فعلية) و COSTOP (إيقاف مشترك في الأجهزة الافتراضية متعددة النوى)تُعد قيم READY أو COSTOP المرتفعة مؤشرات واضحة على التنافس وأن المضيف يعاني من اكتظاظ شديد.
بالنسبة لوحدات المعالجة المركزية، فإن المقاييس الرئيسية هي نسبة الاستخدام المستدام، واستخدام الميغاهرتز لكل وحدة معالجة مركزية افتراضية، وعدادات الجاهزية/إيقاف التشغيلإذا كان استخدام الجهاز الظاهري يتراوح باستمرار بين 90 و100%، أو كان جاهزًا لأكثر من 10% من الوقت، فهذا يعني أن الجهاز يعاني من ضغط كبير. إضافة المزيد من وحدات المعالجة المركزية الافتراضية بشكل عشوائي نادرًا ما يُجدي نفعًا إذا كان المضيف مُثقلًا بالفعل.
في الذاكرة، يجب أن نرعى يشمل الاستخدام العالمي الترحيل/التبديل، وعلى منصات مثل Azure أو Hyper-V، ملفات الترحيل أو التبديل على الأقراص الثانويةعندما تُظهر تلك المجلدات الكثير من عمليات القراءة/الكتابة، فهذه علامة واضحة على أن ذاكرة الوصول العشوائي (RAM) الخاصة بالجهاز الظاهري قد نفدت.
على القرص والشبكة، لوحظ ما يلي: متوسط زمن استجابة القراءة/الكتابة، وعمليات الإدخال/الإخراج في الثانية، وعرض نطاق الشبكةتعتبر فترات الكمون المستمرة التي تتجاوز 15-20 مللي ثانية على القرص أو انخفاضات في التوافر والمهلات في التخزين البعيد (Azure Storage، SAN، إلخ) من العوامل المباشرة التي تؤثر سلبًا على الأداء الملحوظ على سطح المكتب البعيد.
أدوات المراقبة والتشخيص: من ESXTOP إلى Azure Monitor
توفر الشركات المصنعة الكبرى أدوات متطورة لتحليل أداء الأجهزة الافتراضية. بعض الأمثلة:
- VMware: vCenter و ESXTOP.
- Azure: Azure Monitor و PerfInsights.
- Hyper-V: مراقب الأداء و PowerShell.
- KVM/Proxmox: مجموعات مثل top و htop و iostat و virt-top وواجهة الويب نفسها.
يُعد ESXTOP أداة كلاسيكية للتحليل في الوقت الفعلي. فهو يسمح لك بعرض المقاييس لكل وحدة معالجة مركزية افتراضية كل بضع ثوانٍ، مثل: %مستخدم، %تشغيل، %نظام، %انتظار، %خامل، %جاهز، %CSTP، %MLMTD وغيرها الكثير. القاعدة الأساسية: إذا ارتفعت نسبة %RDY أو %CSTP بشكل حاد، فهذا يعني أن لديك عددًا كبيرًا جدًا من وحدات المعالجة المركزية الافتراضية أو عددًا كبيرًا جدًا من الأجهزة الافتراضية بالنسبة للمضيف.
في Azure، يتيح لك تمكين التشخيص على مستوى الجهاز الظاهري وحساب التخزين الحصول على مخططات لـ وحدة المعالجة المركزية والذاكرة والقرص والشبكةإلى جانب مقاييس التوافر، وزمن الاستجابة، والتقييد، وأخطاء مهلة التخزين. تساعد هذه المعلومات في التمييز بين مشكلة في النظام الأساسي واختناق في جانبك ناتج عن زيادة عمليات الإدخال/الإخراج في الثانية أو معدل النقل.
في Hyper-V، يتم تقسيم العمل بين مدير Hyper-V، ومراقب الأداء، ومراقب الموارد، وأوامر PowerShellيمكنك فحص النوى المادية مقابل النوى المنطقية، وNUMA، وأقراص VHDX، والمحولات الافتراضية، وقوائم انتظار الأقراص، وغير ذلك الكثير لضبط الجزء الذي يعاني من قصور.
وبغض النظر عن الشركة المصنعة، توصي العديد من الأدلة بتشغيل اختبارات إجهاد محددة: sysbench لاختبار أداء المعالج، وstress-ng وmemtester لاختبار أداء الذاكرة، وfio لاختبار سرعة الإدخال/الإخراج للقرص، وiperf3 أو netperf لاختبار أداء الشبكة. يتيح لك هذا مقارنة أداء النظام الفعلي (Bare Metal) مع أداء الجهاز الظاهري (VM) بسهولة، والاطلاع على حدود كل برنامج إدارة أجهزة ظاهرية (Hypervisor).
تقنية المحاكاة الافتراضية لوحدة معالجة الرسومات: SR-IOV، وتقنية تمرير البيانات، والحلول الخاصة.
عندما يكون الاختناق واضحًا من الناحية الرسومية (تمزق الشاشة، انخفاض معدل الإطارات، بطء الرسوم المتحركة، تقطع الفيديو)، فقد حان الوقت للنظر في المحاكاة الافتراضية لوحدة معالجة الرسوماتتوجد هنا ثلاث مجموعات رئيسية من الحلول:
- تمرير وحدة معالجة الرسومات (تمرير PCI)يتم تخصيص بطاقة رسومات كاملة لجهاز افتراضي واحد. يوفر هذا أداءً قريبًا من الأداء الأصلي، ولكن مع قيود واضحة: تصبح وحدة معالجة الرسومات هذه غير متاحة للمضيف والأجهزة الافتراضية الأخرى، وعادةً ما تحتاج إلى مخرج فيديو مخصص لهذا الجهاز الافتراضي، وهو أمر غير مثالي إذا كنت تريد عرض كل شيء على نفس الشاشة.
- تقنية المحاكاة الافتراضية لوحدة معالجة الرسومات (GPU) بواسطة SR-IOV (تقنية المحاكاة الافتراضية للإدخال/الإخراج ذات الجذر الواحد)تتيح هذه التقنية عرض وظائف وحدة معالجة الرسومات الافتراضية (VFs) على أجهزة افتراضية مختلفة. الفكرة جذابة للغاية: مشاركة مكونات الرسومات بأقل قدر من الحمل الزائد. تروج إنتل لهذا النهج في وحدات معالجة الرسومات المدمجة Xe2 لأجهزة الكمبيوتر المحمولة (مثل Lunar Lake) وفي وحدات معالجة الرسومات لمراكز البيانات (Flex)، بينما تحتفظ AMD وNVIDIA بهذه الميزة بشكل أساسي لـ بطاقات عمل باهظة الثمن بالإضافة إلى ذلك، توجد في كثير من الأحيان نماذج ترخيص واشتراك غير سهلة الاستخدام للغاية بالنسبة للمستخدمين المنزليين أو الشركات الصغيرة.
- SR-IOV.هذا الحل إنها ليست شفافة تمامًا للأجهزة الافتراضية، وتتطلب برامج تشغيل محددة، ودعم BIOS/البرامج الثابتة، ودعم المشرف، ويمكن أن تسبب مشاكل توافق خاصة بها.ليس من المجدي دائمًا ترقية جميع مكونات جهازك (على سبيل المثال، شراء حاسوب محمول بمعالج Intel Lunar Lake لهذا الغرض فقط) إذا كانت بقية مهامك ستظل محدودة بعوامل أخرى. تحليل مكونات الحاسوب الشخصي يساعد في اتخاذ القرار.
- حلول افتراضية خاصة بوحدة معالجة الرسوماتمثل NVIDIA RTX vWS وNVIDIA VGX أو ما يخلفها. تجمع هذه التقنيات بين مكونات مادية محددة (على سبيل المثال، بطاقات VGX من نوع K1/K2 مزودة بمعالجات رسومية متعددة من نوع Kepler، وذاكرة GDDR5 كبيرة، وآلاف من أنوية CUDA) مع برنامج إدارة افتراضي لوحدة معالجة الرسوميات يسمح بتوزيع قدرة الحوسبة الرسومية على عشرات من أجهزة سطح المكتب الافتراضية.
تقنيات معالجة الرسومات الجزئية في بيئات سطح المكتب: virtio-gpu و virgl و SPICE
بالنسبة لأولئك الذين يستخدمون KVM أو QEMU أو Proxmox أو ما شابه، فإن المسار المعتاد يتضمن وحدات تحكم الرسومات شبه الافتراضية مثل virtio-gpu، بالإضافة إلى بروتوكولات سطح المكتب البعيد مثل SPICEعلى جانب الضيف، يتم تثبيت برنامج تشغيل "يفهم" هذا الجهاز الظاهري ويسمح بمستوى معين من التسريع الأساسي ثنائي/ثلاثي الأبعاد.
VirGL هي طبقة إضافية يقوم بترجمة استدعاءات OpenGL من الجهاز الضيف إلى وحدة معالجة الرسومات الخاصة بالجهاز المضيفوبالتالي، يستفيد التطبيق داخل الجهاز الظاهري بشكل غير مباشر من تسريع الرسومات ثلاثية الأبعاد الحقيقي. نظريًا، يُفترض أن يُحسّن هذا أداء الرسومات على سطح المكتب والتطبيقات. مع ذلك، عمليًا، قد يحدث العكس أحيانًا. فإذا كانت وحدة معالجة الرسومات المدمجة في الجهاز المضيف ضعيفة أو لم يكن التنفيذ مُتقنًا، يُلاحظ انخفاض ملحوظ في الأداء.
في الواقع، أفاد العديد من المستخدمين الذين يمتلكون وحدات معالجة رسومات مدمجة من AMD (مثل Renoir) أنه عند تفعيل VirGL، يصبح سطح مكتب الجهاز الظاهري أبطأ وأثقل بكثيرلدرجة أنها أسوأ من استخدام Virtio-GPU "بدون وحدة معالجة الرسومات". هذا لا يعني أن VirGL عديم الفائدة، لكن الأمر يعتمد بشكل كبير على التوافق بين المكونات. الأجهزة + برامج التشغيل + تحميل رسومات الجهاز الظاهري.
في بروكسموكس، الثلاثي virtio-gpu + SPICE + virt-viewer هذا عادةً ما يكون الحد الأدنى المعقول من الإعدادات لسطح مكتب لينكس بواجهة رسومية. فهو يسمح بمؤشر فأرة جيد، وتغيير حجم النوافذ، وضغط صور أفضل من VNC البسيط، ولكن مع ذلك... لا تتوقع نفس التجربة التي توفرها وحدة التحكم عن بعد VMware ESXi أو VMRCوالتي تم صقلها بشكل كبير بعد سنوات من التحسين.
لهذا السبب، يتفاجأ العديد من مديري الأنظمة القادمين من ESXi عند تجربة Proxmox. على الرغم من امتلاكه برنامج إدارة أجهزة افتراضية قوي للغاية، الشعور بـ "سرعة الاستجابة" لسطح المكتب البعيد أقل إلا إذا قمت بتعديل الكثير من الإعدادات الدقيقة أو استخدمت وحدة معالجة رسومات مخصصة.
متى يكون تمرير وحدة معالجة الرسومات (GPU passthrough) مفيدًا، ومتى لا يكون كذلك؟
لا تزال خاصية تمرير وحدة معالجة الرسومات (GPU passthrough) الخيار الأمثل من حيث الأداء لجهاز افتراضي محدد. مع ذلك، توجد عدة عيوب في سيناريوهات الاستخدام اليومي لأجهزة سطح المكتب. على سبيل المثال، الحاجة إلى مدخل شاشة إضافي، وفقدان وحدة معالجة الرسومات للمضيف، وتعقيدات إضافية (IOMMU، والمجموعات، وBIOS، وبرامج التشغيل، وأخطاء في وضع السكون، وما إلى ذلك)..
إذا كان هدفك هو ذلك تتمتع آلة افتراضية واحدة بتسريع ثلاثي الأبعاد كاملعادةً ما يكون الجهد المبذول مُجديًا. تسمح لك مشاريع مثل Looking Glass بإعادة "حقن" صورة الجهاز الظاهري في سطح مكتب المضيف لتجنب الحاجة إلى شاشات إضافية. ولكن، إذا كان ما تريده هو العديد من الأجهزة الافتراضية المكتبية أو التجريبية ذات مستوى أساسي جيد في اللغة الإنجليزيةنقل وحدة معالجة الرسومات إلى كل منها ليس أمراً ممكناً.
بالنسبة لأجهزة الكمبيوتر المكتبية القوية، يمكنك التفكير في مزيج هجين: وحدة معالجة الرسومات الأساسية للمضيف، وتمرير البيانات من وحدة معالجة رسومات ثانية أقل قوة لجهاز افتراضي محدد.بهذه الطريقة، تحافظ على سطح مكتب مضيف سهل الاستخدام للغاية، وتمنح تلك الآلة الافتراضية بيئة رسومية قريبة جدًا من البيئة الأصلية؛ تحليل جهاز الكمبيوتر المحمول يمكن أن يوفر ذلك منظورًا حول بدائل أجهزة الكمبيوتر المكتبية مقابل أجهزة الكمبيوتر المحمولة.
مع أجهزة الكمبيوتر المحمولة، تصبح الأمور أكثر تعقيداً. عادةً ما تحتوي على وحدة معالجة رسومات مدمجة واحدة (أو وحدة معالجة رسومات مدمجة + وحدة معالجة رسومات منفصلة مدمجة بشكل كبير مع البرامج الثابتة)مع محدودية الموارد وعدم وجود إمكانية واقعية لتثبيت بطاقة رسومات إضافية، نادراً ما يكون تمرير البيانات عبر الشبكة مجدياً. من الأنسب الاستفادة من خيارات المحاكاة الافتراضية الجزئية (مثل virtio-gpu وSPICE وRDP) لتقليل متطلبات الرسومات للأجهزة الافتراضية.
وخلاصة القول، تُعد خاصية Passthrough الأداة المناسبة لعدد قليل من الأجهزة الافتراضية ذات المتطلبات العالية جدًا.بالنسبة للمختبرات التي تحتوي على العديد من الأجهزة أو أجهزة سطح المكتب الخفيفة، فإنك تهتم أكثر بضبط برنامج إدارة الأجهزة الافتراضية، والتحكم في الحمل الزائد لوحدة المعالجة المركزية/ذاكرة الوصول العشوائي/الإدخال/الإخراج، واختيار بروتوكول سطح المكتب البعيد المناسب.
برامج إدارة الأجهزة الافتراضية، وNUMA، والذاكرة الديناميكية، وعوامل الأداء الأخرى
وبعيدًا عن وحدة معالجة الرسومات، فإن طريقة إدارة برنامج إدارة الأجهزة الافتراضية وحدة المعالجة المركزية، والذاكرة، والتخزين، والشبكة يؤثر ذلك بشكل مباشر على سلاسة سطح مكتب الجهاز الظاهري. تختلف فلسفات Hyper-V وKVM وVMware وغيرها إلى حد ما، لكنها تشترك جميعها في مفاهيم مشتركة.
تعتمد بنية Hyper-V، على سبيل المثال، على برنامج إدارة الأجهزة الافتراضية الذي يتحكم في الوصول إلى الأجهزة، وقسم جذر يحتوي على نظام الإدارة، وأقسام ثانوية للأجهزة الافتراضية.يتم دعم ذلك بتقنيات مثل NUMA الافتراضية، والذاكرة الديناميكية، والمحولات الافتراضية، وشبكة SR-IOV، وتحسينات التخزين مثل ODX.
تُعد تقنية NUMA (الوصول غير الموحد للذاكرة) بالغة الأهمية بشكل خاص في الخوادم ذات النوى المتعددة. إذا تم تقسيم جهاز افتراضي كبير بشكل سيئ بين عقد NUMA المادية، فإن زمن استجابة الذاكرة الخاص به سيزداد. ويتأثر الأداء سلبًا، حتى وإن بدت الموارد وفيرة نظريًا. من الناحية المثالية، ينبغي أن تتوافق بنية vNUMA للجهاز الظاهري مع بنية pNUMA للمضيف.
يمكن للذاكرة الديناميكية (في Hyper-V، وتقنية تضخيم الذاكرة في برامج إدارة الأجهزة الافتراضية الأخرى) توفير ذاكرة الوصول العشوائي العامة، ولكن لا يُعد هذا الخيار مناسبًا لأحمال العمل الحساسة للتأخير مثل قواعد البيانات أو أجهزة سطح المكتب التي تحتوي على العديد من التطبيقات المفتوحة.في مثل هذه الحالات، يُنصح بتخصيص ذاكرة ثابتة لتجنب التوقفات عندما يقرر برنامج إدارة الأجهزة الافتراضية استعادة ذاكرة الوصول العشوائي دفعة واحدة.
يُعد التخزين أكثر المعوقات شيوعاً. يُنصح به استخدم أقراص VHDX ذات الحجم الثابت، وافصل أقراص النظام والبيانات، واختر محركات أقراص SSD أو NVMe من فئة المؤسسات، وتجنب تكوينات RAID ذات سلوك الكتابة الضعيف (RAID 5/6) لأحمال العمل المكثفة.عند توفرها، تساعد وحدات التخزين المباشر (Storage Spaces Direct) أو مصفوفات NVMe في الحفاظ على زمن الاستجابة ضمن هوامش مقبولة.
يُنصح بتكوين الشبكة استخدم المحولات الافتراضية الخارجية على بطاقات الشبكة السريعة (10 جيجابت إيثرنت إن أمكن)، واستخدم خاصية تجميع بطاقات الشبكة، وقم بتمكين تقنية SR-IOV لأحمال الشبكة الثقيلة جدًا، وقم بضبط وحدة النقل القصوى (MTU) وعمليات التفريغ. لا يمكن ذلك إلا إذا كانت سلسلة الشبكة بأكملها تدعمه. قد يؤدي ضعف إعدادات الشبكة إلى جعل سطح المكتب البعيد، حتى مع وجود وحدة معالجة رسومات جيدة، يبدو أسوأ من المتوقع.
اختبار الإجهاد وحالات الاستخدام: متى نختار الجهاز الظاهري أم الجهاز الفعلي؟
من المهم اتخاذ قرار بشأن ما إذا كان ينبغي نقل عبء عمل الرسومات إلى جهاز افتراضي أو تركه على وسائط تخزين فعلية. اختبر باستخدام معايير وأدوات اختبار الضغط ينبغي قياس استخدام وحدة المعالجة المركزية، وذاكرة الوصول العشوائي، والقرص، والشبكة. وعند الإمكان، قياس استخدام وحدة معالجة الرسومات أيضًا. ومن الأفضل مقارنة التطبيق "الحقيقي" بالتطبيق نفسه عند تشغيله في جهاز افتراضي.
قد يكون النمط الواقعي كالتالي: قم بتشغيل sysbench أو Geekbench لاختبار وحدة المعالجة المركزية، وstress-ng أو memtester لاختبار ذاكرة الوصول العشوائي، وfio لاختبار عمليات الإدخال/الإخراج في الثانية (IOPS) وزمن استجابة القرص، وiperf3 لاختبار عرض النطاق الترددي للشبكة.، وبعض معايير الرسومات الأساسية (مثل glxgears أو اختبار WebGL المستند إلى المتصفح) على كل من المضيف والآلة الافتراضية.
إذا كان الانخفاض في الأداء ضمن الحدود المقبولة (على سبيل المثال، أقل من 10% على وحدة المعالجة المركزية/ذاكرة الوصول العشوائي، وخسارة تتراوح بين 15-20% على القرص.إذا بدا سطح المكتب البعيد سلسًا بما يكفي للاستخدام المقصود (أتمتة المكاتب، والإدارة، والتطوير الخفيف)، فإن المحاكاة الافتراضية خيار صالح تمامًا.
أما إذا كان التطبيق يعتمد بشكل كبير على وحدة معالجة الرسومات، زمن استجابة منخفض وإنتاجية إدخال/إخراج مستدامة عالية (الرسم في Blender، وبرامج التصميم بمساعدة الحاسوب الثقيلة، ومحركات الذكاء الاصطناعي التي تدرب نماذج كبيرة، والألعاب، وما إلى ذلك)، عادة ما تكون التجربة أفضل بكثير على خادم فعلي مزود بوحدة معالجة رسومات مخصصة أو على جهاز افتراضي/جهاز افتراضي ذي جودة احترافية.
يكمن المفتاح في اكتشاف المكون الذي يبطئ كل جهاز افتراضي (وحدة المعالجة المركزية الجاهزة، أو ذاكرة الوصول العشوائي غير الكافية، أو الإدخال/الإخراج المقيد، أو عدم وجود وحدة معالجة رسومات حقيقية، أو الشبكة البطيئة، أو بروتوكول سطح المكتب غير المحسن بشكل جيد). تطبيق الحل الأبسط والأكثر فعالية من حيث التكلفة الممكنة لتلك الحالةوخصص الاستثمارات الضخمة (وحدات معالجة الرسومات المخصصة، وتقنية SR-IOV، والأجهزة الاحترافية) لأحمال العمل التي تُحدث فيها فرقًا حقيقيًا.