KVM أم Xen أم LXC: ما الذي يعمل عليه VPS لديك؟

ما الذي تبيعه خطة VPS فعلياً

تُبنى خطة VPS على إحدى عائلات المحاكاة الافتراضية الثلاث: KVM أو Xen أو LXC. وليس هذا التفصيل متعلقاً بمعدات مزود الخدمة فقط. فهو يحدد ما إذا كنت ستحصل على نواة خاصة بك. وكل ما يهمك كمشترٍ ينتج عن هذه الحقيقة: تحميل الوحدات، والتحكم في swap، وتشغيل المحاكاة الافتراضية المتداخلة، وما إذا كان /proc يصف خادمك أم خادم شخص آخر، وما إذا كان من الممكن قياس وقت steal أصلاً.

توفر المحاكاة الافتراضية الكاملة (KVM وXen HVM) لكل مستأجر نواة وآلة افتراضية. ويوفر Xen شبه الافتراضي نواة أيضاً، لكنها تعرف أنها ضيف وتطلب من hypervisor تنفيذ الأعمال ذات الامتيازات نيابةً عنها. أما خطة الحاويات (LXC، أو عائلة OpenVZ وVirtuozzo) فتوفر لك نظام ملفات ومجموعة من namespaces على نواة مزود الخدمة. وتُباع الأنواع الثلاثة تحت الأحرف الثلاثة نفسها.

KVM مقابل Xen مقابل LXC: نواة واحدة لكل نظام، أم نواة مشتركة واحدة

في KVM وXen، يشير uname -r إلى نواتك. يمكنك تثبيت نواة مختلفة، وتحميل وحدة فيها، ثم إعادة التشغيل باستخدامها. لا يؤثر أي إجراء تنفذه هناك في مستأجر آخر. في خطة الحاويات، يشير uname -r إلى نواة المزوّد التي تعمل على المضيف وتشترك فيها جميع الحاويات الأخرى على الجهاز. لا يمكنك تغييرها، وسيقوم apt install linux-image-generic بفك حزم ملفات لن يتم تشغيلها أبداً.

هذا الفرق وحده أهم من أي جدول مواصفات. اقرأ بقية هذا الدليل باعتبارها نتائج مترتبة عليه.

المحاكاة الافتراضية الكاملة: KVM وXen HVM

KVM‏ (الآلة الافتراضية المستندة إلى النواة) وحدة داخل نواة Linux تحوّل مضيف Linux عادياً إلى hypervisor، باستخدام تعليمات Intel VT-x أو AMD-V المضمّنة في وحدة المعالجة المركزية. يوفّر QEMU العتاد الافتراضي المحيط بها، مثل القرص وبطاقة الشبكة ووحدة التحكم التسلسلية. أما Xen فهو تصميم مختلف. Xen هو hypervisor مستقل ويبدأ تشغيله قبل Linux. يعمل نطاق تحكم ذي امتيازات، يُسمى dom0، على تشغيل حزمة الإدارة، بينما يكون كل مستأجر في domU. يستخدم Xen HVM‏ (الآلة الافتراضية العتادية) امتدادات وحدة المعالجة المركزية نفسها التي يستخدمها KVM، وعادةً ما يستخدم برامج تشغيل paravirtual للقرص والشبكة لأن محاكاة العتاد بطيئة. يُسمى هذا المزيج PVHVM.

بالنسبة إلى المستأجر، يعمل النظامان بطريقة متشابهة تقريباً. تحصل على نواة، وbootloader، وجهاز كتل فعلي، وmodprobe يعمل، و/proc حقيقي، وswap تملكه، وإعادة تشغيل تبدأ الإقلاع فعلياً. إذا سمح لك المزوّد بإرفاق ISO، يمكنك تثبيت توزيعة لم يكن يوفّرها.

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

Xen بنمط Paravirtualised، وكيف تتعرّف إليه

ظهر Xen PV قبل أن تتوفر في وحدات المعالجة المركزية تعليمات المحاكاة الافتراضية. بدلاً من اعتراض التعليمات ذات الامتيازات، تُعدَّل نواة الضيف لاستدعاء الـhypervisor مباشرةً. ويعمل دون VT-x، وكان ذلك هو الهدف الأساسي في 2005. يحمّل pygrub أو pvgrub النواة من داخل صورة القرص الخاصة بك، لذلك فهي نواتك، لكن يجب بناؤها مع دعم ضيف PV.

تشمل العلامات التي تدل على استخدامه ما يلي: يعرض lscpu نوع المحاكاة الافتراضية على أنه para بدلاً من full، ويوجد /sys/hypervisor/type ويذكر Xen، وتظهر أقراصك على أنها xvda بدلاً من vda أو sda. لا تجد الأدوات التي تقرأ جداول SMBIOS أو DMI أي شيء تقرؤه، لأن ضيف PV لا يملك برنامجاً ثابتاً ينشر هذه الجداول.

وتكلفك هذه البنية دعم المحاكاة الافتراضية المتداخلة بشكل دائم. لا يُعرض للضيف PV أبداً امتدادات المحاكاة الافتراضية الخاصة بوحدة المعالجة المركزية، لذلك لا يمكن لأي hypervisor تشغيل نفسه داخله. لم ينتهِ Xen. لكن Xen PV تحديداً تراجع، وانتقل اتجاه المشروع إلى PVH وHVM. إذا ذكرت خطة ما «Xen»، فاسأل عن النوع المقصود. HVM هو VPS حديث عادي. أما PV فهو خطة ينبغي أن يكون سعرها أقل.

الحاويات الافتراضية: LXC وسلسلة OpenVZ

الحاوية الافتراضية هي مجموعة من Linux namespaces، أي عروض منفصلة لمعرّفات العمليات ونقاط التحميل وواجهات الشبكة واسم المضيف والمستخدمين، إضافة إلى cgroups، وهي مجموعات التحكم التي تفرض حدود الموارد على مستوى النواة، وتعمل جميعها على نواة Linux الخاصة بالمزوّد. إن init لديك عملية على المضيف. ويعمل ls لديك مباشرة على نواة المضيف، من دون محاكاة أو مجدول ثانٍ بينهما. لذلك تتميز الحاويات بالسرعة والكثافة العالية.

الأسماء التي قد تراها في صفحة الطلب هي LXC وProxmox VE containers، وهي مبنية على LXC، وOpenVZ وVirtuozzo. ويُعد OpenVZ 7 وVirtuozzo امتدادين تجاريين للفكرة نفسها.

تتغير بالنسبة إليك أربعة أمور:

• الوحدات. لن يقوم modprobe بإدراج أي شيء. إذا لم تكن WireGuard أو ZFS أو وحدة netfilter محددة موجودة مسبقاً في نواة المزوّد، فلا يمكنك استخدامها.
• sysctl. معظم /proc/sys للقراءة فقط. أما الشبكة فهي namespace حقيقية، لذلك يكون net.ipv4.ip_forward وما يجاوره قابلاً للكتابة عادةً. وتبقى إعدادات النظام على مستوى الجهاز، مثل vm.swappiness أو fs.file-max، تابعة للمضيف.
• الحاويات المتداخلة. لا يعمل Docker داخل حاوية LXC إلا إذا فعّل المزوّد nesting وكان برنامج تشغيل التخزين متوافقاً معه. اختبر ذلك قبل الشراء، ولا تفترض أنه سيعمل.
• إصدار النواة. سترث جدول ترقيات المزوّد، بما في ذلك عمليات إعادة التشغيل.

كيفية معرفة ما الذي اشتريته

شغّل هذه الأوامر على الخادم واقرأ النتائج معاً. لا يحسم أي أمر منفرد المسألة.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

يطبع systemd-detect-virt معرّفاً قصيراً واحداً من قائمة ثابتة. تشمل جهة الآلة kvm وqemu وxen وamazon وvmware. وتشمل جهة الحاوية lxc وlxc-libvirt وopenvz وdocker وsystemd-nspawn. عندما لا يكتشف شيئاً، يطبع none وينتهي بحالة خروج غير صفرية. تجيب صيغة -c عن تقنيات الحاويات فقط، لذلك فإن أي إجابة غير none فيها تحسم المسألة، مهما ذكرت صفحة البيع.

يذكر lscpu مورّد hypervisor، ويحدد ما إذا كان نوع المحاكاة الافتراضية كاملاً أو شبه افتراضي. وبهذا تميّز بين Xen HVM وXen PV. لا يوجد /sys/hypervisor/type إلا في Xen.

فحص /lib/modules هو الفحص الذي يتخطاه كثيرون، وهو الأكثر مباشرة. إذا كان الدليل الخاص بإصدار kernel المشغّل مفقوداً أو فارغاً، بينما يعمل النظام بوضوح بهذا kernel، فهذا يعني أن kernel لم يأتِ من نظام الملفات لديك. لقد أتى من المضيف، ولم تُثبَّت شجرة وحداته في image لديك. هذا يعني أنها حاوية.

للحصول على رأي ثانٍ مستقل، يشغّل sudo apt install -y virt-what && sudo virt-what اختبارات الاكتشاف بوصفه أداة مخصصة. يحتاج إلى root، ولا يطبع أي شيء على bare metal.

لماذا يصف /proc الجهاز الخطأ داخل الحاوية

في ضيف KVM أو Xen، يمثّل /proc/meminfo حساب نواة نظامك الخاصة للذاكرة التي منحك إياها الـhypervisor. وهذا يعكس حالة جهازك، ولا يخبرك بشيء عن المضيف. هذه هي وظيفة الآلة الافتراضية.

أما في الحاوية، فلا توجد نواة ثانية تجري هذا الحساب، لذلك يعرض /proc قيم /proc الخاصة بالمضيف. LXCFS هو نظام ملفات صغير يعيد كتابة بعض هذه الملفات لتتوافق مع حدود cgroup الخاصة بك، ويغطي /proc/cpuinfo و/proc/meminfo و/proc/stat و/proc/uptime و/proc/swaps و/proc/diskstats و/sys/devices/system/cpu/online. يحمّله Proxmox تلقائياً. لكن كثيراً من مزوّدي الخدمة الأصغر لا يفعلون ذلك. عندها يعرض free -m إجمالي ذاكرة المضيف، وقد يعرض nproc كل نواة في الجهاز، بينما يعرض uptime مدة تشغيل المضيف.

هذا ليس أمراً شكلياً، لأن البرامج تحدد حجم مواردها بالاعتماد على هذه الملفات. ويحصي nginx عدد الأنوية التي يستطيع رؤيتها باستخدام worker_processes auto. إذا كان المضيف يضم 64 نواة وكانت حصتك نواتين، فسيبدأ make -j$(nproc) تشغيل 64 compiler. أما JVM أو قاعدة البيانات التي تختار حجم ذاكرة التخزين المؤقت من MemTotal، فستختار قيمة سيرفضها cgroup الخاص بك، وتقتل النواة العملية عند بلوغها الحد. ويُسجَّل هذا الإنهاء في سجل نواة المضيف، الذي لا يمكنك قراءته.

توجد القيم المعتمدة في cgroup، وليس في /proc:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

هذه مسارات cgroup v2، وهي ما تستخدمه التوزيعات الحالية. تعني قراءة memory.max من max عدم تعيين حد على ذلك المستوى. يعرض cpu.max حصة وفترة بالميكروثانية، ولذلك يعني 200000 100000 نواتين من وقت CPU في كل فترة. في مضيف أقدم يستخدم cgroup v1، توجد القيم نفسها ضمن /sys/fs/cgroup/memory/memory.limit_in_bytes و/sys/fs/cgroup/cpu/cpu.cfs_quota_us.

المبادلة، ومن يملكها فعلياً

في KVM وXen، تكون مساحة المبادلة ملكاً لك. وهي ملف أو قسم على القرص، ويتولى kernel تنفيذ الترحيل.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

يجب أن يعرض swapon --show الملف الآن مع حجمه وأولويته. إذا رفض swapon الملف، فأنشئه باستخدام dd if=/dev/zero of=/swapfile bs=1M count=2048 بدلاً من ذلك، لأن بعض أنظمة الملفات ترفض الملف المخصّص مسبقاً الذي يحتوي على extents غير مكتوبة. أضف /swapfile none swap sw 0 0 إلى /etc/fstab، وإلا فستختفي مساحة المبادلة بعد إعادة التشغيل التالية.

في الحاوية، لا يكون أي من ذلك ملكاً لك. يحتاج swapon إلى capability لا تملكها الحاوية غير المميّزة، لذلك يفشل إنشاء ملف المبادلة الخاص بك بسبب الصلاحيات ولا يصل التنفيذ إلى القرص. ما تسميه الخطة مساحة مبادلة هو إعداد cgroup على المضيف، وتحديداً memory.swap.max في cgroup v2، وتدعمه أجهزة المبادلة الخاصة بالمضيف. كانت خطط OpenVZ الأقدم تبيع حصة باسم "vswap"، وكانت أقرب إلى رصيد استخدام مؤقت منها إلى مساحة على القرص. يمكنك قراءة الحد الأقصى. لكنك لا تتحكم في الجهاز الذي يستند إليه هذا الحد.

الافتراضية المتداخلة، وراية CPU الكاذبة

تعني الافتراضية المتداخلة تشغيل hypervisor داخل VPS لديك: ضيف QEMU، أو صندوق Vagrant، أو مختبر افتراضية متداخلة يضم أجهزته الافتراضية. يجب تحقق شرطين معاً. يجب أن يفعّل المزوّد التداخل على المضيف، ويجب أن تظهر لضيفك امتدادات الافتراضية في CPU.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

في ضيف KVM مع تفعيل التداخل، يوجد /dev/kvm، ويعرض kvm-ok بوضوح ما إذا كان يمكن استخدام التسريع. في Xen HVM، هذا ممكن تقنياً لكنه نادراً ما يُتاح. أما في Xen PV فلا يمكن حدوثه.

في الحاوية، يفشل الفحص بطريقة توضّح المشكلة. إنّ /proc/cpuinfo هو ملف المضيف، لذلك تكون راية vmx أو svm موجودة، وهي صحيحة فعلاً: فـCPU الفعلي الموجود تحتك يملك هذه التعليمات حقاً. لكنها ليست ملكك. لا يوجد /dev/kvm في مساحة الأسماء لديك، ولا يمكنك تحميل الوحدة kvm_intel، والراية التي قرأتها للتو تصف الجهاز الذي تعمل كضيف عليه، لا جهازاً تسيطر عليه. هذه أوضح حالة للقاعدة العامة. في الحاوية، تصف /proc مساحة الأسماء والعتاد المحيط بها، لا خادماً تملكه.

AES-NI وميزات CPU التي تتيحها خطتك

AES-NI (تعليمات AES الجديدة) هي مجموعة من تعليمات CPU تجعل تشفير AES أسرع عدة مرات من تنفيذ الحسابات نفسها في البرمجيات. وتعتمد عليها عمليات إنهاء TLS، وتشفير الأقراص، وSSH، ومسارات النسخ الاحتياطي.

في KVM، يحدد نموذج CPU الذي أعدّه المزوّد لـQEMU ما يراه الضيف. عند استخدام host passthrough، تظهر لك العلامات الفعلية. أما عند استخدام نموذج عام مثل qemu64، أو baseline قديم عمداً للسماح بترحيل الضيوف بين مضيفين غير متطابقين، فقد تكون علامة aes غائبة، وعندها يعود OpenSSL بهدوء إلى مساره البرمجي.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

الأمر الثالث هو المثال الوارد في دليل OpenSSL لتعطيل هذه التعليمات داخل المكتبة: فهو يمسح بت AES-NI وبت VAES ويترك الباقي دون تغيير. قارن رقمي معدل النقل. إذا كانا متقاربين، فهذا يعني أن المسار السريع لم يكن مستخدماً أصلاً، ولذلك يستحق التحقق من AES-NI على VPS بطريقة صحيحة قضاء خمس دقائق قبل الالتزام بخطة.

لا يملك الحاوي نموذج CPU أمامه، لذلك تكون العلامات الموجودة في /proc/cpuinfo هي العلامات الفعلية للمضيف، وهي تنطبق عليك. وهذه ميزة حقيقية لخطط الحاويات، وهي الحالة الوحيدة في هذا الدليل التي تعمل فيها النواة المشتركة لمصلحتك.

مصدر وقت السرقة، ولماذا لا يظهر في الحاوية

وقت السرقة هو الوقت الذي كانت فيه وحدة المعالجة المركزية الافتراضية جاهزة للتنفيذ لكنها لم تُنفَّذ، لأن الـhypervisor كان يشغّل جهة أخرى. يظهر هذا الوقت كـst في top وvmstat، وكالحقل الثامن في سطر cpu ضمن /proc/stat.

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

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

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

في الحاوية لن يتحرك ذلك العمود، لأنه لا يوجد hypervisor بينك وبين المجدول. تصطف عملياتك إلى جانب عمليات كل مستأجر آخر باعتبارها مهام عادية في مجدول CPU الخاص بالمضيف. يظهر التنافس على شكل استغراق العمل وقتًا أطول ببساطة، من دون عدّاد يذكر السبب. أقرب مكافئ لذلك هو تقييد الحصة: عندما يضبط المزوّد cpu.max، فإن /sys/fs/cgroup/cpu.stat يحسب فترات nr_throttled والميكروثواني throttled_usec التي قُضيت في انتظار نافذة الحصة التالية. يغطي ذلك حصتك أنت فقط، ولا يغطي مطلقًا التنافس مع الأنظمة المجاورة. انتبه إلى أمر واحد: إذا كان مضيف الحاويات لدى المزوّد عبارة عن آلة افتراضية بحد ذاته، فقد يظهر رقم للسرقة في /proc/stat، لكنه يخص ذلك المضيف لا يخصك.

المبالغة في البيع، ولماذا تكون خطة الحاويات أرخص

الإجابة الصادقة قصيرة. تكلف خطة الحاويات أقل لأن المزود يشارك الجهاز نفسه مع عدد أكبر من المستخدمين.

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

يُبالغ في بيع CPU في كل أنواع الخطط، بما في ذلك KVM، من خلال بيع عدد من vCPUs أكبر من عدد الأنوية. ويُستخدم thin provisioning للقرص تقريباً في كل مكان. تضيف الحاويات كثافة أكبر فوق ذلك: نواة واحدة، وذاكرة page cache واحدة، ومن دون عملية QEMU منفصلة لكل ضيف. لذلك يستوعب المضيف عدداً من المستأجرين أكبر بعدة مرات.

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

أيّهما تشتري؟

اشترِ KVM عندما تحتاج إلى kernel خاص بك: وحدات WireGuard أو ZFS، أو إصداراً محدداً من kernel، أو المحاكاة الافتراضية المتداخلة، أو تحكماً فعلياً في swap، أو حدوداً يمكنك شرحها لمدقق. اشترِ خطة حاويات عندما تشغّل خدمات عادية بميزانية محدودة، ويكون kernel لدى المزوّد محدثاً، وتكون قد تأكدت من أن الميزات التي تعتمد عليها مضمّنة فيه مسبقاً. اعتبر Xen HVM معادلاً لـKVM في معظم الاستخدامات، واطرح هذا السؤال قبل شراء أي خدمة ما زالت تُباع باسم Xen PV.

توجد طريقتان خارج هذا التقسيم. تمنح Firecracker microVMs كل مستأجر kernel حقيقياً مع زمن بدء قريب من زمن الحاوية، وهذا ما تستخدمه منصات serverless. تتيح لك حاويات نظام Incus تشغيل نموذج الحاويات بنفسك على عتاد تتحكم فيه، وهذا يختلف عن شراء حاوية جاهزة. إذا كانت المصطلحات هي موضع الإشكال، فتشرح ما هو VPS فعلياً والفرق بين VPS وVM وVPC المصطلحات التي يفترض هذا الدليل أنك تعرفها مسبقاً.

FAQ

كيف أعرف ما إذا كان VPS لدي يعمل على KVM أم داخل حاوية؟

شغّل systemd-detect-virt -c. تعني أي إجابة غير none أنك داخل حاوية، بغض النظر عن اسم المنتج الذي تحمله الخطة. أكّد ذلك بطريقتين إضافيتين، لأن وسائل الكشف قد تعطي نتائج مضللة. يذكر lscpu اسم مورّد الـhypervisor ويحدد ما إذا كان نوع المحاكاة الافتراضية كاملاً أم شبه افتراضي. يكون ls /lib/modules/$(uname -r) مفقوداً أو فارغاً في الحاوية، لأن النواة قيد التشغيل جاءت من المضيف ولم تُثبَّت شجرة وحداتها في نظام الملفات لديك. يعطي sudo virt-what إجابة مستقلة من أداة كُتبت لهذا السؤال وحده.

لماذا يعرض free -m ذاكرة أكبر بكثير من الذاكرة المضمّنة في خطتي؟

أنت تستخدم خطة حاوية من دون تركيب LXCFS، لذلك فإن /proc/meminfo هو ملف المضيف، ويعرض free ذاكرة المضيف بدقة. الحد الفعلي لديك تحدده cgroup. اقرأ /sys/fs/cgroup/memory.max لمعرفة الحد، و/sys/fs/cgroup/memory.current لمعرفة الاستخدام الحالي، أو استخدم /sys/fs/cgroup/memory/memory.limit_in_bytes على مضيف أقدم يعمل بإصدار cgroup v1. اضبط أي خدمة تحدد حجم cache أو مجموعة worker اعتماداً على ذلك الرقم، لا على free.

هل يمكنني تشغيل Docker أو WireGuard على VPS يعمل بـ LXC؟

أحياناً، وليس بسبب أي شيء تثبّته أنت. يعتمد كلاهما على نواة المزوّد، لأنك لا تستطيع تحميل module فيها. يعمل WireGuard عندما تكون الوحدة موجودة مسبقاً على المضيف ومكشوفة لك، ويكون تطبيق wireguard-go في userspace بديلاً عند عدم توفرها. يحتاج Docker إلى أن يسمح المزوّد بالتداخل، كما يحتاج إلى storage driver يعمل داخل الحاوية. اسأل قبل الشراء، أو اختبر على مدة يمكنك إلغاؤها دون التزام طويل.

لماذا لا يعرض VPS الذي يعمل داخل حاوية وقت steal أبداً؟

يوجد وقت steal فقط عندما يوزّع hypervisor وقت CPU افتراضياً، ويُبلَّغ عنه لأن ذلك الـhypervisor يكتب القيمة في صفحة تقرؤها نواتك. لا يوجد hypervisor أسفل الحاوية. عملياتك هي مهام عادية في مجدول المضيف، لذلك يظهر التزاحم في صورة بطء كل شيء من دون عدّاد يحدد سببه. اقرأ /sys/fs/cgroup/cpu.stat بدلاً من ذلك: يحسب nr_throttled وthrottled_usec الوقت الذي قضته cgroup في انتظار نافذة quota التالية لـCPU، وهو أقرب ما تملكه الحاوية إلى وقت steal.