Bagian 1. Tentang CPUBagian 3. Tentang PenyimpananDalam artikel ini, kita akan berbicara tentang penghitung kinerja RAM di vSphere.
Tampaknya memori lebih dan lebih tidak ambigu daripada dengan prosesor: jika ada masalah kinerja pada VM, sulit untuk tidak melihatnya. Tetapi jika mereka muncul, berurusan dengan mereka jauh lebih sulit. Tetapi hal pertama yang pertama.
Sedikit teori
RAM mesin virtual diambil dari memori server tempat VM menjalankan. Ini cukup jelas :). Jika RAM server tidak cukup untuk semua orang, ESXi mulai menerapkan teknik reklamasi memori. Jika tidak, sistem operasi VM akan macet dengan kesalahan akses RAM.
Teknik apa yang digunakan untuk memutuskan ESXi tergantung pada beban RAM:
SumberminFree adalah RAM yang dibutuhkan agar hypervisor berfungsi.
Sebelum ESXi 4.1 inklusif, minFree telah diperbaiki secara default - 6% dari RAM server (persentase dapat diubah melalui opsi Mem.MinFreePct pada ESXi). Dalam versi yang lebih baru, karena peningkatan volume memori pada server minFree, mulai dihitung berdasarkan ukuran memori host, dan bukan sebagai nilai persentase tetap.
Nilai minFree (default) dihitung sebagai berikut:
SumberMisalnya, untuk server dengan 128 GB RAM, nilai MinFree adalah:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Nilai aktual dapat berbeda beberapa ratus MB, tergantung pada server dan RAM.
Biasanya, untuk tegakan produktif, hanya Tinggi yang dapat dianggap normal. Untuk tegakan uji dan pengembangan, kondisi Clear / Soft mungkin dapat diterima. Jika ada kurang dari 64% MinFree RAM yang tersisa di host, maka VM yang menjalankannya pasti akan mengalami masalah kinerja.
Di setiap negara, teknik reklamasi memori tertentu diterapkan dimulai dengan TPS, yang secara praktis tidak mempengaruhi kinerja VM, berakhir dengan Swapping. Saya akan memberi tahu Anda lebih banyak tentang mereka.
Berbagi Halaman Transparan (TPS). TPS, secara umum, deduplikasi halaman RAM mesin virtual di server.
ESXi mencari halaman identik dari RAM mesin virtual, menghitung dan membandingkan jumlah hash halaman, dan menghapus halaman duplikat, menggantinya dengan tautan ke halaman yang sama di memori fisik server. Akibatnya, konsumsi memori fisik berkurang, dan beberapa langganan memori dapat dicapai dengan sedikit atau tanpa kehilangan kinerja.
SumberMekanisme ini hanya berfungsi untuk 4 halaman kB (halaman kecil). Halaman dengan ukuran 2 MB (halaman besar) yang hypervisor bahkan tidak mencoba untuk deduplicate: kesempatan untuk menemukan halaman yang identik dengan ukuran ini tidak besar.
Secara default, ESXi mengalokasikan memori ke halaman besar. Pemecahan halaman besar menjadi kecil dimulai ketika ambang negara tinggi tercapai dan dipaksa ketika negara jelas tercapai (lihat tabel negara hypervisor).
Jika Anda ingin TPS mulai bekerja tanpa menunggu RAM host terisi, di Advanced Options ESXi Anda perlu mengatur nilai
"Mem.AllocGuestLargePage" ke 0 (standarnya adalah 1). Kemudian alokasi halaman memori yang besar untuk mesin virtual akan dinonaktifkan.
Sejak Desember 2014, dalam semua rilis ESXi, TPS antara VM telah dinonaktifkan secara default, karena kerentanan telah ditemukan yang secara teoritis memungkinkan mengakses RAM VM lain dari satu VM. Detail di sini. Informasi tentang implementasi praktis dari eksploitasi kerentanan TPS yang belum saya temui.
Kebijakan TPS dikendalikan melalui opsi lanjutan
"Mem.ShareForceSalting" di ESXi:
0 - TPS Inter-VM. TPS berfungsi untuk laman berbagai VM;
1 - TPS untuk VM dengan nilai yang sama "sched.mem.pshare.salt" di VMX;
2 (standar) - TPS Intra-VM. TPS berfungsi untuk halaman di dalam VM.
Masuk akal untuk mematikan halaman besar dan mengaktifkan TPS Inter-VM di bangku tes. Itu juga dapat digunakan untuk dudukan dengan sejumlah besar VM dari jenis yang sama. Misalnya, saat berdiri dengan VDI, penghematan memori fisik dapat mencapai puluhan persen.
Memory Ballooning. Balon tidak lagi merupakan teknik yang tidak berbahaya dan transparan untuk sistem operasi VM seperti TPS. Tetapi dengan penggunaan yang tepat dengan Ballooning Anda dapat hidup dan bahkan bekerja.
Bersama dengan Vmware Tools, driver khusus diinstal pada VM, disebut Balloon Driver (alias vmmemctl). Ketika hypervisor mulai kehabisan memori fisik dan memasuki kondisi lunak, ESXi meminta VM untuk mengembalikan RAM yang tidak digunakan melalui Driver Balon ini. Pengemudi, pada gilirannya, bekerja pada level sistem operasi dan meminta memori bebas darinya. Hypervisor melihat halaman mana dari memori fisik yang diambil oleh Driver Balon, mengambil memori dari mesin virtual, dan mengembalikannya ke host. Tidak ada masalah dengan pengoperasian OS, karena pada level OS memori ditempati oleh Driver Balloon. Secara default, Driver Balon dapat mengambil hingga 65% dari memori VM.
Jika VMware Tools tidak diinstal pada VM atau Ballooning dinonaktifkan (saya tidak merekomendasikannya, tetapi ada
KB :), hypervisor segera beralih ke metode yang lebih ketat untuk menghapus memori. Kesimpulan: pastikan bahwa VMware Tools pada VM adalah.
Pengoperasian Balloon Driver dapat diperiksa dari OS melalui VMware Tools .
Kompresi memori Teknik ini digunakan ketika ESXi mencapai Hard. Seperti namanya, ESXi sedang mencoba untuk mengompres 4 KB halaman RAM menjadi 2 KB dan dengan demikian membebaskan beberapa ruang dalam memori fisik server. Teknik ini secara signifikan meningkatkan waktu akses ke isi halaman-halaman memori RAM dari VM, karena halaman harus dibersihkan terlebih dahulu. Terkadang tidak semua halaman dapat dikompres dan prosesnya sendiri membutuhkan waktu. Karena itu, teknik ini tidak terlalu efektif dalam praktik.
Penukaran memori. Setelah fase singkat, Memory Compression ESXi hampir tidak terhindarkan (jika VM tidak pergi ke host lain atau mematikan) pergi ke Swapping. Dan jika memori yang tersisa sangat sedikit (Status rendah), maka hypervisor juga berhenti mengalokasikan halaman memori VM, yang dapat menyebabkan masalah pada VM tamu.
Beginilah cara Swapping bekerja. Ketika Anda menghidupkan mesin virtual, file dengan ekstensi .vswp dibuat untuk itu. Dalam ukurannya, ini sama dengan RAM non-cadangan dari VM: ini adalah perbedaan antara memori yang dikonfigurasi dan yang dipesan. Saat bekerja dengan Swapping, ESXi menurunkan halaman memori mesin virtual ke dalam file ini dan mulai bekerja dengannya alih-alih memori fisik server. Tentu saja, memori "RAM" seperti itu beberapa kali lipat lebih lambat dari memori sebenarnya, bahkan jika .vswp berada pada penyimpanan cepat.
Tidak seperti Ballooning, ketika halaman yang tidak digunakan dipilih dari VM, halaman yang secara aktif digunakan oleh OS atau aplikasi di dalam VM dapat pergi ke disk selama Swapping. Akibatnya, kinerja VM turun sampai hang. VM secara resmi berfungsi dan setidaknya dapat dinonaktifkan dengan benar dari OS. Jika Anda akan bersabar;)
Jika VM telah beralih ke Swap, ini adalah situasi abnormal yang sebaiknya dihindari jika mungkin.
Penghitung kinerja memori mesin virtual dasar
Jadi kami sampai pada hal utama. Untuk memantau status memori di VM, penghitung berikut tersedia:
Aktif - menunjukkan jumlah RAM (Kbytes) tempat VM memperoleh akses pada periode pengukuran sebelumnya.
Penggunaannya sama dengan Active, tetapi sebagai persentase dari memori VM yang dikonfigurasi. Itu dihitung menggunakan rumus berikut: memory aktif ukuran mesin dikonfigurasi memori virtual.
Penggunaan Tinggi dan Aktif, masing-masing, tidak selalu menunjukkan masalah kinerja VM. Jika VM secara agresif menggunakan memori (setidaknya mendapatkan akses ke sana), ini tidak berarti bahwa tidak ada cukup memori. Sebaliknya, ini adalah kesempatan untuk melihat apa yang terjadi di OS.
Ada Alarm standar tentang Penggunaan Memori untuk VM:
Shared - jumlah RAM dalam VM yang didupuplikasi menggunakan TPS (di dalam VM atau di antara VM).
Diberikan - jumlah memori fisik host (Kbytes) yang diberikan kepada VM. Termasuk Dibagikan.
Consumed (Granted - Shared) - jumlah memori fisik (Kbytes) yang dikonsumsi VM dari host. Tidak termasuk Dibagi.
Jika bagian dari memori VM tidak dialokasikan dari memori fisik host, tetapi dari file swap atau memori diambil dari VM melalui Driver Balon, jumlah ini tidak diperhitungkan dalam Granted and Consumed.
Nilai tinggi dari Granted dan Consumed sangat normal. Sistem operasi secara bertahap mengambil memori dari hypervisor dan tidak memberikan kembali. Seiring waktu, dengan VM yang berfungsi aktif, nilai-nilai penghitung ini mendekati jumlah memori yang dikonfigurasi, dan tetap ada.
Nol - jumlah RAM dalam VM (Kbytes), yang berisi nol. Memori tersebut dianggap sebagai hypervisor gratis dan dapat diberikan ke mesin virtual lainnya. Setelah OS tamu menerimanya, ia menulis sesuatu ke memori nol, ia pergi ke Dikonsumsi dan tidak kembali.
Reserved Overhead - jumlah RAM di VM, (Kbytes) dicadangkan oleh hypervisor agar VM berfungsi. Ini jumlah yang kecil, tetapi harus tersedia di host, jika tidak VM tidak akan mulai.
Balon - jumlah RAM (KB) yang disita dari VM menggunakan Driver Balon.
Compressed - jumlah RAM (KB) yang dapat dikompres.
Swapped - jumlah RAM (Kbytes), yang karena kurangnya memori fisik pada server dipindahkan ke disk.
Balon dan teknik reklamasi memori lainnya adalah nol.
Seperti inilah grafiknya dengan penghitung Memori dari VM yang biasanya berfungsi dengan 150 GB RAM.
Pada grafik di bawah ini, VM memiliki masalah yang jelas. Grafik menunjukkan bahwa untuk VM ini semua teknik yang dijelaskan untuk bekerja dengan RAM digunakan. Balon untuk VM ini jauh lebih besar daripada yang Dikonsumsi. Faktanya, VM lebih mungkin mati daripada hidup.
ESXTOP
Seperti halnya CPU, jika Anda ingin dengan cepat mengevaluasi situasi pada host, serta dinamika dengan interval hingga 2 detik, ada baiknya menggunakan ESXTOP.
Layar Memori ESXTOP disebut dengan tombol "m" dan terlihat seperti ini (bidang B, D, H, J, K, L, O dipilih):
Parameter berikut ini akan menarik bagi kami:
Mem overcommit avg - nilai rata-rata dari memory over-berlangganan pada host selama 1, 5, dan 15 menit. Jika di atas nol, maka ini adalah kesempatan untuk melihat apa yang terjadi, tetapi tidak selalu menjadi indikator adanya masalah.
Pada baris
PMEM / MB dan
VMKMEM / MB - informasi tentang memori fisik server dan memori yang tersedia untuk VMkernel. Dari yang menarik di sini Anda dapat melihat nilai minfree (dalam MB), keadaan host dari memori (dalam kasus kami, tinggi).
Pada baris
NUMA / MB, Anda dapat melihat distribusi RAM berdasarkan NUMA-node (soket). Dalam contoh ini, distribusinya tidak merata, yang pada prinsipnya tidak terlalu baik.
Berikut ini adalah ringkasan statistik server untuk teknik reklamasi memori:
PSHARE / MB adalah statistik TPS;
SWAP / MB - statistik tentang penggunaan Swap;
ZIP / MB - statistik kompresi halaman memori;
MEMCTL / MB - Statistik penggunaan Driver Balon.
Untuk masing-masing VM, kami mungkin tertarik pada informasi berikut. Saya menyembunyikan nama-nama VM agar tidak membuat malu penonton :). Jika metrik ESXTOP sama dengan penghitung di vSphere, saya kutip penghitung yang sesuai.
MEMSZ adalah jumlah memori yang dikonfigurasi pada VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + tidak tersentuh.
GRANT - Diberikan dalam MB.
TCHD - Aktif dalam MB.
MCTL? - diinstal pada Driver VM Balloon.
MCTLSZ - Balon dalam MB.
MCTLGT adalah jumlah RAM (MB) yang ingin dihapus ESXi dari VM melalui Driver Balon (Target Memctl).
MCTLMAX - jumlah maksimum RAM (MB) yang dapat dihapus ESXi dari VM melalui Driver Balon.
SWCUR - jumlah RAM (MB) saat ini yang diberikan kepada VM dari file Swap.
SWGT - jumlah RAM (MB) yang ingin diberikan ESXi dari file Swap (Swap Target).
Juga melalui ESXTOP Anda dapat melihat informasi lebih rinci tentang topologi NUMA VM. Untuk melakukan ini, pilih bidang D, G:
NHN - NUMA node tempat VM berada. Di sini Anda dapat segera melihat vm lebar yang tidak sesuai pada satu NUMA node.
NRMEM - berapa banyak megabita memori yang VM ambil dari simpul NUMA jarak jauh.
NLMEM - berapa megabyte memori yang VM ambil dari simpul NUMA lokal.
N% L - persentase memori VM pada simpul NUMA lokal (jika kurang dari 80%, masalah kinerja dapat terjadi).
Memori pada hypervisor
Jika penghitung CPU pada hypervisor biasanya tidak menarik, maka situasinya berlawanan dengan memori. Penggunaan Memori yang tinggi pada VM tidak selalu menunjukkan masalah kinerja, tetapi Penggunaan Memori yang tinggi pada hypervisor hanya memulai teknisi manajemen memori dan menyebabkan masalah dengan kinerja VM. Alarm Penggunaan Memori Host harus dipantau dan VM tidak diizinkan untuk masuk Swap.
Unswap
Jika VM masuk ke Swap, kinerjanya sangat berkurang. Balon dan jejak kompresi dengan cepat menghilang setelah munculnya RAM gratis di host, tetapi mesin virtual tidak terburu-buru untuk kembali dari Swap ke RAM server.
Sebelum ESXi 6.0, satu-satunya cara yang andal dan cepat untuk mengeluarkan VM dari Swap adalah dengan me-reboot (lebih tepatnya, mematikan / mematikan wadah). Dimulai dengan ESXi 6.0, cara yang tidak terlalu resmi, tetapi bekerja dan dapat diandalkan untuk mengeluarkan VM dari Swap. Di salah satu konferensi, saya berhasil berbicara dengan salah satu insinyur VMware yang bertanggung jawab untuk Penjadwal CPU. Dia menegaskan bahwa metode ini cukup berhasil dan aman. Dalam pengalaman kami, masalah dengannya juga tidak diperhatikan.
Perintah aktual untuk mengeluarkan VM dari Swap
dijelaskan oleh Duncan Epping. Saya tidak akan mengulangi uraian terperinci, cukup berikan contoh penggunaannya. Seperti yang dapat dilihat pada tangkapan layar, beberapa saat setelah eksekusi perintah Swap yang ditentukan pada VM menghilang.
Kiat untuk mengelola RAM pada ESXi
Sebagai kesimpulan, saya akan memberikan beberapa tips untuk membantu Anda menghindari masalah dengan kinerja VM karena RAM:
- Hindari kelebihan langganan RAM dalam kluster produktif. Itu selalu disarankan untuk memiliki ~ 20-30% memori bebas di cluster, sehingga DRS (dan administrator) memiliki ruang untuk bermanuver, dan VM tidak pergi ke Swap selama migrasi. Juga jangan lupa margin untuk toleransi kesalahan. Tidak menyenangkan ketika, ketika satu server gagal dan VM di-reboot menggunakan HA, beberapa mesin juga masuk ke Swap.
- Dalam infrastruktur yang sangat terkonsolidasi, cobalah untuk TIDAK membuat VM dengan lebih dari setengah memori host. Ini, sekali lagi, akan membantu DRS mendistribusikan mesin virtual di antara server cluster tanpa masalah. Aturan ini, tentu saja, tidak universal :).
- Hati-hati dengan Alarm Penggunaan Memori Host.
- Jangan lupa untuk meletakkan VMware Tools di VM dan jangan mematikan Ballooning.
- Pertimbangkan untuk mengaktifkan TPS Inter-VM dan menonaktifkan Halaman Besar di VDI dan lingkungan pengujian.
- Jika VM mengalami masalah kinerja, periksa untuk melihat apakah itu menggunakan memori dari node NUMA jauh.
- Dapatkan VM dari Swap secepat mungkin! Antara lain, jika VM ada di Swap, untuk alasan yang jelas, sistem penyimpanan menderita.
Itu saja untuk RAM. Di bawah ini adalah artikel terkait untuk mereka yang ingin mempelajari detailnya.
Artikel selanjutnya akan dikhususkan untuk cerita.