Risiko Saat Menggunakan Memori Dinamis dalam Hyper-V

Virtualisasi sangat populer untuk organisasi:memungkinkan mereka untuk memanfaatkan perangkat keras dengan lebih baik dengan menggabungkan beberapa server ke satu host, menyediakan kemampuan HA, dan memberikan pengurangan berbagai biaya seperti pemanasan/pendinginan, lisensi SQL Server, dan perangkat keras. Saya telah terlibat dalam banyak proyek dengan organisasi untuk membantu mereka bermigrasi dari lingkungan fisik ke virtual dan telah membantu mereka merasakan manfaat ini.

Apa yang ingin saya bagikan dengan Anda dalam artikel ini adalah masalah aneh yang saya temui saat bekerja dengan Hyper-V di Windows Server 2012 R2 menggunakan Memori Dinamis. Saya harus mengakui bahwa sebagian besar pengetahuan saya tentang virtualisasi telah dengan VMware, namun itu berubah sekarang.

Saat bekerja dengan SQL Server di VMware, saya selalu menyarankan untuk mengatur reservasi untuk memori, jadi ketika saya menemukan fitur Memori Dinamis ini dengan Hyper-V, saya harus melakukan riset. Saya menemukan artikel (Panduan Konfigurasi Memori Dinamis Hyper-V) yang menjelaskan banyak manfaat dan persyaratan sistem untuk menggunakan Memori Dinamis. Fitur ini cukup keren dalam hal bagaimana Anda dapat menyediakan mesin virtual dengan lebih banyak atau lebih sedikit memori tanpa harus dimatikan.

Bermain-main dengan Hyper-V Saya menemukan bahwa penyediaan mesin virtual sangatlah mudah dan mudah dipelajari. Dengan sedikit usaha, saya dapat membangun lingkungan lab untuk mensimulasikan pengalaman yang dialami pelanggan saya. Penghargaan diberikan kepada bos saya karena memberi saya perangkat keras yang luar biasa untuk digunakan. Saya menjalankan Dell M6800 dengan prosesor i7, 32GB RAM dan dua SSD 1TB. Binatang ini lebih baik daripada banyak server yang pernah saya tangani.

Menggunakan VMware Workstation 11 di laptop saya, saya membuat tamu Windows Server 2012 R2 dengan 4 vCPU, RAM 24GB, dan penyimpanan 100GB. Setelah tamu dibuat dan ditambal, saya menambahkan peran Hyper-V dan menyediakan tamu di bawah Hyper-V. Tamu baru ini dibuat dengan Windows Server 2012 R2 dengan 2 vCPU, RAM 22 GB, dan penyimpanan 60 GB yang menjalankan SQL Server 2014 RTM.

Saya menjalankan tiga set tes, masing-masing menggunakan memori dinamis. Untuk setiap pengujian, saya menggunakan Pembangkit Data SQL Red Gate terhadap database AdventureWorks2014 untuk mengisi kumpulan buffer. Untuk pengujian pertama saya mulai dengan 512MB untuk nilai RAM Startup karena itu adalah jumlah minimum memori untuk memulai Windows Server 2012 R2 dan kumpulan buffer berhenti meningkat sekitar 8GB.

Untuk setiap pengujian saya akan memotong tabel pengujian saya, mematikan tamu, mengubah pengaturan memori dan memulai kembali tamu. Untuk pengujian kedua, saya meningkatkan RAM Startup menjadi 768MB dan kumpulan buffer hanya bertambah menjadi lebih dari 12GB.

Untuk pengujian ketiga dan terakhir, peningkatan RAM Startup menjadi 1024 MB, menjalankan generator data, dan kumpulan buffer dapat ditingkatkan hingga hanya di bawah 16 GB.

Melakukan sedikit matematika pada nilai-nilai ini menunjukkan bahwa kumpulan buffer tidak dapat tumbuh lebih dari 16 kali RAM Startup. Ini bisa sangat bermasalah untuk SQL Server jika Startup RAM kurang dari 1/16 ukuran memori maksimum. Mari kita pikirkan tentang tamu Hyper-V dengan 64GB RAM yang menjalankan SQL Server dengan nilai RAM Startup 1GB. Kami telah mengamati bahwa kumpulan buffer tidak akan dapat menggunakan lebih dari 16GB dengan konfigurasi ini, tetapi jika kami menetapkan nilai RAM Startup ke 4096MB maka kumpulan buffer akan dapat meningkat 16 kali memungkinkan kami untuk menggunakan semua 64GB.

Satu-satunya referensi yang dapat saya temukan tentang mengapa kumpulan buffer dibatasi hingga 16 kali nilai RAM Startup ada di halaman 8 dan 16 di whitepaper, Praktik Terbaik untuk Menjalankan SQL Server dengan HVDM. Dokumen ini menjelaskan bahwa karena nilai cache buffer dihitung pada waktu startup, itu adalah nilai statis dan tidak bertambah. Namun jika SQL Server mendeteksi bahwa Hot Add Memory didukung maka itu meningkatkan ukuran yang dicadangkan untuk ruang alamat virtual untuk kumpulan buffer sebanyak 16 kali memori startup. Dokumen ini juga menyatakan bahwa perilaku ini memengaruhi SQL Server 2008 R2 dan sebelumnya, namun pengujian saya dilakukan pada Windows Server 2012 R2 dengan SQL Server 2014 jadi saya akan menghubungi Microsoft untuk memperbarui dokumen praktik terbaik.

Karena sebagian besar DBA produksi tidak menyediakan mesin virtual atau bekerja berat di ruang itu, dan insinyur virtualisasi tidak mempelajari teknologi SQL Server terbaru dan terhebat, saya dapat memahami bagaimana informasi penting ini tentang bagaimana kumpulan buffer menangani Memori Dinamis tidak diketahui banyak orang. dari orang-orang.

Bahkan mengikuti artikel bisa menyesatkan. Dalam artikel Panduan Konfigurasi Memori Dinamis Hyper-V, deskripsi untuk RAM Startup berbunyi:

Pemanfaatan memori yang optimal untuk siapa, tuan rumah atau tamu? Jika admin virtualisasi membaca ini, mereka kemungkinan akan menentukan bahwa itu berarti memori minimum yang diizinkan untuk memulai sistem operasi.

Bertanggung jawab atas SQL Server berarti kita perlu mengetahui tentang teknologi lain yang dapat memengaruhi lingkungan kita. Dengan diperkenalkannya SAN dan virtualisasi, kita perlu memahami sepenuhnya bagaimana hal-hal di lingkungan tersebut dapat berdampak negatif terhadap SQL Server dan, yang lebih penting, cara mengomunikasikan masalah secara efektif kepada orang yang bertanggung jawab atas sistem tersebut. DBA tidak perlu mengetahui cara menyediakan penyimpanan di SAN atau cara menyediakan atau dapat mengelola lingkungan VMWare atau Hyper-V, tetapi mereka harus mengetahui dasar-dasar cara kerja.

Dengan mengetahui dasar-dasar tentang bagaimana SAN bekerja dengan array penyimpanan, jaringan penyimpanan, multi-pathing dan sebagainya, serta bagaimana hypervisor bekerja dengan penjadwalan CPU dan alokasi penyimpanan dalam virtualisasi, DBA dapat berkomunikasi dan memecahkan masalah dengan lebih baik ketika masalah muncul. . Selama bertahun-tahun saya telah berhasil bekerja dengan sejumlah SAN dan admin virtualisasi untuk membangun standar untuk SQL Server. Standar ini unik untuk SQL Server dan tidak selalu berlaku untuk server web atau aplikasi.

DBA tidak dapat benar-benar mengandalkan SAN dan admin virtualisasi untuk sepenuhnya memahami praktik terbaik untuk SQL Server, terlepas dari betapa menyenangkannya itu, jadi kita perlu mendidik diri kita sendiri sebaik mungkin tentang bagaimana bidang keahlian mereka dapat memengaruhi kita.

Selama pengujian saya, saya menggunakan kueri dari posting blog Paul Randal, Masalah kinerja dari memori buffer pool yang terbuang, untuk menentukan berapa banyak buffer pool yang digunakan database AdventureWorks2014. Saya telah menyertakan kode di bawah ini:

SELECT
    (CASE WHEN ([database_id] = 32767)
        THEN N'Resource Database'
        ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
    COUNT (*) * 8 / 1024 AS [MBUsed],
    SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id];

Kode ini juga bagus untuk memecahkan masalah database mana yang menggunakan sebagian besar kumpulan buffer sehingga Anda dapat mengetahui database mana yang harus Anda fokuskan untuk menyetel kueri berbiaya tinggi. Jika Anda adalah toko Hyper-V, hubungi admin Anda untuk melihat apakah Memori Dinamis dapat dikonfigurasi sedemikian rupa sehingga berdampak negatif pada server Anda.