Saat memecahkan masalah kinerja CPU pada Server SQL tervirtualisasi yang berjalan di VMware, salah satu hal pertama yang saya lakukan adalah memverifikasi bahwa konfigurasi mesin virtual bukan merupakan faktor penyebab masalah kinerja. Di mana server fisik memiliki 100% sumber daya yang tersedia yang didedikasikan untuk OS, mesin virtual tidak, jadi melihat beberapa item dasar di muka menghilangkan pemecahan masalah yang salah dan membuang-buang waktu. Di masa lalu saya telah membuat blog tentang pentingnya DBA memiliki akses hanya baca ke Pusat Virtual untuk VMware untuk pemecahan masalah dasar masalah kinerja. Namun, bahkan tanpa akses ke Virtual Center, masih mungkin untuk menemukan beberapa informasi dasar di dalam Windows yang dapat menyebabkan potensi masalah tingkat host yang memengaruhi kinerja.
Setiap mesin virtual VMware memiliki dua grup penghitung kinerja di Windows yang ditambahkan saat alat VMware diinstal di tamu; Prosesor VM dan Memori VM. Penghitung kinerja ini adalah salah satu hal pertama yang saya lihat setiap kali saya bekerja dengan mesin virtual di VMware, karena mereka memberi Anda gambaran tentang sumber daya apa yang diterima VM dari hypervisor. Grup Prosesor VM memiliki penghitung berikut:
- % Waktu Prosesor
- Kecepatan VM Efektif dalam MHz
- Kecepatan prosesor host dalam MHz
- Batas dalam MHz
- Reservasi dalam MHz
- Bagikan
Pada tamu VM yang menunjukkan Waktu Prosesor\% yang tinggi di Pengelola Tugas atau perfmon, memeriksa penghitung Prosesor VM akan memberikan akun akurat tentang alokasi sumber daya aktual yang diterima tamu VM. Jika kecepatan prosesor Host dalam MHz adalah 3000 dan tamu memiliki 8 CPU virtual yang dialokasikan untuk itu, maka kecepatan efektif maksimum untuk VM adalah 24000 MHz dan Kecepatan VM Efektif dalam penghitung MHz akan mencerminkan apakah VM benar-benar mendapatkan sumber daya dari sang penyelenggara. Biasanya jika ini masalahnya, Anda harus mulai melihat informasi tingkat host untuk mendiagnosis akar penyebab masalah lebih lanjut. Namun dalam keterlibatan klien baru-baru ini, ternyata tidak demikian.
VM klien dalam hal ini cocok dengan konfigurasi yang dijelaskan di atas dan memiliki kecepatan efektif maksimum 24000 MHz tetapi Kecepatan VM Efektif dalam penghitung MHz hanya rata-rata sekitar 6900 MHz dengan waktu Prosesor VM Windows Persen dipatok hampir 100%. Melihat tepat di bawah Penghitung Kecepatan VM Efektif dalam MHz mengungkapkan penyebab masalah:Batas dalam MHz adalah 7000, yang berarti bahwa VM memiliki batas penggunaan CPU yang dikonfigurasi pada 7000MHz di ESX, sehingga secara konsisten dibatasi oleh hypervisor di bawah memuat.
Penjelasan untuk ini adalah bahwa VM khusus ini telah digunakan untuk tujuan pengujian dalam bukti konsep dan awalnya ditempatkan bersama pada host VM yang sibuk; administrator VM tidak menginginkan beban kerja yang tidak diketahui yang menyebabkan masalah kinerja pada host tersebut. Jadi, untuk memastikan bahwa itu tidak akan berdampak negatif pada beban kerja produksi nyata pada host selama POC, itu dibatasi untuk hanya mengizinkan 7000 MHz CPU atau setara dengan 2 1/3 inti fisik pada host. Pada akhirnya, menghapus Batas CPU VM di ESX menghilangkan masalah CPU yang tinggi dalam Windows, dan masalah kinerja yang dialami klien hilang.
Grup penghitung Memori VM sama pentingnya dengan grup Prosesor VM untuk mengidentifikasi potensi masalah kinerja untuk SQL Server. Grup penghitung Memori VM berisi penghitung berikut:
- Memori Aktif dalam MB
- Memori Dibesarkan dalam MB
- Batas Memori dalam MB
- Memori Dipetakan dalam MB
- Overhead Memori dalam MB
- Reservasi Memori dalam MB
- Memori Bersama dalam MB
- Memori Bersama Disimpan dalam MB
- Pembagian Memori
- Memori Bertukar dalam MB
- Memori yang Digunakan dalam MB
Dari penghitung ini, yang secara khusus saya lihat adalah Memory Ballooned in MB dan Memory Swapped in MB, keduanya harus nol untuk beban kerja SQL Server. Memory Ballooned in MB counter memberi tahu berapa banyak memori yang telah diambil kembali dari VM tamu oleh driver balon karena overcommit memori pada host, yang akan menyebabkan SQL Server mengurangi penggunaan memori untuk merespons tekanan memori di Windows yang disebabkan oleh driver balon menggembungkan untuk mengambil memori dari VM. Penghitung Memory Swapped in MB melacak berapa banyak memori yang di-page ke disk oleh hypervisor host karena overcommit memori pada host yang tidak dapat diselesaikan dengan menggelembungkan tamu VM dengan driver balon. Panduan praktik terbaik VMware untuk SQL Server merekomendasikan penggunaan reservasi untuk menjamin bahwa SQL Server tidak membengkak atau keluar karena alasan kinerja, tetapi banyak administrator VM ragu-ragu untuk mengatur reservasi statis karena mengurangi fleksibilitas lingkungan.
Alat pemantauan, seperti SentryOne V Sentry, juga dapat membantu. Pertimbangkan kasus di mana Anda mungkin tidak memiliki akses langsung ke vCenter, tetapi seseorang dapat mengatur pemantauannya atas nama Anda. Sekarang Anda bisa mendapatkan visualisasi dan wawasan hebat tentang CPU, memori, dan bahkan masalah disk – baik di tingkat tamu maupun host – dan semua riwayat yang menyertainya juga. Pada dasbor di bawah, Anda dapat melihat metrik host di sebelah kiri (termasuk kerusakan CPU untuk co-stop dan waktu siap), dan metrik tamu di sebelah kanan:
Untuk mencoba fungsi ini dan fungsi lainnya dari SentryOne, Anda dapat mengunduh uji coba gratis.
Kesimpulan
Saat memecahkan masalah kinerja pada SQL Server tervirtualisasi di VMware, penting untuk melihat masalah dari sudut pandang holistik daripada melakukan pemecahan masalah "knee-jerk" hanya menggunakan informasi terbatas. Penghitung khusus VMware di Performance Monitor dapat menjadi cara yang bagus untuk memverifikasi dengan cepat bahwa VM mendapatkan alokasi sumber daya dasar dari host, sebelum mengambil langkah lebih lanjut untuk memecahkan masalah.
