Banyak perubahan lisensi diperkenalkan di SQL Server 2012; yang paling signifikan adalah perpindahan dari lisensi berbasis soket ke lisensi berbasis inti untuk Edisi Perusahaan. Salah satu tantangan yang dihadapi Microsoft dengan perubahan ini adalah menyediakan jalur migrasi untuk pelanggan yang sebelumnya menggunakan lisensi berbasis Server+CAL untuk Enterprise Edition sebelum SQL Server 2012. Pelanggan di bawah Jaminan Perangkat Lunak dapat meningkatkan ke SQL Server 2012 Enterprise Edition dan masih menggunakan Server Lisensi +CAL (juga dikenal sebagai "kakek") tetapi dengan batasan hingga 20 prosesor logis, seperti yang didokumentasikan dalam Panduan Lisensi SQL Server 2012. Lisensi ini juga berlaku untuk VM dengan batas 4 VM yang dicakup oleh lisensi Enterprise Server+CAL, tetapi masih dengan batasan 20 prosesor logis yang sama seperti yang didokumentasikan dalam Panduan Lisensi Virtualisasi SQL Server 2012.
Banyak orang yang lengah dengan 20 batasan prosesor logis, meskipun didokumentasikan dalam panduan lisensi.
Entri dibuat dalam file ERRORLOG saat instans dijalankan, yang menentukan jumlah prosesor logis dan bahwa batasan 20 prosesor diterapkan:
Tanggal 14/11/2012 8:15:08 PMLog SQL Server (Saat Ini – 14/11/2012 8:17:00 PM)
Server Sumber
Pesan
SQL Server mendeteksi 2 soket dengan 16 inti per soket dan 16 prosesor logis per soket, 32 prosesor logis total; menggunakan 20 prosesor logis berdasarkan lisensi SQL Server. Ini adalah pesan informasi; tidak ada tindakan pengguna yang diperlukan.
Dengan konfigurasi default yang diterapkan SQL Server di bawah 20 batasan prosesor logis menggunakan Server+CAL, 20 penjadwal pertama TERLIHAT ONLINE dan penjadwal lainnya TERLIHAT OFFLINE. Akibatnya, masalah kinerja dapat terjadi untuk instance, karena ketidakseimbangan NUMA node scheduler. Untuk mendemonstrasikan ini, saya membuat VM di server uji Dell R720 kami yang memiliki dua soket dan prosesor Intel Xeon E5-2670 terpasang, masing-masing dengan 8 core dan Hyperthreading diaktifkan, menyediakan total 32 prosesor logis yang tersedia di Windows Server 2012 Datacenter Edition. VM dikonfigurasi untuk memiliki 32 CPU virtual dengan 16 prosesor virtual yang dialokasikan di dua node vNUMA.
Gambar 1 – setelan vNUMA
Di SQL Server di bawah model lisensi Enterprise Server+CAL, ini menghasilkan konfigurasi penjadwal yang mirip dengan berikut ini:
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulers;
Gambar 2 – Penjadwalan tugas di bawah Enterprise Server+CAL
Seperti yang Anda lihat, semua 16 prosesor logis di node NUMA pertama dan hanya empat prosesor logis di node NUMA kedua yang digunakan oleh instance. Ini menghasilkan ketidakseimbangan yang signifikan dari penjadwal antara dua node NUMA yang dapat menyebabkan masalah kinerja yang signifikan di bawah beban. Untuk mendemonstrasikan ini, saya memutar 300 koneksi yang menjalankan beban kerja AdventureWorks Books Online terhadap instance dan kemudian menangkap informasi penjadwal untuk penjadwal VISIBLE ONLINE dalam instance menggunakan kueri berikut:
SELECT parent_node_id, scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';
Contoh output dari kueri ini di bawah beban ditunjukkan pada Gambar 3 di bawah ini.
Gambar 3 – Penjadwal sedang dimuat dengan Enterprise Server+CAL
Anda juga dapat melihat gejala ini secara visual di alat pemantauan seperti SQL Sentry Performance Advisor:
Gambar 4 – Ketidakseimbangan NUMA seperti yang ditunjukkan pada SQL Sentry Performance Advisor
Informasi ini menunjukkan ketidakseimbangan yang signifikan dan akibatnya kinerja akan terpengaruh. Ini jelas terlihat dalam jumlah tugas yang dapat dijalankan untuk empat penjadwal di simpul NUMA kedua, yang tiga hingga empat kali lebih besar dari penjadwal di simpul NUMA pertama. Jadi apa sebenarnya masalahnya dan mengapa ini terjadi?
Pada pandangan pertama Anda mungkin berpikir bahwa ini adalah bug di SQL Server, tetapi sebenarnya tidak. Ini adalah sesuatu yang terjadi karena desain, meskipun saya ragu bahwa skenario ini diharapkan ketika batasan 20 prosesor logis awalnya diterapkan. Pada sistem berbasis NUMA, koneksi baru ditetapkan ke node NUMA secara round-robin, dan kemudian di dalam node NUMA koneksi ditetapkan ke penjadwal berdasarkan beban. Jika kita mengubah cara kita melihat data ini dan menggabungkan data berdasarkan parent_node_id, kita akan melihat bahwa tugas sebenarnya seimbang di seluruh NUMA node. Untuk melakukan ini, kita akan menggunakan kueri berikut, yang outputnya ditunjukkan pada Gambar 5.
Gambar 5 – NUMA node round-robin balance
Perilaku ini didokumentasikan di Buku Daring untuk SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Mengetahui apa yang saya ketahui tentang SQLOS, SQL Server, dan perangkat keras, ini masuk akal. Sebelum 20 batasan prosesor logis dalam SQL Server 2012 Enterprise Edition dengan lisensi Server+CAL, itu adalah skenario yang jarang terjadi bahwa SQL Server akan memiliki ketidakseimbangan penjadwal antara node NUMA di server produksi. Salah satu masalah dalam kasus khusus ini adalah cara NUMA virtual dilewatkan ke VM. Melakukan instalasi yang sama persis pada perangkat keras fisik memungkinkan semua penjadwal TERLIHAT ONLINE karena prosesor logis tambahan yang disajikan oleh hyperthread dapat dibedakan oleh SQL dan gratis.
Dengan kata lain, batas prosesor 20-logis sebenarnya menghasilkan 40 penjadwal ONLINE jika (a) itu bukan mesin virtual, (b) prosesornya adalah Intel, dan (c) hyper-threading diaktifkan.
Jadi kita melihat pesan ini di log kesalahan:
Tanggal 14/11/2012 10:36:18Log SQL Server (Saat Ini – 14/11/2012 10:36:00 PM)
Server Sumber
Pesan
SQL Server mendeteksi 2 soket dengan 8 inti per soket dan 16 prosesor logis per soket, total 32 prosesor logis; menggunakan 32 prosesor logis berdasarkan lisensi SQL Server. Ini adalah pesan informasi; tidak ada tindakan pengguna yang diperlukan.
Dan kueri yang sama seperti di atas menghasilkan 32 prosesor yang TERLIHAT ONLINE:
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE';
Gambar 6 – Konfigurasi yang sama pada perangkat keras fisik
Dalam hal ini, karena hanya ada 32 prosesor logis, batas 20 (baik, 40) inti tidak memengaruhi kami sama sekali, dan pekerjaan didistribusikan secara merata di semua inti.
Dalam skenario di mana batasan 20 prosesor mempengaruhi keseimbangan NUMA penjadwal, dimungkinkan untuk mengubah konfigurasi server secara manual untuk menyeimbangkan jumlah penjadwal ONLINE TERLIHAT di setiap node NUMA melalui penggunaan ALTER SERVER CONFIGURATION . Dalam contoh VM yang diberikan, perintah berikut akan mengonfigurasi 10 prosesor logis pertama di setiap node NUMA ke VISIBLE ONLINE.
ALTER SERVER CONFIGURATIONSET PROSES AFFINITY CPU =0 SAMPAI 9, 16 SAMPAI 25;
Dengan konfigurasi baru ini, menjalankan beban kerja 300 sesi yang sama dan beban kerja AdventureWorks Books Online, kita dapat melihat bahwa ketidakseimbangan beban tidak lagi terjadi.
Gambar 7 – Keseimbangan dipulihkan dengan konfigurasi manual
Dan lagi dengan menggunakan SQL Sentry Performance Advisor, kita dapat melihat beban CPU didistribusikan secara lebih merata di kedua node NUMA:
Gambar 8 – Keseimbangan NUMA seperti yang ditunjukkan pada SQL Sentry Performance Advisor
Masalah ini tidak terbatas pada VM dan cara CPU virtual disajikan ke OS. Dimungkinkan juga untuk mengalami masalah ini dengan perangkat keras fisik. Misalnya, Dell R910 yang lebih lama dengan empat soket dan delapan inti per soket, atau bahkan server berbasis AMD Opteron 6200 Interlagos dengan dua soket dan 16 inti per soket, yang menampilkan dirinya sebagai empat simpul NUMA dengan masing-masing delapan inti. Di bawah salah satu konfigurasi ini, ketidakseimbangan proses juga dapat mengakibatkan salah satu node NUMA disetel offline seluruhnya. Akibatnya, efek samping lain seperti memori dari node yang didistribusikan di seluruh node online yang mengarah ke masalah akses memori asing juga dapat menurunkan kinerja.
Ringkasan
Konfigurasi default SQL Server 2012 menggunakan lisensi Enterprise Edition untuk Server+CAL tidak ideal di bawah semua konfigurasi NUMA yang mungkin ada untuk SQL Server. Setiap kali lisensi Enterprise Server+CAL digunakan, konfigurasi NUMA dan status penjadwal per node NUMA perlu ditinjau untuk memastikan bahwa SQL Server dikonfigurasi untuk kinerja optimal. Masalah ini tidak terjadi di bawah lisensi berbasis inti karena semua penjadwal berlisensi dan TERLIHAT ONLINE.
