Pada artikel ini, kita akan berbicara tentang penghitung kinerja memori akses acak (RAM) di vSphere.
Tampaknya dengan memori semuanya lebih jelas daripada dengan prosesor: jika VM memiliki masalah kinerja, sulit untuk tidak menyadarinya. Tetapi jika mereka muncul, jauh lebih sulit untuk menghadapinya. Tapi hal pertama yang pertama.
Sedikit teori
RAM mesin virtual diambil dari memori server tempat VM berjalan. Cukup jelas :). Jika RAM server tidak cukup untuk semua orang, ESXi mulai menggunakan teknik reklamasi memori untuk mengoptimalkan konsumsi RAM. Jika tidak, sistem operasi VM akan macet karena kesalahan akses RAM.
Teknik mana yang menggunakan ESXi memutuskan tergantung pada beban RAM:
Status memori
batas
Aktivitas
High
400% dari minGratis
Setelah mencapai batas atas, halaman memori besar dipecah menjadi halaman kecil (TPS berfungsi dalam mode standar).
Hapus
100% dari minGratis
Halaman memori besar dipecah menjadi halaman kecil, TPS dipaksa bekerja.
Lunak
64% dari minGratis
TPS + Balon
Sulit
32% dari minGratis
TPS + Kompres + Tukar
Rendah
16% dari minGratis
Kompres + Tukar + Blokir
minFree adalah RAM yang diperlukan agar hypervisor berfungsi.
Sebelum ESXi 4.1 inklusif, minFree telah diperbaiki secara default - 6% dari RAM server (persentasenya dapat diubah melalui opsi Mem.MinFreePct di ESXi). Di versi yang lebih baru, karena bertambahnya ukuran memori di server, minFree mulai dihitung berdasarkan jumlah memori host, dan bukan sebagai persentase tetap.
Nilai minFree (default) dihitung sebagai berikut:
Persentase memori yang dicadangkan untuk minFree
Rentang memori
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memori yang tersisa
Misalnya, untuk server dengan RAM 128 GB, nilai MinFree adalah:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
Nilai sebenarnya mungkin berbeda beberapa ratus MB, tergantung pada server dan RAM.
Persentase memori yang dicadangkan untuk minFree
Rentang memori
Nilai untuk 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Memori yang tersisa (100 GB)
1024 MB
Biasanya, untuk tegakan produktif, hanya keadaan Tinggi yang dianggap normal. Untuk bangku pengujian dan pengembangan, status Hapus/Lembut mungkin dapat diterima. Jika RAM di host kurang dari 64% MinFree, maka VM yang berjalan di dalamnya pasti mengalami masalah kinerja.
Di setiap status, teknik reklamasi memori tertentu diterapkan, dimulai dengan TPS, yang secara praktis tidak memengaruhi kinerja VM, dan diakhiri dengan Swapping. Saya akan memberi tahu Anda lebih banyak tentang mereka.
Berbagi Halaman Transparan (TPS). TPS, secara kasar, adalah deduplikasi halaman memori mesin virtual di server.
ESXi mencari halaman identik dari RAM mesin virtual dengan 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 kelebihan memori dapat dicapai dengan sedikit atau tanpa penurunan kinerja.
Mekanisme ini hanya bekerja untuk halaman memori 4 KB (halaman kecil). Hypervisor bahkan tidak mencoba menghapus halaman berukuran 2 MB (halaman besar): peluang untuk menemukan halaman identik dengan ukuran ini tidak besar.
Secara default, ESXi mengalokasikan memori ke halaman besar. Memecah halaman besar menjadi halaman kecil dimulai saat ambang status Tinggi tercapai dan dipaksa saat status Hapus tercapai (lihat tabel status hypervisor).
Jika Anda ingin TPS mulai bekerja tanpa menunggu RAM host terisi, di Opsi Lanjutan ESXi Anda perlu mengatur nilainya “Mem.AllocGuestLargePage” ke 0 (default 1). Kemudian alokasi halaman memori besar untuk mesin virtual akan dinonaktifkan.
Sejak Desember 2014, di semua rilis ESXi, TPS antar VM telah dinonaktifkan secara default, karena ditemukan kerentanan yang secara teoritis memungkinkan akses dari satu VM ke RAM VM lain. Detail di sini. Saya belum menemukan informasi tentang implementasi praktis dari eksploitasi kerentanan TPS.
Kebijakan TPS dikendalikan melalui opsi lanjutan “Mem.ShareForceSalting” di ESXi:
0 - TPS Antar-VM. TPS berfungsi untuk halaman VM yang berbeda;
1 – TPS untuk VM dengan nilai “sched.mem.pshare.salt” yang sama di VMX;
2 (default) - TPS Intra-VM. TPS berfungsi untuk halaman di dalam VM.
Sangat masuk akal untuk mematikan halaman besar dan mengaktifkan Inter-VM TPS di meja pengujian. Itu juga dapat digunakan untuk stand dengan jumlah besar dari jenis VM yang sama. Misalnya, pada dudukan dengan VDI, penghematan memori fisik bisa mencapai puluhan persen.
balon memori. Balon tidak lagi menjadi teknik yang tidak berbahaya dan transparan untuk sistem operasi VM seperti TPS. Tapi dengan aplikasi yang tepat, Anda bisa hidup dan bahkan bekerja dengan Ballooning.
Bersama dengan Vmware Tools, driver khusus yang disebut Driver Balon (alias vmmemctl) diinstal pada VM. Saat hypervisor mulai kehabisan memori fisik dan memasuki kondisi Soft, ESXi meminta VM untuk mengklaim kembali RAM yang tidak terpakai melalui Balloon Driver ini. Pengemudi, pada gilirannya, bekerja pada level sistem operasi dan meminta memori bebas darinya. Hypervisor melihat halaman mana dari memori fisik yang ditempati oleh Balloon Driver, mengambil memori dari mesin virtual dan mengembalikannya ke host. Tidak ada masalah dengan pengoperasian OS, karena pada level OS memori ditempati oleh Balloon Driver. Secara default Driver Balon dapat memakan hingga 65% dari memori VM.
Jika VMware Tools tidak diinstal pada VM atau Ballooning dinonaktifkan (saya tidak menyarankan, tetapi ada :), hypervisor segera beralih ke teknik penghapusan memori yang lebih ketat. Kesimpulan: pastikan VMware Tools ada di VM.
Pengoperasian Balloon Driver dapat diperiksa dari OS melalui VMware Tools.
kompresi memori. Teknik ini digunakan saat ESXi mencapai kondisi Hard. Sesuai dengan namanya, ESXi mencoba mengecilkan halaman RAM 4KB menjadi 2KB dan dengan demikian membebaskan sebagian ruang pada memori fisik server. Teknik ini secara signifikan meningkatkan waktu akses ke konten halaman RAM VM, karena halaman tersebut harus dibuka terlebih dahulu. Terkadang tidak semua halaman dapat dikompresi dan prosesnya sendiri memakan waktu. Oleh karena itu, teknik ini tidak terlalu efektif dalam praktiknya.
pertukaran memori. Setelah fase Kompresi Memori singkat, ESXi hampir pasti (kecuali jika VM telah pergi ke host lain atau dimatikan) akan beralih ke Swapping. Dan jika memori yang tersisa sangat sedikit (kondisi Rendah), maka hypervisor juga berhenti mengalokasikan halaman memori ke VM, yang dapat menyebabkan masalah pada OS tamu VM.
Begini cara kerja Swapping. Saat Anda menghidupkan mesin virtual, file dengan ekstensi .vswp dibuat untuknya. Ukurannya sama dengan RAM unreserved VM: ini adalah perbedaan antara memori yang dikonfigurasi dan yang dicadangkan. Saat Swapping sedang berjalan, ESXi membongkar halaman memori mesin virtual ke dalam file ini dan mulai bekerja dengannya alih-alih memori fisik server. Tentu saja, memori "operatif" seperti itu beberapa kali lipat lebih lambat dari yang asli, bahkan jika .vswp terletak pada penyimpanan cepat.
Tidak seperti Ballooning, ketika halaman yang tidak digunakan diambil dari VM, dengan Swapping, halaman yang digunakan secara aktif oleh OS atau aplikasi di dalam VM dapat dipindahkan ke disk. Akibatnya, kinerja VM turun ke titik beku. VM secara formal berfungsi dan setidaknya dapat dinonaktifkan dengan benar dari OS. Jika kamu sabar 😉
Jika VM beralih ke Swap, ini adalah situasi yang tidak normal, yang sebaiknya dihindari jika memungkinkan.
Penghitung kinerja memori VM utama
Jadi kami sampai pada poin utama. Untuk memantau status memori di VM, ada penghitung berikut:
Aktif — menunjukkan jumlah RAM (KB) yang dapat diakses VM pada periode pengukuran sebelumnya.
penggunaan - sama dengan Aktif, tetapi sebagai persentase dari RAM VM yang dikonfigurasi. Dihitung menggunakan rumus berikut: aktif ÷ ukuran memori yang dikonfigurasi mesin virtual.
Penggunaan Tinggi dan Aktif, masing-masing, tidak selalu menjadi indikator masalah kinerja VM. Jika VM secara agresif menggunakan memori (setidaknya mendapat akses ke sana), ini tidak berarti tidak ada cukup memori. Sebaliknya, ini adalah kesempatan untuk melihat apa yang terjadi di OS.
Ada Alarm Penggunaan Memori standar untuk VM:
bersama - jumlah RAM VM yang digandakan menggunakan TPS (di dalam VM atau di antara VM).
Memang - jumlah memori host fisik (KB) yang diberikan ke VM. Termasuk Dibagikan.
Dikonsumsi (Diberikan - Dibagikan) - jumlah memori fisik (KB) yang dikonsumsi VM dari host. Tidak termasuk Dibagikan.
Jika bagian dari memori VM diberikan bukan 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 Diberikan dan Dikonsumsi Tinggi sangat normal. Sistem operasi secara bertahap mengambil memori dari hypervisor dan tidak mengembalikannya. Seiring waktu, dalam VM yang berjalan aktif, nilai penghitung ini mendekati jumlah memori yang dikonfigurasi, dan tetap di sana.
Nol — jumlah VM RAM (KB), yang berisi nol. Memori semacam itu dianggap gratis oleh hypervisor dan dapat diberikan ke mesin virtual lainnya. Setelah OS tamu menulis sesuatu ke memori nol, itu masuk ke Dikonsumsi dan tidak kembali.
Overhead yang Dicadangkan — jumlah RAM VM, (KB) yang dicadangkan oleh hypervisor untuk operasi VM. Ini adalah jumlah yang kecil, tetapi harus tersedia di host, jika tidak, VM tidak akan dimulai.
Balon — jumlah RAM (KB) yang disita dari VM menggunakan Driver Balon.
Terkompresi - jumlah RAM (KB) yang dikompresi.
Bertukar - jumlah RAM (KB) yang, karena kurangnya memori fisik di server, dipindahkan ke disk.
Balon dan penghitung teknik reklamasi memori lainnya adalah nol.
Beginilah tampilan grafik dengan Penghitung memori untuk VM yang berfungsi normal dengan RAM 150 GB.
Pada grafik di bawah ini, VM memiliki masalah yang jelas. Di bawah grafik, Anda dapat melihat bahwa untuk VM ini, semua teknik yang dijelaskan untuk bekerja dengan RAM digunakan. Balon untuk VM ini jauh lebih besar daripada yang Dikonsumsi. Nyatanya, VM lebih mati daripada hidup.
ESXTOP
Seperti halnya CPU, jika kita ingin menilai situasi host dengan cepat, serta dinamikanya dengan interval hingga 2 detik, kita harus menggunakan ESXTOP.
Layar ESXTOP oleh Memori dipanggil dengan tombol "m" dan terlihat seperti ini (bidang B, D, H, J, K, L, O dipilih):
Parameter berikut akan menarik bagi kami:
Mem overcommit rata-rata - nilai rata-rata oversubscription memori pada host selama 1, 5 dan 15 menit. Jika di atas nol, maka ini adalah alasan untuk melihat apa yang terjadi, tetapi tidak selalu menjadi indikator masalah.
Dalam barisan PMEM/MB и 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), status host dalam memori (dalam kasus kami, tinggi).
Di barisan 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 statistik server umum tentang teknik reklamasi memori:
PSHARA/MB adalah statistik TPS;
TUKAR/MB — Tukar statistik penggunaan;
ZIP/MB — statistik kompresi halaman memori;
MEMCTL/MB — Statistik penggunaan Driver Balon.
Untuk VM individual, kami mungkin tertarik dengan informasi berikut. Saya menyembunyikan nama VM agar tidak membingungkan penonton :). Jika metrik ESXTOP mirip dengan penghitung di vSphere, saya memberikan penghitung yang sesuai.
MEMSZ — jumlah memori yang dikonfigurasi pada VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + tidak tersentuh.
GRANT — Diberikan kepada MB.
TCHD — Aktif dalam MB.
MCTL? - apakah Driver Balon diinstal pada VM.
MCTLSZ — Balon ke MB.
MCTLGT — jumlah RAM (MB) yang ingin diambil ESXi dari VM melalui Balloon Driver (Memctl Target).
MCTLMAX - jumlah maksimum RAM (MB) yang dapat diambil ESXi dari VM melalui Driver Balon.
SWCUR — jumlah RAM (MB) saat ini yang dialokasikan ke VM dari file Swap.
SWGT - jumlah RAM (MB) yang ingin diberikan ESXi ke VM dari file Swap (Target Swap).
Selain itu, melalui ESXTOP, Anda dapat melihat informasi lebih detail tentang topologi NUMA VM. Untuk melakukan ini, pilih bidang D, G:
KECIL – NUMA node tempat VM berada. Di sini Anda dapat langsung melihat vm lebar, yang tidak muat pada satu node NUMA.
NRMEM - berapa megabyte memori yang diambil VM dari node NUMA jarak jauh.
NLMEM - berapa megabyte memori yang diambil VM dari node NUMA lokal.
N%L – persentase memori VM pada node NUMA lokal (jika kurang dari 80%, masalah kinerja dapat terjadi).
Memori di hypervisor
Jika penghitung CPU untuk hypervisor biasanya tidak terlalu menarik, maka situasinya terbalik dengan memori. Penggunaan Memori yang Tinggi pada VM tidak selalu menunjukkan masalah kinerja, tetapi Penggunaan Memori yang tinggi pada hypervisor memicu teknik manajemen memori dan menyebabkan masalah kinerja pada VM. Alarm Penggunaan Memori Host harus dipantau untuk mencegah VM masuk ke Swap.
Batalkan pertukaran
Jika VM ada di Swap, kinerjanya sangat berkurang. Jejak balon dan kompresi dengan cepat menghilang setelah RAM gratis muncul 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 mem-boot ulang (lebih tepatnya, matikan/hidupkan wadah). Dimulai dengan ESXi 6.0, meskipun tidak cukup resmi, cara yang berfungsi dan andal untuk menghapus VM dari Swap telah muncul. Di salah satu konferensi, saya dapat berbicara dengan salah satu insinyur VMware yang bertanggung jawab atas Penjadwal CPU. Dia menegaskan bahwa metode ini cukup berhasil dan aman. Dalam pengalaman kami, tidak ada masalah dengan itu juga.
Perintah sebenarnya untuk menghapus VM dari Swap Duncan Epping. Saya tidak akan mengulangi uraian mendetail, cukup berikan contoh penggunaannya. Seperti yang Anda lihat di tangkapan layar, beberapa saat setelah eksekusi perintah yang ditentukan, Swap menghilang di VM.
Tip Manajemen Memori ESXi
Terakhir, berikut adalah beberapa tip yang akan membantu Anda menghindari masalah kinerja VM karena RAM:
- Hindari kelebihan memori dalam kelompok produktif. Sangat diinginkan untuk selalu memiliki ~20-30% memori kosong di kluster sehingga DRS (dan administrator) memiliki ruang untuk bermanuver, dan VM tidak masuk ke Swap selama migrasi. Juga, jangan lupakan margin untuk toleransi kesalahan. Sangat 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 ke seluruh server cluster tanpa masalah. Aturan ini, tentu saja, tidak universal :).
- Perhatikan Alarm Penggunaan Memori Host.
- Jangan lupa install VMware Tools di VM dan jangan matikan Ballooning.
- Pertimbangkan untuk mengaktifkan Inter-VM TPS dan menonaktifkan Halaman Besar di VDI dan lingkungan pengujian.
- Jika VM mengalami masalah kinerja, periksa apakah VM menggunakan memori dari node NUMA jarak jauh.
- Keluarkan VM Anda dari Swap secepat mungkin! Antara lain, jika VM ada di Swap, karena alasan yang jelas, sistem penyimpanan menderita.
Itu saja untuk saya tentang RAM. Di bawah ini adalah artikel terkait untuk mereka yang ingin menggali detailnya. Artikel selanjutnya akan dikhususkan untuk penyimpanan.
Berguna Link
Sumber: www.habr.com