Manajemen memori VMware tampaknya menjadi tindakan penyeimbang yang rumit. Dengan cluster RAM, Resource Pools, teknik manajemen VMware (TPS, ballooning, host swapping), pemanfaatan RAM di dalam tamu, swapping, pemesanan, pembagian, dan batasan, ada banyak variabel.
Saya dalam situasi di mana klien menggunakan sumber daya kluster vSphere khusus. Namun, mereka mengkonfigurasi mesin virtual seolah-olah mereka menggunakan perangkat keras fisik. Pada gilirannya, ini berarti membangun VM standar mungkin memiliki 4 vCPU dan 16GB atau lebih RAM. Saya datang dari sekolah mulai dari kecil (1 vCPU, RAM minimal), memeriksa penggunaan dunia nyata dan menyesuaikan sesuai kebutuhan. Sayangnya, banyak persyaratan vendor dan orang yang tidak terbiasa dengan virtualisasi meminta lebih banyak sumber daya daripada yang diperlukan ... Saya tertarik untuk mengukur dampak keputusan ini.
Beberapa contoh dari kluster "masalah".
Ringkasan kumpulan sumber daya - Kelihatannya hampir 4: 1 terlalu berkomitmen. Perhatikan tingginya jumlah RAM yang menggelembung.
Alokasi sumber daya - Kolom Alokasi Kasus Terburuk menunjukkan bahwa VM ini akan memiliki akses ke kurang dari 50% RAM yang dikonfigurasikan dalam kondisi terbatas.
Grafik pemanfaatan memori real-time dari VM teratas dalam daftar di atas. 4 vCPU dan 64GB RAM dialokasikan. Ini rata-rata di bawah penggunaan 9GB.
Ringkasan dari VM yang sama
Apa kerugian dari sumber daya yang terlalu banyak berkomunikasi dan konfigurasi berlebihan (khususnya RAM) di lingkungan vSphere?
Dengan asumsi bahwa VM dapat berjalan dalam lebih sedikit RAM, apakah adil untuk mengatakan bahwa ada overhead untuk mengkonfigurasi mesin virtual dengan lebih banyak RAM daripada yang sebenarnya mereka butuhkan?
Apa argumen kontra untuk: "jika VM memiliki 16GB RAM yang dialokasikan, tetapi hanya menggunakan 4GB, apa masalahnya ?? "? Misalnya apakah pelanggan perlu dididik bahwa VM tidak sama dengan perangkat keras fisik?
Metrik spesifik apa yang harus digunakan untuk mengukur penggunaan RAM. Melacak puncak "Aktif" versus waktu? Menonton "Dikonsumsi"?
Pembaruan: Saya menggunakan vCenter Operations Manager untuk profil lingkungan ini dan mendapatkan beberapa detail pada statistik cluster yang tercantum di atas. Sementara hal-hal yang pasti overkomit, VMs sebenarnya sangat overconfigured dengan RAM yang tidak perlu bahwa jejak memori (kecil) nyata tidak menunjukkan pertengkaran memori di tingkat cluster / host ...
Takeaway saya adalah bahwa VMs harus benar-benar berukuran tepat dengan sedikit buffer untuk caching level OS. Komitmen berlebihan karena ketidaktahuan atau "persyaratan" vendor mengarah pada situasi yang disajikan di sini. Balon memori tampaknya buruk dalam setiap kasus, karena ada dampak kinerja, sehingga ukuran yang tepat dapat membantu mencegah hal ini.
Pembaruan 2: Beberapa VM ini mulai macet dengan:
kernel:BUG: soft lockup - CPU#1 stuck for 71s!
VMware menggambarkan ini sebagai gejala overcommitment memori yang besar . Jadi saya kira itu menjawab pertanyaan.
Laporan vCops "Mesin Virtual Oversized" ...
vCops "Limbah Dapat Diklaim" grafik ...