SQL Server Kaç CPU Çekirdeği Kullanabilir? Sürüm Sınırları, Offline Scheduler’lar ve VM Tuzakları

SQL Server lisansında her çekirdek için ödeme yaparsınız; ama bu, SQL Server’ın makinedeki her çekirdeği kullandığı anlamına gelmez. Sürüm sınırları, sanal makinenin işlemcileri sunma biçimi, eski Enterprise Server + CAL lisanslaması, NUMA düzeni ve affinity ayarları, işlemcilerin bir kısmı %100’de çalışırken diğerlerinin boşta kalmasına yol açabilir. Bu düşündüğünüzden sık yaşanır ve tek belirtisi, bir türlü ölçeklenmeyen bir sunucudur.

Bu rehberde SQL Server’ın işlemcileri scheduler’lara nasıl eşlediğini, SQL Server 2025’te sürümlere göre sınırları, offline scheduler’ların nasıl tespit edileceğini, sanal makinedeki soket tuzağını, NUMA node başına 64 mantıksal işlemci sınırını ve her durumun nasıl düzeltileceğini anlatıyoruz.

SQL Server İşlemcileri Nasıl Kullanır?

SQL Server işini doğrudan Windows thread’lerine bırakmaz; kendi zamanlama katmanı olan SQLOS’u çalıştırır:

• Bir request (bir sorgu ya da batch) bir veya daha fazla task‘a bölünür; paralel bir sorgunun birden fazla task’ı vardır.
• Her task bir worker thread’ine bağlanır.
• Worker’lar scheduler‘lar üzerinde çalışır. SQL Server’ın kullanmasına izin verilen her mantıksal işlemci için bir scheduler vardır ve bir scheduler’da aynı anda yalnızca bir worker çalışır.

Bir scheduler VISIBLE ONLINE (SQL Server o işlemciyi kullanıyor) ya da VISIBLE OFFLINE (işlemci var ama SQL Server’ın kullanmasına izin yok) olabilir. Offline scheduler’lar, veritabanı için hiçbir iş yapmayan işlemcilere ödeme yaptığınızın en net işaretidir.

SQL Server 2025’te Sürümlere Göre İşlem Gücü Sınırları

Her sürüm, tek bir instance’ın kullanabileceği soket ve çekirdek sayısını sınırlar:

Bu sınırların nasıl uygulandığını iki ayrıntı değiştirir:

• Fiziksel sunucuda sınır çekirdek sayısına göredir. Hyper-threading açıkken 32 çekirdekle sınırlı bir Standard instance 64 mantıksal işlemciye kadar kullanabilir.
• Sanal makinede ise sınır mantıksal işlemci (vCPU) sayısına göredir; çünkü konuk işletim sistemi fiziksel çekirdek düzenini göremez. Standard bir VM en fazla 32 vCPU kullanabilir.

Sınırlar sunucu başına değil, instance başınadır. Büyük bir host üzerindeki birden fazla instance’ın her biri kendi sınırına kadar kullanabilir; ancak her instance’ın lisanslanması gerekir.

SQL Server Tüm İşlemcilerinizi Kullanıyor mu?

En hızlı kontrol error log’dur. SQL Server her açılışta ne bulduğunu ve ne kadarını kullandığını yazar:

SQL Server detected 2 sockets with 24 cores per socket and 48 logical processors per socket, 96 total logical processors; using 40 logical processors based on SQL Server licensing. This is an informational message; no user action is required.

“Bilgilendirme” ifadesi burada yanıltıcı: bu örnekte 56 mantıksal işlemci boşta. Scheduler DMV’leriyle teyit edin:

-- SQL Server'ın gördüğü işlemci topolojisi
SELECT cpu_count, hyperthread_ratio, socket_count, cores_per_socket,
       numa_node_count, scheduler_count, virtual_machine_type_desc
FROM sys.dm_os_sys_info;

-- NUMA node başına online ve offline scheduler'lar
SELECT parent_node_id AS numa_node,
       status,
       COUNT(*)       AS schedulers,
       SUM(current_tasks_count)  AS current_tasks,
       SUM(runnable_tasks_count) AS runnable_tasks
FROM sys.dm_os_schedulers
WHERE status IN (N'VISIBLE ONLINE', N'VISIBLE OFFLINE')
GROUP BY parent_node_id, status
ORDER BY numa_node, status;

Herhangi bir VISIBLE OFFLINE satırı, işlemcilerin dışarıda kaldığı anlamına gelir. Online scheduler’larda sürekli sıfırdan büyük bir runnable_tasks değeri ise işin CPU için kuyrukta beklediğini gösterir; bunu yüksek SOS_SCHEDULER_YIELD beklemeleri ve signal wait süresi olarak da görürsünüz.

Durum 1: Sürüm Sınırı

En yaygın neden, sürümün makineden küçük olmasıdır: 48 çekirdekli bir host üzerinde Standard sürüm ya da dört çekirdekten büyük herhangi bir makinede Express. Ya instance’a verilen işlemcileri sürümün kullanabileceği kadara indirip boşta duran kapasiteye ödeme yapmayı bırakın, ya da donanıma uygun bir sürüme geçin. Bir sürüm yükseltmesi, yeni donanımdan çok daha fazla kapasite açabilir.

Sahadan bir örnek: 192 çekirdekli sunucuda %8 CPU

Bu durumun en çarpıcı örneklerinden biri, binlerce çalışanın eş zamanlı kullandığı kritik bir kamu sisteminde yaşandı. Uygulama ekranları yanıt vermiyor, iş akışları durma noktasına geliyordu; ancak sunucunun toplam CPU kullanımı yaklaşık %8’de görünüyordu. Sunucuda 192 çekirdek vardı, veritabanı motoru ise SQL Server 2014 Standard’dı.

Scheduler’lara bakıldığında tablo netleşti: Standard sürümün sınırı nedeniyle SQL Server yalnızca 16 çekirdeği kullanabiliyordu ve bu 16 çekirdeğin tamamı %100’deydi. Kalan 176 çekirdek veritabanı için hiç yoktu. Toplam %8’lik kullanım tam olarak 16/192 oranıydı.

Kontrollü bir edition upgrade ile instance Enterprise’a yükseltildi, kamu hizmetleri kesintiye uğramadan 192 çekirdeğin tamamı kullanıma açıldı ve yanıt süreleri normale döndü. Çalışmanın ayrıntılarını SQL Server 2014 Standard’dan Enterprise’a upgrade ile 192 çekirdeğin kullanıma açılması başarı hikâyemizde anlatıyoruz.

Enterprise Server + CAL tuzağı

Server + CAL ile lisanslanmış Enterprise sürüm (yalnızca eski sözleşmelerde mevcuttur) instance başına 20 çekirdekle, yani hyper-threading ile 40 mantıksal işlemciyle sınırlıdır. Böyle bir instance’ı daha çok çekirdekli yeni donanıma taşıyan kurumlar, ek çekirdeklerin offline olduğunu sıkça görür. Çözüm çekirdek bazlı lisanslamaya geçmektir; yalnızca donanım eklemek işe yaramaz.

Durum 2: Sanal Makinedeki Soket Tuzağı

Standard sürüm dört soketle sınırlıdır. Bir VM, yaygın bir hypervisor varsayılanı olarak 8 vCPU’yu 8 soket × 1 çekirdek şeklinde sunarsa SQL Server Standard 8 soket görür ve yalnızca 4’ünü kullanır. VM’in işlemcilerinin yarısı offline kalır.

Çözüm SQL Server’da değil, hypervisor yapılandırmasındadır: aynı vCPU’ları daha az soket ve soket başına daha fazla çekirdek olarak sunun; örneğin 1 soket × 8 çekirdek ya da 2 soket × 4 çekirdek, tercihen host’un fiziksel NUMA düzenine uygun şekilde. VM’in yeniden başlatılmasını gerektirir.

Durum 3: Dengesiz NUMA Node’ları

SQL Server işlemcilerin yalnızca bir kısmını kullanabildiğinde, izin verilenleri varsayılan olarak NUMA node’larına eşit dağıtmaz. Sonuç, bir node’da tüm scheduler’ların online, diğerinde neredeyse hiçbirinin online olmaması olabilir; bellek ve iş yükü makinenin bir tarafına yığılır.

Sürümü ya da işlemci sayısını değiştiremiyorsanız, her NUMA node’undan işlemci seçerek process affinity ile scheduler’ları dengeli şekilde online yapabilirsiniz:

-- Örnek: iki NUMA node'unun her birinden 20 mantıksal işlemci kullan
ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 19, 48 TO 67;

-- Varsayılana dön (SQL Server karar verir)
ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU = AUTO;

Durum 4: NUMA Node Başına 64’ten Fazla Mantıksal İşlemci

SQL Server, NUMA node başına en fazla 64 mantıksal işlemciyi destekler. Yüksek çekirdek sayılı modern CPU’lar, bir soketin tamamı SMT açıkken tek bir NUMA node olarak sunulduğunda bu sınırı aşabilir. Sınırın ötesinde stack dump’lar ve kararlılık sorunları görülebilir; SQL Server 2022 CU11’den itibaren veritabanı motoru böyle bir yapılandırmada hiç başlamaz.

Çözüm firmware’dedir: Intel Xeon’da sub-NUMA clustering’i (SNC), AMD’de NPS2 veya NPS4 gibi bir Nodes-per-Socket ayarını açarak her soketin birkaç küçük NUMA node olarak sunulmasını sağlayın. Bazı Azure VM boyutlarında SMT’yi kapatmak aynı sonucu verir.

Yeni Kurulumda Çekirdek Planlaması

Bu sorunların çoğu kurulumdan önce verilen birkaç kararla hiç yaşanmaz. Yeni bir SQL Server sunucusu ya da sanal makinesi planlarken:

• Sürümü donanıma göre seçin (ya da donanımı sürüme göre boyutlandırın). Standard için 32 çekirdeğin, Express için 4 çekirdeğin üzerindeki her işlemci boşta kalır ama lisanslanır.
• VM topolojisini oluşturma anında belirleyin: az soket, soket başına birden fazla çekirdek ve host’un NUMA düzenine uygun bir dağılım.
• Firmware ayarlarını kontrol edin: NUMA node başına 64 mantıksal işlemci sınırı, güç profili ve C-state ayarları.
• Kurulumdan hemen sonra error log’daki açılış mesajını okuyun ve offline scheduler olmadığını doğrulayın.
• MAXDOP, cost threshold ve tempdb dosya sayısını gerçek işlemci sayısına göre ayarlayın.

Kurulum aşamasındaki diğer adımları SQL Server kurulum kontrol listemizde topladık. Sunucu boyutlandırma, sürüm ve lisans seçimi, kurulum ve ilk yapılandırmayı birlikte planlamak isterseniz SQL Server kurulum ve yapılandırma hizmetimize göz atabilirsiniz.

Lisans Çekirdek Başına, Kullanım Sürüme Göre

Lisanslama ve kullanılabilir kapasite ayrı sorulardır. Çekirdek bazlı lisanslamada, sürüm hepsini kullanamasa bile işletim sisteminin ya da VM’in gördüğü her çekirdeği, VM veya işlemci başına en az dört çekirdek olmak üzere lisanslarsınız. Standard bir VM’e 48 vCPU vermek, SQL Server 32’sini kullanırken 48 çekirdeğe ödeme yapmak demektir.

Doğru boyutlandırma iki yönlüdür: sürümün kullanamadığı işlemcileri kaldırın ve bıraktığınız işlemcilerin online ve dengeli olduğundan emin olun. Sayım kurallarını SQL Server 2025 lisanslama rehberimizde anlatıyoruz.

İşlemciler Online Olduktan Sonra

SQL Server doğru sayıda scheduler’ı gördüğünde, bu sayıya bağlı ayarları gözden geçirin:

• MAXDOP: önerilen değer NUMA node başına mantıksal işlemci sayısına bağlıdır. MAXDOP yazımıza bakabilirsiniz.
• Cost threshold for parallelism: varsayılan 5 değeri modern iş yüklerinin çoğu için çok düşüktür.
• tempdb veri dosyaları: genellikle sekize kadar mantıksal işlemci başına bir dosya; contention devam ederse daha fazlası.
• Max worker threads: özel bir neden yoksa 0’da (otomatik) bırakın; otomatik değer işlemci sayısıyla ölçeklenir.
• Güç planı: Windows’u High performance’a alın ve BIOS güç profilini kontrol edin. Dengeli bir plan, kısa yük patlamalarında çekirdekleri düşük frekansta tutabilir.

CPU Kontrol Listesi

• Error log’daki açılış mesajı, SQL Server’ın hedeflenen tüm mantıksal işlemcileri kullandığını gösteriyor.
• VISIBLE OFFLINE scheduler yok ya da offline olanlar bilinçli bir tercih.
• Online scheduler’lar NUMA node’larına dengeli dağılmış.
• VM’ler az soket ve soket başına birden fazla çekirdekle yapılandırılmış.
• Hiçbir NUMA node 64’ten fazla mantıksal işlemci sunmuyor.
• Lisanslanan çekirdekler, sürümün kullanabildiği çekirdeklerle örtüşüyor.
• MAXDOP, cost threshold ve tempdb dosyaları gerçek işlemci sayısını yansıtıyor.
• Windows ve BIOS güç ayarları performansı öncelikli tutuyor.