Bu makalede mssql server üzerinde CPU bekleme tiplerini detaylı bir şekilde görmüş olacağız. İlk olarak çalıştığım sistemde en çok bekleme tiplerine sebep olan bekleme tiplerinden başlayacağız. Bunun için aşağıdaki komut kullanılır.
SELECT
wait_type,
wait_time_ms/1000.0 AS WaitTimeSec,
signal_wait_time_ms/1000.0 AS SignalWaitTimeSec,
(wait_time_ms *100.0)/SUM(wait_time_ms) OVER() AS Yüzde
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0
ORDER BY Yüzde DESC;
- WaitTimeSec: Bu bekleme türünün toplam bekleme süresini saniye cinsinden gösterir. Yani SQL Server, ilgili kaynak için toplamda ne kadar beklemiş.
- SignalWaitTimeSec: Bir thread’in cpu da çalışmaya hazır olduğu ancak cpu meşgul olduğu için beklemek zorunda kaldığı süredir.
- Yüzde: Toplam bekleme süresine göre bu bekleme türünün yüzdesel oranını gösterir. En çok hangi bekleme türünün sistemi yavaşlattığını anlamak için kullanılır.
Şimdi yukarıdaki bekleme tiplerini detaylı bir aşağıda katagorilere ayrılmış şekilde detaylı bir şekilde açıklayalım.
Ayrıca Session bazlı hangi sorguların bekleme tipleri olduğunu görmek için aşağıdaki komut kullanılır.
SELECT session_id, wait_type, wait_time/1000 as bekleme_Saniye, wait_resource
FROM sys.dm_exec_requests
WHERE wait_type <> 'WAITFOR'
SQL Server’daki bekleme türleri (wait types), veritabanı motorunun çeşitli kaynaklar için yaptığı beklemeleri izler ve yönetir. Bu beklemeler, SQL Server’ın işlemleri nasıl gerçekleştirdiğini, hangi kaynakların talep edildiğini ve hangi işlemlerin zaman alarak beklediğini anlamanızı sağlar. Bekleme türlerinin doğru analiz edilmesi, SQL Server’daki performans sorunlarının tespit edilmesi ve çözülmesi için kritik öneme sahiptir.
SQL Server’da Bekleme Türlerini Neden İzleriz?
- Performans Analizi: Bekleme türleri, hangi kaynakların darboğaz oluşturduğunu belirlemek için kullanılır. Eğer belirli bir kaynakta sürekli bekleme oluyorsa, bu kaynak üzerinde iyileştirme yapılması gerekebilir.
- Veritabanı Optimizasyonu: Bir işlem ya da sorgu belirli bir kaynağı bekliyorsa, bu kaynağın optimizasyonu (örneğin, disk I/O’su ya da bellek yönetimi) sorgunun daha hızlı çalışmasını sağlayabilir.
- Veritabanı Yönetimi: Bekleme türleri, veritabanı yöneticilerinin (DBA) sistemdeki kaynak kullanımını izlemesine ve veritabanı altyapısını optimize etmesine yardımcı olur.
SQL Server Bekleme Türlerinin Temel Kategorileri
SQL Server’daki bekleme türlerini birkaç ana kategoride toplayabiliriz:
- CPU ile ilgili beklemeler
- Disk I/O ile ilgili beklemeler
- Memory (bellek) ile ilgili beklemeler
- Network (ağ) ile ilgili beklemeler
- Task Scheduler ve Resource ile ilgili beklemeler
CPU ile ilgili kategoriyi detaylı olarak inceleyelim:
1. CPU ile İlgili Beklemeler
Bu tür beklemeler, SQL Server’ın CPU kaynaklarını beklediği durumları tanımlar. SQL Server, sorguları çalıştırmak için CPU’yu kullanır ve eğer işlemci üzerinde başka görevler veya sorgular varsa, SQL Server işlemciyi beklemek zorunda kalabilir.
Örnek Bekleme Türleri:
- SOS_SCHEDULER_YIELD:
Bu bekleme türü, SQL Server’daki bir işlem tarafından CPU kaynağının tamamen kullanıldığı durumlarda, CPU’yu başka işlemlerin de kullanma fırsatı vermek için CPU serbest bırakmaya çalışmasıyla ortaya çıkar. Bir işlem işlemciyi yoğun bir şekilde kullanıyorsa ve başka işlemler de çalıştırılabiliyorsa, CPU diğer işlemler için “yield” (serbest bırakma) yapar. Yüksek CPU kullanımı veya CPU’yu fazla kullanan işlemler nedeniyle. Genellikle çok yoğun CPU tüketen sorgular için optimizasyon gerekebilir. Sorguların daha verimli yazılması, index kullanımı, sorgu planı iyileştirmeleri gerekebilir.
Processor’lar üzerinde çok fazla kullanım varsa bu durum CPU üzerinde çok fazla baskı hissetirir ve bu bekleme tipi görülürür.
- SQL Server’da kooperatif zamanlayıcı (cooperative scheduler) sistemi vardır.
- Bir işlem CPU’da çalışır ve belirli bir noktada ya:
- I/O bekliyordur (disk, network, vs.), ya da
- Daha fazla CPU süresine ihtiyacı vardır ama scheduler diyor ki: “Başka işler de var, biraz kenara çekil.”
İşlem, CPU’dan kendi isteğiyle (yield) çekilir ve tekrar sıra kendisine gelene kadar bekler. Çünkü bir tread 4 quantom süresi dolana kadar bekler. Tread kendi isteğiyle cpu yu bırakmaktadır. Sos_scheduler_yıeld treadlerin kendi isteğiyle cpu’yu bırakmasıdır.
Yüksek SOS_SCHEDULER_YIELD değeri, sistemdeki CPU darboğazı veya yoğun CPU kullanan işlemler olduğunun işaretidir.
İşlem, CPU’da yeterince uzun süre çalışamamış ve sık sık “kenara çekilmek” zorunda kalmış demektir. İşlem CPU’da kalmak istiyor ama scheduler buna izin vermiyor.
CPU tüketen sorguları bulmak için:
SELECT TOP 10
total_worker_time / execution_count AS AvgCPU,
execution_count,
total_worker_time,
statement_text = SUBSTRING(st.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY AvgCPU DESC;Bu gibi durumlarda ne yapılması gerekmektedir. Sorguların execution plan‘larını analiz edin. Missing index önerilerine göz atın. CPU sayısını veya performansını artırılmalı, MAXDOP ayarı gözden geçirilebilir. Resource Governor ile CPU limiti sınırlamaları var mı, bakılmalı Yoğun sorguları yeniden yazılmalı veya optimize edilmelidir. Gereksiz paralel işlemlerden kaçınılması gerekmektedir. Plan cache’de çok fazla tekrar eden kötü planlar varsa, yeniden derlenmesi gerekir. (DBCC FREEPROCCACHE gibi)
- THREADPOOL
Bu bekleme türü, SQL Server’ın CPU iş parçacıklarını (threads) yönetirken karşılaştığı sorunları ifade eder. SQL Server, belirli sayıda iş parçacığına sahiptir ve çok sayıda sorgu çalıştırıldığında iş parçacıkları tükenebilir. Bu durumda, bir işlem iş parçacığı almayı bekler. SQL Server, belirli bir işlem için yeterli CPU iş parçacığına sahip olmadığında, işlemci iş parçacığı kullanılabilir hale gelene kadar işlem bekler. Bu tür beklemeler genellikle çok fazla iş parçacığının aynı anda çalıştığı durumlarda görülür. İşlemci havuzu büyütülerek, sorgu yoğunluğunu yönetmek için CPU kapasitesinin arttırılması gerekebilir. Bu bekleme tipi worker ile ilgili blocklama yada contention olduğunda görülür. Çözüm için sys.dm_os_waiting_tasks dmv’sine ve sp_configure üzerinden max worker thread değerine bakılmalı.
Not: max worker threads, SQL Server’ın aynı anda kaç adet worker thread (iş parçacığı) oluşturabileceğini belirler.
Aşağıdaki komutla öğrenilebilir. Yada sp_configure üzerinden tread sayısı bulunabilir.
SELECT
max_workers_count AS [Max Worker Thread],
cpu_count AS [CPU Sayısı]
FROM sys.dm_os_sys_info;Max worker tread sayısını ve önerilen worker tread sayısını aşağıdaki komut ile görebiliriz.
SELECT
cpu_count,
hyperthread_ratio,
scheduler_count,
max_workers_count,
-- Otomatik hesaplama formülü:
CASE
WHEN cpu_count <= 4 THEN 512
ELSE 512 + ((cpu_count - 4) * 16)
END AS [Önerilen Max Worker Thread]
FROM sys.dm_os_sys_info;
Tread sayısının fazla olması performans anlamında sıkıntıya sebebiyet verir. Çünkü her tread 2 ile 4 mb arasında bellek tüketir. Buda memory overhead(bellek yükü) oluşturmaktadır. Cpu treadlar arasında geçiş yaparken zaman kaybeder. Buda context switching oluşmasına sebebiyet verir.
Aktif tread kullanımı aşağıdaki komut ile bulunanabilir.
-- İdeal kullanım kontrolü
SELECT
(SELECT COUNT(*) FROM sys.dm_os_workers WHERE state = 'RUNNING') AS [Aktif Thread],
(SELECT max_workers_count FROM sys.dm_os_sys_info) AS [Max Thread],
(SELECT COUNT(*) FROM sys.dm_os_workers WHERE state = 'RUNNING') * 100.0 /
(SELECT max_workers_count FROM sys.dm_os_sys_info) AS [Kullanım Yüzdesi];Bu thread’ler neler yapar?
- Sorgular (SELECT, INSERT, UPDATE, DELETE),
- Backup işlemleri,
- Replication,
- Index oluşturma,
- Paralel sorgular (Parallel Query Execution),
Yukarıdaki tüm işlemler worker thread’ler aracılığıyla yapılır.
Yani, SQL Server genellikle kendi donanımına göre bu ayarı otomatik olarak en uygun şekilde belirler. Aşağıdaki tread sayısıda yukarıdaki önelirilen tread sayısına yakındır.
| Donanım | Varsayılan Değer |
|---|---|
| < 16 işlemci | 512 |
| ≥ 16 işlemci | max worker threads = 512 + ((N – 16) * 16) |
| (N = CPU sayısı) |
Normalde max worked tread sayısı 65535’dir. Bu sp_configure üzerindeki default ayardır. Yukarıdaki formülle ilgili değere set etmemiz ulaşabileceğimiz en iyi performans tır. Her tread 2-4 MB’dır.
Her aktif kullanıcı oturumu için SQL Server arka planda bir worker thread tahsis eder.
Eğer çok fazla kullanıcı varsa ya da çok fazla paralel işlem çalışıyorsa ve bu sayı max worker threads sınırına ulaşırsa:
- SQL Server yeni bağlantılar için thread bulamayabilir.
- Kullanıcılar beklemeye alınır.
- Bu durumda wait_type = THREADPOOL olur. (Buna dikkat!)
Diyelim ki büyük bir raporlama sisteminiz var, ve aynı anda 2000 kullanıcı bağlanıp sorgu çalıştırıyor.
- Eğer max worker threads = 1024 ise ve her kullanıcı bir thread kullanıyorsa (veya paralel sorgularla daha fazlasını), sistem bir süre sonra thread havuzunu tüketir.
Sonuç: Bazı kullanıcılar thread beklemeye başlar, ve bu da sistemde THREADPOOL wait olarak görünür.
-- Gelişmiş ayarları aktif hale getir
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- max worker threads ayarını değiştir
EXEC sp_configure 'max worker threads', 2048;
RECONFIGURE;
Bu ayarı gereksiz yere yükseltmek önerilmez! Çünkü:
- Fazla thread → fazla context switching → CPU yükü artar → performans düşer.
- Önce THREADPOOL beklemeleri analiz edilmeden değişiklik yapılmamalıdır.
Şu sorgu ile sistemde THREADPOOL beklemeleri var mı, görebilirsin:
SELECT wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'THREADPOOL';Ayrıca aktif thread sayısını görmek için:
SELECT COUNT(*) AS [Active_Worker_Threads]
FROM sys.dm_os_workers
WHERE state = 'RUNNING';- SQLTRACEBUFFER:
SQLTRACEBUFFER, SQL Server’da bir trace oturumunun (örneğin: SQL Profiler, Extended Events ya da Default Trace), olayları kaydetmeye çalışırken buffer (önbellek) yazmak için hazırda beklemesi durumunu temsil eder.
Yani:
SQL Server bir olayı trace etmeye çalışıyor → Olayı buffer’a yazmak istiyor → Ama buffer doluysa veya kullanılamıyorsa → SQLTRACEBUFFER beklemesi oluşur.
Bu bekleme, doğrudan performansla ilgili olmayabilir.
Ama çok sayıda ve yoğun çalışan trace oturumları, özellikle canlı sistemlerde, uygulamayı yavaşlatabilir.
SQL Profiler gibi araçlarla canlı sistem üzerinde izleme yapmak, bu tür buffer sıkışmalarına yol açabilir.
SQLTRACEBUFFER ile Karşılaşırsan Ne Yapmalısın?
| Yapılacak | Açıklama |
|---|---|
| Trace oturumlarını kontrol et | sys.traces DMV’siyle çalışan trace’leri görebilirsin |
| SQL Profiler canlı sistemde çalıştırma | Bunun yerine Extended Events kullanman daha iyi olur |
| Trace’leri dosyaya yazıyorsan | Yazma hızını (I/O) kontrol et, gerekirse daha hızlı disk kullan |
| Gereksiz trace’leri durdur | Özellikle default trace dışında açık olanları kapatmayı düşün |
Aktif trace oturumlarını görmek için:
SELECT * FROM sys.traces;Varsayılan trace dışında (traceid = 1) bir şey görüyorsan, sistemde bir uygulama veya DBA özel bir trace başlatmış olabilir.
Sonuç olarak:
- SQLTRACEBUFFER, SQL Server’ın trace olaylarını buffer’a yazmak isterken beklemede kaldığını gösterir.
- Genellikle yoğun izleme (profiler, trace) işlemlerinden kaynaklanır.
- Performansa dolaylı olarak zarar verebilir, özellikle canlı sistemde yoğun izleme yapılırsa.
- Extended Events, trace’e göre daha performans dostudur.
- CXPACKET
CXPACKET, paralel sorguların yürütülmesi sırasında görülen bir bekleme türüdür. SQL Server, sorguları paralel işleme modunda çalıştırırken, her bir iş parçacığının tamamlanmasını bekler. Eğer bu paralel iş parçacıkları eşit şekilde tamamlanmazsa, bazı iş parçacıkları diğerlerini beklemek zorunda kalır. Paralel sorgularda, iş parçacıklarının tamamlanması için gereken süre farkı büyük olduğunda. Paralel yürütme ile ilgili beklemeler ise genellikle sorgunun paralel olarak çalıştığı koşullarda gerçekleşir. Max Degree of Parallelism (MAXDOP) ayarını optimize etmek, bu tür beklemeleri azaltabilir.
Kısaca:
“Paralel çalışan thread’lerden biri işi bitirmiş, diğerini bekliyor.”
OLTP sistemlerde, paralellism sorunu vardır ve bunun çözümü cost of threeshold paralellisim ve maxdop ayarlarını check edebilirsin. Bu bekleme türü ile birlikte PAGEIOLATCH_xx bekleme türünüde görüyorsan, büyük bir tablo paralel thread’ler ile birlikte taranıyordur. Bu duruma da sebep olmasının sebebi doğru atılmamış olan bir index veya istatistikleri toplanmadığından kötü bir query plan üretimidir.
Aktif olarak şu anda CXPACKET beklemesi var mı görmek için:
SELECT
session_id, wait_type, wait_time, blocking_session_id, resource_description
FROM sys.dm_exec_requests
WHERE wait_type = 'CXPACKET';
Son olarak CXPACKET neden oluşur ona değinelim:
| Sebep | Açıklama |
|---|---|
| Paralel çalışan thread’ler dengesiz yük almış | Bazı thread’ler az, bazıları çok iş yapıyor |
| Aşırı paralellik | CPU sayısı kadar thread açılıyor ama gerek yok |
| Yanlış/eksik indeksler | SQL Server daha fazla thread kullanıyor çünkü plan optimal değil |
| Büyük veri taramaları (table scan) | Paralellik kaçınılmaz oluyor |
| Uyumsuz MAXDOP ve COST_THRESHOLD_FOR_PARALLELISM ayarları | Gereksiz yere paralel sorgular oluşuyor |
- ASYNC_IO_COMPLETION
Bu bekleme türü, SQL Server’ın asenkron I/O işlemleri sırasında meydana gelir. SQL Server, veri okuma ve yazma işlemleri için asenkron I/O kullanır ve bu bekleme türü, verilerin okuma/yazma işlemleri sırasında işlemciyi bekletir. SQL Server, asenkron okuma ve yazma işlemleri sırasında CPU’nun meşgul etmesine neden olan beklemelere neden olur. Genellikle disk I/O veya bellekle ilgili darboğazlardan kaynaklanır. Daha hızlı diskler veya daha fazla bellek kullanımı, bu tür beklemeleri azaltabilir. Bu bekleme tipi daha çok IFI açılmadığında, backup beklemelerinde ve linked server beklemelerinde görülür.
Not: SQL Server’da IFI (Instant File Initialization) açılmadığında, özellikle veri dosyaları (MDF, NDF) ve transaction log dosyaları (LDF) oluşturulurken veya büyütülürken, disk alanı işletim sistemi tarafından sıfırlarla doldurulur. Bu, dosya tahsis işlemini yavaşlatır ve özellikle büyük dosyalarda performans kaybına neden olabilir.
IFI Açılmadığında Ne Olur?
- Yeni veritabanı oluşturma işlemleri yavaşlar.
- Veritabanı dosyaları büyütüldüğünde performans düşer. (Otomatik büyüme veya manuel genişletme sırasında.)
- Backup restore işlemleri daha uzun sürer.
IFI Açmak için Ne Yapılmalı: IFI’yi etkinleştirmek için SQL Server çalıştıran Windows kullanıcısına “Perform Volume Maintenance Tasks” izni verilmelidir:
Aşağıdaki durumlarda ASYNC_IO_COMPLETION karşımıza çıkabilir:
| Durum | Açıklama |
|---|---|
| Veri dosyasına yazma | INSERT/UPDATE işlemlerinde |
| Transaction log’a yazma | Özellikle tempdb veya log yoğun işlemlerde |
| Backup/restore işlemleri | Disk yavaşsa veya ağ üzerindeyse |
| Large Object (LOB) veri okuma/yazma | NVARCHAR(MAX), VARBINARY(MAX), IMAGE gibi |
| CHECKPOINT veya LAZY WRITER sırasında | Memory’deki sayfalar diske yazılırken |
Nasıl Azaltılır?
| Çözüm | Açıklama |
|---|---|
| Disk performansını ölç | sys.dm_io_virtual_file_stats DMV’siyle dosya I/O sürelerini görebilirsin |
| Daha hızlı disk altyapısı kullan | SSD, NVMe, RAID 10 gibi |
| Backup’ları daha hızlı hedeflere al | Ağ yavaşsa yerel diske alınabilir |
| TempDB’yi optimize et | Çok yazma varsa ayrı diske al, dosya sayısını artır |
| Büyük LOB işlemlerini gözden geçir | LOB veri işlemleri genelde bu beklemeyi artırır |
Aktif bekleme sayısını aşağıdaki komut ile görebiliriz.
SELECT session_id, wait_type, wait_time, blocking_session_id
FROM sys.dm_exec_requests
WHERE wait_type = 'ASYNC_IO_COMPLETION';- PREEMPTIVE_OS_CALLS
Bu bekleme türü, SQL Server’ın Windows işletim sistemi ile etkileşime geçerken, işlemciye erişim sağlayamadığı ve başka bir işlem için CPU kaynağını serbest bırakması gerektiğinde meydana gelir. Bu, SQL Server’ın işletim sistemi ile yaptıkları çağrıları beklerken oluşur. SQL Server işletim sistemine erişim yapmak zorunda olduğunda ve bu erişim sırasında başka işlemler CPU’yu yoğun şekilde kullanıyorsa.
PREEMPTIVE_OS_CALLS, SQL Server’ın bir Windows API (işletim sistemi çağrısı) veya dış bileşen (örneğin Active Directory, dosya sistemi, ağ paylaşımı vs.) ile iletişim kurduğu sırada, kontrolü Windows’a bıraktığı (preemptive mode’a geçtiği) ve sonucu beklediği süredir.
Neden “PREEMPTIVE”
SQL Server normalde cooperative scheduling kullanır: thread’ler adilce sırayla çalışır.
Ama bazı işlemler, işletim sistemi API’lerine bağlandığında, SQL Server bu işlemleri “kontrol dışı” (preemptive) bırakır. Çünkü bu çağrılar:
- SQL Server dışı bir işlem başlatır
- Süresini kontrol edemez
- Bu yüzden “Ben bu işi Windows’a devrediyorum, sonra tekrar bakarım” der
Bu da PREEMPTIVE_XXX türü wait’lere yol açar.
Hangi Durumlarda Görülür?
| Durum | Açıklama |
|---|---|
| Linked Server çağrıları | Özellikle uzak sunucudan veri çekerken |
| File system işlemleri | Dosya okuma/yazma (örneğin xp_cmdshell, BULK INSERT, OPENROWSET) |
| Active Directory istekleri | Kullanıcı kimlik doğrulaması, grup sorguları |
| CLR (Common Language Runtime) işlemleri | .NET ile yazılmış SQL Server uzantıları |
| Ağ üzerinden yavaş işlem | Örneğin DFS paylaşımları veya SMB protokolleriyle dosya okuma |
- CLR_AUTO_EVENT
SQL Server, Common Language Runtime (CLR) ile etkileşimde bulunurken bazı işlemleri bekletebilir. Bu bekleme türü, CLR kodlarının çalıştırılmasında meydana gelen beklemeleri ifade eder. SQL Server’ın CLR işlemleri çalıştırdığı ve işlemci kaynağını kullanarak beklemeye alındığı durumlarda görülür. CLR kullanılan sorgularda, işlemciyi verimli kullanabilmek için CLR kodlarının optimize edilmesi gerekebilir.
- CX Consumer
CX (Concurrency Exchange) bekleme türü, SQL Server’ın paralel sorgu yürütme sırasında iş parçacıkları arasında koordinasyon sağlamak için kullandığı bir mekanizmadır. CX Consumer, paralel iş parçacıklarından biri işini tamamladıktan sonra diğer iş parçacıklarını beklerken ortaya çıkar. Genellikle “CX Packet” bekleme türü ile birlikte görülür. Yüksek CX Consumer beklemeleri, sorguların aşırı paralelleştirilmesi veya dengesiz iş yükü dağılımı nedeniyle oluşabilir. MAXDOP (Maximum Degree of Parallelism) ayarının optimize edilmesi veya Query Cost Threshold for Parallelism değerinin gözden geçirilmesi sorunu azaltabilir.
- CXCONSUMER genellikle normal ve beklenen bir durumdur.
- SQL Server paralel planları işlerken bazı thread’lerin veri tüketmesi zaman alabilir, bu da bu beklemeye neden olur.
- Yani: “Her CXCONSUMER = performans problemi” değildir.
Ancak çok fazla CXCONSUMER varsa ve CPU kullanımı yüksekse, şu soruları sormakta fayda var:
- Gerçekten paralel planlara ihtiyaç var mı?
- MAXDOP ve cost_threshold_for_parallelism değerleri uygun mu?
- Sorguların planları doğru mu?
Çözüm Önerileri
- Sorgu Optimizasyonu: Verimsiz sorguları optimize etmek, paralel sorgularda MAXDOP ayarını düzenlemek, CPU yükünü azaltabilir.
- Donanım İyileştirmeleri: Eğer CPU kaynakları sıkça tükeniyorsa, daha güçlü işlemciler veya daha fazla işlemci çekirdeği eklemek faydalı olabilir.
- Paralel Sorgu Yönetimi: SQL Server’daki paralel sorgu işlemlerinin yönetilmesi, iş yükünü dengelemeye yardımcı olabilir. MAXDOP ayarı ile paralel iş parçacığı sayısını sınırlandırmak da bir çözüm olabilir.
Makalenin başında belirtilen diğer bekleme tiplerine değinelim.
1. VDI_CLIENT_OTHER
Sanal Cihaz Arayüzü (VDI) istemcisi ile ilgili diğer bekleme türlerini ifade eder. Bu bekleme türü, backup veya restore işlemleri sırasında ortaya çıkabilir. Yüksek bekleme süresi, VDI istemcisi veya yedekleme altyapısı ile ilgili sorunlara işaret edebilir.
2. BROKER_TASK_STOP
Service Broker görevlerinin durdurulması sırasında oluşan bekleme süresidir. Service Broker ile ilgili işlemlerde bir gecikme yaşanıyorsa, bu bekleme türü artabilir.
SQL Server Service Broker, veritabanı içinde veya sunucular arasında asenkron mesajlaşma ve işlem yönetimi sağlayan bir mesaj kuyruğu sistemidir. Yani işlemler birbirini beklemeden arka planda yürütülebilir. Uzun süren işlemleri (örn. e-posta gönderme, rapor oluşturma) arka planda çalıştırarak sistem performansını artırır. Farklı SQL Server örnekleri arasında güvenli ve güvenilir iletişim sağlar. Service Broker kuyruğa alınan mesajları sürekli dinlediği için CPU ve bellek tüketebilir. Yapılandırılması ve yönetimi geleneksel SQL işlemlerine göre daha zordur. HADR_WORK_QUEUE ve HADR_NOTIFICATION_DEQUEUE bekleme türleri birlikte görülmektedir.
Eğer Service Broker bekleme süreleri yüksekse, bu şu anlama gelebilir:
- Mesaj kuyruğunda bir tıkanma (block) olabilir.
- Mesajlar düzgün işlenmiyor olabilir.
- Service Broker etkin fakat kullanılmıyor olabilir, gereksiz CPU tüketiyor olabilir.
Çözüm için:
- sys.transmission_queue tablosunu kontrol edip kuyruğa takılan mesaj var mı bakılabilir.
- Service Broker ile ilgili oturumlar (sys.dm_broker_connections) izlenebilir.
- Gereksiz Service Broker bileşenleri devre dışı bırakılabilir.
3. HADR_WORK_QUEUE
SQL Server’daki bir worker thread, Availability Group replikasyon işi yapmak üzere iş kuyruğunda (work queue) bekliyor demektir.
Yani, replikasyon işlemi (log gönderme, senkronizasyon vs.) yapılacak ama thread henüz işleme geçmedi.
Bu durumda işlem work queue’da bekliyor.
Genelde ne zaman olur?
- Replika sistemi meşgulse
- Aşırı yüklenmişse (çok transaction var)
- Sistem yüksek availability yükü altındaysa
Normal mi?
Düşük seviyelerde ve kısa süreli ise → normal.
Ama sürekli artan HADR_WORK_QUEUE beklemesi, secondary replika işleyemiyor anlamına gelir → performans düşebilir.
4.PREEMPTIVE_OS_WRITEFILEGATHER
PREEMPTIVE_OS_WRITEFILEGATHER bekleme tipi, SQL Server’ın işletim sistemine (Windows API’lerine) kontrolü geçici olarak bıraktığı (preemptive) ve bu esnada bir dosya yazma işlemini (özellikle backup gibi büyük veri yazımları) beklediğini ifade eder.
Detaylı Açıklama:
• PREEMPTIVE_* beklemeleri:
SQL Server, normalde thread’leri kendi scheduler’ı (SQLOS) ile yönetir. Ancak bazı işlemler, Windows API’si ile doğrudan etkileşim gerektirir. Bu durumda SQL Server, kontrolü işletim sistemine verir ve kendi planlayıcısından çıkar. Bu tür beklemelere “preemptive wait” denir.
• WRITEFILEGATHER kısmı:
Bu, SQL Server’ın diske toplu veri (genellikle backup, file stream, ya da data file write) yazarken kullandığı bir işlem türüdür.
Özellikle yedekleme (backup) sırasında bu bekleme sık görülür.
Not: System Center ürünlerinin bulunacağı ortamlarda sql server kurulumu için Collation SQL_Latin1_General_CP1_CI_AS yapısının seçilmesi gerekmetedir.
Bu makalede MSSQL Server CPU Bekleme Tiplerini detaylı bir şekilde görmüş olduk. Başka bir makalede görüşmek dileğiyle..
“De ki: Ey Rabbim! İlmimi artır.” Taha-114
