Ketika ESX 5 dan Hyper-V di Windows Server 2012 dirilis dan mengubah batasan yang sebelumnya ada untuk ukuran VM, saya segera tahu bahwa kita akan melihat lebih banyak beban kerja SQL Server skala besar mulai divirtualisasikan. Saya telah bekerja dengan sejumlah pelanggan pada tahun lalu yang memvirtualisasikan 16-32 inti SQL Server dengan berbagai alasan, dari strategi Pemulihan Bencana yang disederhanakan yang cocok dengan bisnis lainnya, hingga konsolidasi dan total biaya kepemilikan yang lebih rendah pada perangkat keras yang lebih baru. platform. Salah satu alasan perubahan skalabilitas dengan ESX 5+ adalah pengenalan NUMA virtual (vNUMA) untuk tamu luas yang melebihi ukuran node NUMA perangkat keras individu. Dengan vNUMA, VM tamu dioptimalkan agar sesuai dengan topologi perangkat keras NUMA, memungkinkan sistem operasi tamu dan aplikasi yang sadar NUMA, seperti SQL Server, yang berjalan pada VM untuk memanfaatkan optimalisasi kinerja NUMA, seolah-olah mereka berjalan di server fisik.
Dalam VMware, topologi vNUMA tersedia pada perangkat keras versi 8 atau lebih tinggi, dan dikonfigurasi secara default jika jumlah vCPU lebih besar dari delapan untuk tamu. Dimungkinkan juga untuk mengonfigurasi topologi vNUMA secara manual untuk VM menggunakan opsi konfigurasi lanjutan, yang dapat berguna untuk VM yang memiliki lebih banyak memori yang dialokasikan untuknya daripada yang dapat disediakan oleh node NUMA fisik, tetapi masih menggunakan delapan vCPU atau lebih sedikit. Untuk sebagian besar, pengaturan konfigurasi default berfungsi untuk sebagian besar VM yang telah saya lihat selama beberapa tahun terakhir, tetapi ada skenario tertentu di mana topologi vNUMA default tidak ideal dan konfigurasi manual dapat memberikan beberapa manfaat. Baru-baru ini saya bekerja dengan klien dengan sejumlah 32 vCPU SQL Server VM dengan RAM 512GB yang dialokasikan melakukan beberapa penyetelan kinerja di mana topologi vNUMA tidak mendekati apa yang diharapkan.
Server host VM di lingkungan ini adalah empat soket E5-4650 delapan prosesor inti dan 1TB RAM, masing-masing didedikasikan untuk satu SQL Server VM di bawah operasi biasa, tetapi dengan kapasitas yang tersedia untuk mempertahankan dua VM dalam skenario kegagalan. Dengan tata letak perangkat keras ini, ada empat simpul NUMA, satu per soket, dan konfigurasi VM yang diharapkan juga akan memiliki 4 simpul vNUMA yang disajikan untuk konfigurasi 32 vCPU. Namun, apa yang saya temukan saat melihat DMV di SQL Server adalah bahwa ini tidak terjadi:
Gambar 1 – Konfigurasi vNUMA salah
Seperti yang mungkin Anda lihat pada gambar, ada yang salah dengan konfigurasi NUMA di server ini. Ada empat node memori dalam SQLOS dan hanya satu CPU Node, dengan semua vCPU dialokasikan di dalamnya. Sejujurnya, ini mengejutkan saya ketika saya melihatnya karena bertentangan dengan semua yang saya tahu tentang bagaimana SQLOS mengonfigurasi struktur internal pada saat startup. Setelah menggali sedikit di file ErrorLog, Performance Monitor, dan Windows Task Manager, saya mengunduh salinan CoreInfo dari SysInternals, dan melihat tata letak NUMA yang dilaporkan ke Windows.
Pemroses Logis ke Peta Soket:********———————— Soket 0
——–********—————- Soket 1
—————-********——– Soket 2
————————******** Soket 3
Prosesor Logis ke NUMA Node Map:
********************************* NUMA Node 0
Keluaran CoreInfo mengkonfirmasi bahwa VM menyajikan 32 vCPU sebagai 4 soket berbeda, tetapi kemudian mengelompokkan semua 32 vCPU ke dalam NUMA Node 0. Melihat penghitung kinerja Windows Server 2012 pada VM, saya dapat melihat dari grup penghitung Memori Node NUMA, bahwa 4 NUMA memori node disajikan ke OS dengan memori merata di seluruh node. Ini semua sejalan dengan apa yang saya lihat di SQLOS, dan saya juga dapat mengetahui dari entri ERRORLOG startup bahwa topeng cpu untuk node menutupi semua CPU yang tersedia ke CPU Node 0, tetapi empat Pengalokasi Halaman Besar sedang dibuat, satu untuk setiap simpul memori.
09/22/2013 05:03:37,Server,Unknown,Konfigurasi node:node 0:CPU mask:0x00000000ffffffff:0 Active CPU mask:0x00000000ffffffff:0. Pesan ini memberikan deskripsi konfigurasi NUMA untuk komputer ini. Ini adalah pesan informasi saja. Tidak diperlukan tindakan pengguna.22/09/2013 05:03:37,Server,Tidak Diketahui,Instance SQL Server ini terakhir kali dilaporkan menggunakan ID proses 1596 pada 22/9/2013 5:00:25 (lokal) 22/9/2013 10:00:25 (UTC). Ini adalah pesan informasi saja; tidak ada tindakan pengguna yang diperlukan.
09/22/2013 05:03:35,Server,Tidak Diketahui,Halaman Besar Dialokasikan:32MB
09/22/2013 05:03:35,Server,Tidak Diketahui,Besar Alokasi Halaman:32MB
2209/2013 05:03:35,Server,Tidak Diketahui,Halaman Besar Dialokasikan:32MB
09/22/2013 05:03:35,Server,Tidak Diketahui,Halaman Besar Dialokasikan :32MB
09/22/2013 05:03:35,Server,Unknown,Menggunakan halaman terkunci di manajer memori.
09/22/2013 05:03:35,Server,Unknown,Detected 524287 MB RAM. Ini adalah pesan informasi; tidak ada tindakan pengguna yang diperlukan.
22/09/2013 05:03:35,Server,Tidak diketahui,SQL Server dimulai dari basis prioritas normal (=7). Ini adalah pesan informasi saja. Tidak ada tindakan pengguna yang diperlukan.
09/22/2013 05:03:35,Server,Unknown,SQL Server mendeteksi 4 soket dengan 8 inti per soket dan 8 prosesor logis per soket 32 total prosesor logis; menggunakan 32 prosesor logis berdasarkan lisensi SQL Server. Ini adalah pesan informasi; tidak diperlukan tindakan pengguna.
Pada titik ini saya yakin itu adalah sesuatu yang terkait dengan konfigurasi VM, tetapi saya tidak dapat mengidentifikasi apa masalahnya secara spesifik karena saya belum pernah melihat perilaku ini pada VM SQL Server luas lainnya yang telah saya bantu klien di VMware ESX 5+ di masa lalu. Setelah membuat beberapa perubahan konfigurasi ke server VM pengujian yang tersedia, hanya tidak ada yang mengoreksi konfigurasi vNUMA yang disajikan di dalam VM. Setelah memanggil dukungan VMware, kami diminta untuk menonaktifkan fitur hotplug vCPU untuk VM pengujian dan melihat apakah itu memperbaiki masalah. Dengan hotplug yang dinonaktifkan pada VM, output CoreInfo mengonfirmasi bahwa pemetaan vNUMA prosesor untuk VM sekarang sudah benar:
Pemroses Logis ke Peta Soket:********———————— Soket 0
——–********—————- Soket 1
—————-********——– Soket 2
————————******** Soket 3
Prosesor Logis ke NUMA Node Map:
*********———————— NUMA Node 0
——–********————— - NUMA Node 1
—————-********——– NUMA Node 2
————————********* NUMA Node 3
Perilaku ini sebenarnya didokumentasikan dalam artikel VMware KB, (vNUMA dinonaktifkan jika VCPU hotplug diaktifkan), mulai Oktober 2013. Ini merupakan VM lebar pertama untuk SQL Server yang pernah saya gunakan di mana hotplug vCPU diaktifkan, dan itu bukan konfigurasi khas yang saya harapkan untuk VM 32 vCPU, tetapi merupakan bagian dari templat standar yang digunakan di klien dan kebetulan memengaruhi SQL Server mereka.
Efek vNUMA dinonaktifkan
Ada sejumlah efek yang dapat menyebabkan vNUMA dinonaktifkan seperti ini pada beban kerja, tetapi ada dua masalah khusus yang dapat memengaruhi SQL Server secara khusus di bawah jenis konfigurasi ini. Yang pertama adalah bahwa server mungkin memiliki masalah dengan akumulasi tunggu CMEMTHREAD karena ada 32 vCPU yang dialokasikan untuk satu node NUMA, dan partisi default untuk objek memori di SQLOS adalah per NUMA node. Masalah khusus ini didokumentasikan oleh Bob Dorr dalam grup CSS di Microsoft pada posting blog mereka SQL Server 2008/2008 R2 pada Mesin Lebih Baru dengan Lebih dari 8 CPU Disajikan per NUMA Node Mungkin Perlu Trace Flag 8048. Sebagai bagian dari melakukan tinjauan statistik tunggu pada VM dengan klien saya mencatat bahwa CMEMTHREAD adalah tipe menunggu tertinggi kedua mereka, yang tidak normal dari pengalaman saya dan menyebabkan saya melihat konfigurasi SQLOS NUMA yang ditunjukkan pada Gambar 1 di atas. Dalam hal ini tanda pelacakan bukanlah solusi, menghapus hotplug vCPU dari konfigurasi VM akan menyelesaikan masalah.
Masalah kedua yang akan memengaruhi SQL Server secara khusus jika Anda menggunakan versi yang belum ditambal terkait dengan manajemen memori NUMA di SQLOS, dan cara SQLOS melacak dan mengelola halaman Jauh selama fase peningkatan memori awal setelah startup instans. Perilaku ini didokumentasikan oleh Bob Dorr pada posting blog CSS, Cara Kerja:SQL Server (NUMA Local, Foreign, dan Away Memory Blocks). Pada dasarnya, ketika SQLOS mencoba alokasi memori node lokal selama peningkatan awal, jika alamat memori yang dikembalikan berasal dari node memori yang berbeda, halaman ditambahkan ke daftar Away, dan upaya alokasi memori lokal lainnya terjadi, dan proses berulang hingga alokasi memori lokal berhasil, atau target memori server tercapai. Karena tiga perempat dari memori instans kami ada di NUMA node tanpa penjadwal apa pun, ini menciptakan kondisi kinerja yang menurun selama peningkatan awal memori untuk instans. Pembaruan terbaru telah mengubah perilaku alokasi memori selama peningkatan awal untuk hanya mencoba alokasi memori lokal beberapa kali (nomor spesifik tidak didokumentasikan) sebelum menggunakan memori asing untuk melanjutkan pemrosesan. Pembaruan tersebut didokumentasikan dalam KB #2819662, MEMPERBAIKI:Masalah kinerja SQL Server di lingkungan NUMA.
Ringkasan
Untuk VM lebar, yang didefinisikan memiliki lebih dari 8 vCPU, vNUMA diinginkan untuk diteruskan ke VM oleh hypervisor untuk memungkinkan Windows dan SQL Server memanfaatkan pengoptimalan NUMA dalam basis kode mereka. Akibatnya, VM yang lebih luas ini seharusnya tidak mengaktifkan konfigurasi hotplug vCPU, karena ini tidak kompatibel dengan vNUMA dan dapat mengakibatkan penurunan kinerja SQL Server saat divirtualisasi.
