Bu makalede mssql server üzerinde Disk I/O 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 AS WaitTimeSec,
signal_wait_time_ms / 1000 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: İşlemcinin (CPU) kullanıma hazır olmasını beklerken geçen süredir. Yüksek değerler, CPU darboğazı olabileceğini gösterir.
- 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
Disk I/O ile ilgili kategoriyi detaylı olarak inceleyelim:
2. Disk I/O ile İlgili Beklemeler
Disk I/O ile ilgili beklemeler, SQL Server’ın veritabanı dosyalarına ve transaction log dosyalarına okuma veya yazma işlemleri sırasında meydana gelir. Eğer disk okuma veya yazma işlemleri uzun sürüyorsa, işlemler beklemeye alınır.
Örnek Bekleme Türleri:
SQL Server, veritabanı sayfalarını okurken veya yazarken, bu işlemler diske yapılır ve disk kaynakları sınırlı olduğunda beklemeler oluşabilir.
Disk I/O beklemeleri, SQL Server’ın disk işlemlerini ne kadar hızlı gerçekleştirdiğini ve veritabanının I/O kaynaklarını verimli kullanıp kullanmadığını anlamanızı sağlar. Eğer disk işlemleri çok uzun sürüyorsa, bu durum SQL Server’ın performansını ciddi şekilde etkileyebilir.
· PAGEIOLATCH_SH (Shared Page I/O Latch)
PAGEIOLATCH_SH, SQL Server’ın veritabanı sayfalarını okuma işlemi sırasında meydana gelir. SQL Server veritabanındaki verileri belleğe almak için sayfaları diskte arar ve bu bekleme türü, bir sayfa belleğe aktarılana kadar SQL Server’ın beklediği durumları ifade eder. Bu bekleme türü, özellikle okuma işlemlerinde yaygın olarak görülür. Veri okuma işlemi sırasında veritabanı sayfası belleğe yüklenmeden önce görülür. Bu tür beklemeler genellikle diskin yavaş olduğu durumlarda, veritabanı sayfasının bellekten okuma işlemi sırasında görülür. Daha hızlı diskler veya SSD kullanımı, bu beklemeleri azaltabilir. Ayrıca, index optimizasyonu yaparak, disk okuma ihtiyacı azaltılabilir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'PAGEIOLATCH_SH';Yani:
SQL Server bir veriyi RAM’de bulamadı → Diske gitti → Disk yavaş yanıt verdi → SQL Server bekledi →
Bu bekleme süresi = PAGEIOLATCH_SH
SH = Shared: Okuma amaçlı erişim. (UPDATE yapsa PAGEIOLATCH_EX olurdu.)
En çok I/O yapan tablolar
SELECT TOP 10
OBJECT_NAME(s.object_id) AS TableName,
i.name AS IndexName,
user_seeks, user_scans, user_lookups, user_updates
FROM sys.dm_db_index_usage_stats AS s
JOIN sys.indexes AS i ON i.object_id = s.object_id AND i.index_id = s.index_id
WHERE database_id = DB_ID()
ORDER BY user_scans DESC;
· PAGEIOLATCH_EX (Exclusive Page I/O Latch)
PAGEIOLATCH_EX beklemesi, veritabanı sayfalarına yazma işlemi sırasında meydana gelir. SQL Server, veritabanındaki sayfalara yazma işlemi gerçekleştireceği zaman, sayfa exclusive (özel) kilit alır ve bu bekleme türü, bir sayfaya yazma işlemi yapılana kadar bekleme durumunu ifade eder. Ne Zaman Görülür bir sayfa yazmaya çalışılırken ve disk I/O işlemi tamamlanana kadar. Yavaş diskler veya I/O darboğazları bu tür beklemelere yol açabilir. Yazma işlemleri sırasında bu beklemeyi azaltmak için veritabanı indexleri iyileştirilebilir. Ayrıca, yazma işlemleri için disklerin hızını artırmak ve SSD kullanımı bu tür beklemeleri minimize edebilir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'PAGEIOLATCH_EX';Yani:
SQL Server veriye yazmak istiyor (örneğin UPDATE, INSERT, DELETE)
Ama veri RAM’de yok → Diske gitmesi gerek → Disk yavaş → SQL Server bekliyor
Ve bekleme türü: PAGEIOLATCH_EX. Kısacası veriyi güncellemek için Ram’de bulamazsa diskten Ram’e almak için beklemektedir.
Ne Zaman Ortaya Çıkar?
| Durum | Açıklama |
|---|---|
| INSERT / UPDATE / DELETE | Sayfaya yazmak için önce diskteki veriyi belleğe getirmesi gerekir |
| Veri RAM’de değilse | Diskten okuma başlar, yavaşsa PAGEIOLATCH_EX oluşur |
| Disk alt yapısı yavaş | HDD, ağ diski, düşük IOPS varsa |
| Yetersiz bellek | Sık sık veri sayfaları buffer pool’dan atılıyor, tekrar diske gidiliyor. |
| TempDB yoğun kullanılıyorsa | Yoğun geçici işlem varsa, bu bekleme tempdb diskine bağlı hale gelir |
En çok disk I/O yapan veri dosyaları
SELECT
DB_NAME(vfs.database_id) AS DbName,
mf.physical_name,
vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS AvgWriteMs
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id
ORDER BY AvgWriteMs DESC;
· WRITELOG
WRITELOG bekleme türü, SQL Server’ın transaction log dosyasına yazma işlemi sırasında meydana gelir. Bu bekleme türü, veritabanındaki transaction log’a yeni bilgiler yazılırken ortaya çıkar. Özellikle büyük işlem gruplarının olduğu durumlarda, bu bekleme türü daha sık görülür. Ne Zaman Görülür: Transaction log’a veri yazılırken disk I/O işlemi tamamlanana kadar. Eğer transaction log dosyasına yazma işlemleri çok sık gerçekleşiyorsa ve disk I/O işlemleri çok uzun sürüyorsa, disk performansı artırılabilir. Log büyüklüğünü optimize etmek ve log dosyalarını düzenli olarak yedeklemek, disk I/O üzerindeki baskıyı hafifletebilir. Log’ların disk’e yazıldığı anda gerçekleşir. Log file’ların hızlı büyümesi işlemi sırasında PREEMPTIVE_OS_WRITEFILEGATHER bekleme tipi ile birlikte görülebilir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'WRITELOG';Yani SQL Server diyor ki:
“İşlemi tamamladım, log dosyasına yazmam gerekiyor… ama disk yavaş → bekliyorum.”
Bekleme süresi = WRITELOG, Yada işletim sisteminden yeni alan tahsis etmek için PREEMPTIVE_OS_WRITEFILEGATHER bekleme türleri görünür.
Nerede Ortaya Çıkar?
WRITELOG şu işlemlerde sıkça görülür:
| İşlem Türü | Açıklama |
|---|---|
| INSERT, UPDATE, DELETE | Her işlem log dosyasına yazılır |
| SELECT INTO, MERGE, BULK INSERT | Büyük veri yazmaları log’u zorlar |
| Transaction’lar (BEGIN TRAN … COMMIT) | Transaction log’a yazma zorunlu |
| Checkpoint, Auto-checkpoint | Log dosyası büyüdükçe işlem sayısı artar |
| TempDB yazma işlemleri | Yine log kullanılır |
| ALTER, DDL komutları | DDL bile log’lanır |
Neden Oluşur?
| Neden | Detay |
|---|---|
| Yavaş disk (özellikle log dosyası diski) | Log dosyası genelde sequential write yapar → disk hızı çok önemli |
| RAM azsa | Veriler sık checkpoint olur, log’a yazım artar |
| Çok fazla transaction aynı anda | Log yazma kuyruğu olur |
| Uzun süren transaction’lar | Log’un reuse edilmesini engeller |
| Auto-growth sık olursa | Log dosyası büyürken işlem bekler |
| Anti-virus veya backup uygulamaları | Log dosyasına erişimi geciktirir |
Log Diski Nasıl Olmalı?
| Özellik | Neden Önemli |
|---|---|
| SSD kullanımı | Sequential write işlemleri için idealdir |
| Ayrı fiziksel disk | Veri dosyasından ayrı olursa I/O çakışması azalır |
| Düşük latency | Log yazma gecikmesi = sorgu gecikmesi |
| Yeterli alan ve büyüme ayarı | Auto-growth sık olmamalı (örneğin % yerine MB cinsinden sabit değer) |
Nasıl Azaltılır?
| Aksiyon | Açıklama |
|---|---|
| Log dosyasını hızlı diske taşı | SSD, NVMe, ayrı RAID grubu |
| Auto-growth ayarını düzelt | Sabit ve yeterli büyüklükte (örneğin 512 MB artış) |
| Transactionları kısa tut | BEGIN TRAN uzun sürerse log kilitlenebilir |
| Checkpoint tuning | recovery interval ayarı kontrol edilebilir |
| Backup’ları düzenli yap | Log backup yapılmazsa log şişer, WRITELOG artar |
| Minimal log işlemleri | BULK_LOGGED recovery modeli gibi |
Aşağıdaki komut ile hangi dosyada IO sorunu olduğunu görebiliriz.
SELECT
DB_NAME(mf.database_id) AS DbName,
mf.physical_name,
vfs.num_of_writes,
vfs.io_stall_write_ms,
vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS AvgWriteMs
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf
ON mf.database_id = vfs.database_id AND mf.file_id = vfs.file_id
ORDER BY AvgWriteMs DESC;En yüksek AvgWriteMs olan dosya = potansiyel WRITELOG sorunu yaşanan log dosyası.
Not: WRITELOG + ASYNC_NETWORK_IO + PAGEIOLATCH
Bu üç bekleme bir arada görünüyorsa:
- WRITELOG: Log’a yazarken bekliyor
- ASYNC_NETWORK_IO: Sonuçları client yavaş çekiyor
- PAGEIOLATCH: Disk’ten veri okuyor
Bu sistem genel anlamda IO-bound (disk bağımlı) durumda olabilir.
· IO_COMPLETION
IO_COMPLETION beklemesi, SQL Server’ın bir I/O (Girdi/Çıktı) işleminin tamamlanmasını beklediği durumdur. Yani SQL Server bir dosyaya veri yazma ya da okuma işlemi başlatmış, ama bu işlem henüz tamamlanmamış → SQL Server bu sürede beklemededir. Kısacası: SQL Server “diskle konuşuyorum, bir işlemi bitirmesini bekliyorum” derken bu bekleme oluşur. Disklerin yanıt süreleri uzun veya diskler çok yoğun olduğunda bu bekleme türü ortaya çıkabilir. I/O tamamlanmasını hızlandırmak için, disk performansını artırmak, SSD kullanmak ve disk alanını optimize etmek faydalı olabilir. Ayrıca, veritabanı boyutunu izlemek ve gereksiz veri dosyalarını temizlemek de bu tür beklemeleri azaltabilir. Genellikle tempdb spill olduğunda bu bekleme tipine rastlanılır. Tempdb spill, bazı sorgularda join gibi işlemlerde sql server birleştirmek için ek memory ihityaç duyar ve server kaynakları buna cevap veremezse, sql server bu açığı tempdb ile kapatır ve bu durumda tempdb spill oluşmasına neden olur.
Bir sorgu çalışırken veri üzerinde işlemler yapmak için belleğe ihtiyaç duyar. Eğer SQL Server bu sorguya yeterli bellek (memory grant) veremezse, o zaman bu ara işlemler bellekte değil, tempdb üzerine yazılır.
Bu olaya “spill to tempdb”, yani “verinin geçici olarak tempdb’ye taşması” denir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type LIKE 'IO_COMPLETION'
Ne tür I/O’larda olur?
- Veri sayfası okumaları (read)
- Transaction log yazmaları (write)
- TempDB yazmaları
- Checkpoint işlemleri
- Backup veya restore işlemleri
Ne zaman sorun olur?
IO_COMPLETION tek başına ara sıra görünüyorsa → NORMAL.
Ama çok sık ve yüksek sürelerde oluyorsa, şunlar olabilir:
| Olası Neden | Açıklama |
|---|---|
| Disk yavaş | Disk altyapısı (özellikle SAN/NAS) yavaş yanıt veriyor olabilir |
| I/O yoğun sorgular | Çok sayıda büyük okuma/yazma yapan sorgular var |
| TempDB ya da log dosyası diskte darboğazda | Disk sıralaması, yavaşlık, fragmentation |
| Donanım sorunu | Disk, RAID kontrolcüsü ya da storage layer’da sorun olabilir |
| Anti-virus taraması | SQL veri/log dosyalarını tarıyor olabilir |
Ne Yapılabilir?
| Sorun | Çözüm |
|---|---|
| Disk altyapısı yavaş | Disk IOPS artırılmalı, SSD tercih edilmeli |
| Yoğun sorgular var | Query tuning ile I/O azaltılmalı (daha az okuma, daha az yazma) |
| TempDB veya Log dosyası yavaş disklerde | Ayrı, hızlı diskler kullan |
| Antivirus taramaları | .mdf, .ldf, .ndf dosyaları taramadan muaf tutulmalı |
| Backup işlemleri disk darboğazına neden oluyor | Yedeklemeler başka diske alınmalı veya throttle edilmeli |
· ASYNC_IO_COMPLETION
ASYNC_IO_COMPLETION bekleme türü, SQL Server’ın asenkron I/O işlemleri sırasında meydana gelir. SQL Server veritabanı sayfalarını okumak ve yazmak için asenkron I/O kullanır. Bu bekleme türü, veri okuma veya yazma işlemi sırasında I/O işleminin tamamlanmasını bekleyen bir işlem olduğunda oluşur. SQL Server, asenkron okuma veya yazma işlemi yaparken ve bu işlemler tamamlanana kadar bekler. Bu tür beklemeler, disk I/O performansındaki gecikmeler nedeniyle ortaya çıkabilir. 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.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'ASYNC_IO_COMPLETION';· FILESTREAM
FILESTREAM beklemesi, SQL Server’ın FILESTREAM özelliğini kullandığı durumlarda meydana gelir. FILESTREAM, SQL Server’ın büyük dosya verilerini saklamak için disk üzerinde dosya sistemini kullandığı bir özelliktir. Bu bekleme türü, dosya sistemi ve veritabanı arasındaki I/O işlemleri sırasında görülebilir. SQL Server, büyük dosyaları okurken veya yazarken, disk üzerinde dosya işlemi yapmak için bekler. Disk I/O performansı, özellikle büyük dosyaların işlendiği senaryolarda çok önemlidir. Yavaş diskler veya disklerdeki darboğazlar, FILESTREAM işlemleri sırasında bu beklemelere yol açabilir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'FILESTREAM';· LOGBUFFER
LOGBUFFER, SQL Server’ın transaction log yazma işlemleri sırasında log verilerini tampon bellek (buffer) üzerinde işlemesi sırasında meydana gelir. Bu bekleme, log verilerinin disk üzerine yazılmadan önce bellekteki tamponlarda işlenmesi sırasında oluşur. Ne Zaman Görülür: LOGBUFFER, SQL Server’ın transaction log bilgilerini bellek (log buffer) üzerinde hazırlayıp fiziksel log dosyasına yazmaya hazır hale getirme sürecinde yaşadığı beklemeyi gösterir. SQL Server, log’a yazmadan önce verileri bir buffer’a (arabellek) koyar. Eğer bu buffer’a yazmak için bir sebepten dolayı bekleniyorsa, LOGBUFFER oluşur.Log tampon büyüklüğü ve disk yazma hızları bu tür beklemeler üzerinde etki yapar. İyi yapılandırılmış log diskleri ve yüksek hızda yazma gerçekleştiren diskler bu tür beklemeleri azaltabilir. Log kayıtlarını log buffer içerisine almak için sıra bekliyor.
LOGBUFFER vs. WRITELOG
| Wait Type | Ne Anlatır? | Hangi Aşama? |
|---|---|---|
| LOGBUFFER | Log verisi RAM’deki buffer’a yazılırkenki bekleme | Hazırlık aşaması |
| WRITELOG | Log verisi diske yazılırkenki bekleme | Disk’e yazma aşaması |
İkisi genelde beraber görülür, ama LOGBUFFER daha nadirdir.
Log Buffer Boyutu
- SQL Server log verilerini genelde 60KB’lık bloklar halinde log buffer’da tutar.
- Bu buffer dolunca veya COMMIT gibi bir işlem olunca diske yazılır.
- LOGBUFFER demek, bu RAM içindeki küçük blokların bile işlenmesinde gecikme var demektir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type LIKE 'LOGBUFFER'Sonuç olarak ne yapılması gerekmektedir.
Ne Yapabilirim?
| Sorun | Çözüm |
|---|---|
| Log dosyası yavaş | SSD diske taşı, log dosyası için RAID 10 önerilir |
| Transaction’lar çok büyük | Transaction’ları parçalara böl |
| Çok sık log büyümesi | Log dosyasını sabit büyük tut, autogrow ayarını iyileştir |
| Log yazım işlemleri yoğun | Query tuning yap, gereksiz log trafiğini azalt |
| Sync replication varsa | Log flush işlemi yavaşlar, delayed durability düşünülebilir |
· HADR_SYNC_COMMIT
HADR_SYNC_COMMIT, SQL Server’ın bir synchronous (senkron) replikaya sahip Availability Group (AG) ortamında, transaction’ı commit etmeden önce verinin diğer sunucuya başarıyla gönderilip yazılmasını beklediği süreyi ifade eder.
Yani:
- Sen INSERT, UPDATE, DELETE yaptın
- Primary replica (ana sunucu) işlemi log dosyasına yazdı
- Aynı işlem secondary replica’ya gönderildi
- Secondary, log’a yazdı ve “tamam” dedi
- SQL Server bu cevabı beklerken geçen süre = HADR_SYNC_COMMIT
Aşağıdaki komut ile HADR_SYNC_COMMIT bekleme tipini görebiliriz.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type = 'HADR_SYNC_COMMIT';
Genel olarak disk üzerinde bekleme türlerini aşağıdaki komut ile görebiliriz.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type LIKE 'PAGEIOLATCH%' OR wait_type = 'WRITELOG' OR wait_type = 'ASYNC_IO_COMPLETION';
Not: Genel olarak sql server Error log’larında 833 error kodu ile bu bekleme tiplerini görürüz.
Ne Zaman Artar?
| Neden | Açıklama |
|---|---|
| Network gecikmesi | Primary ↔ Secondary replikalar arası ağ yavaşsa |
| Secondary sunucu yavaşsa | Disk I/O ya da CPU yetersizse |
| Log diski zayıfsa | Secondary log’u hızlı yazamıyorsa |
| Blocking/locking | Secondary’de log yazımı başka işlemlerle çakışıyorsa |
| Çok fazla transaction varsa | Secondary her biri için yanıt vermek zorunda |
Nasıl Azaltılır?
| Aksiyon | Açıklama |
|---|---|
| Ağ gecikmesini düşür | Primary ↔ Secondary arasındaki bağlantı iyileştirilmeli (aynı veri merkezi önerilir) |
| Secondary sunucunun diskini hızlandır | Özellikle transaction log diski çok önemli |
| Transaction’ları kısa tut | Transaction ne kadar kısa → o kadar hızlı commit |
| Sadece kritik verileri synchronous yap | Diğerlerini async yaparak performansı artırabilirsin |
| Replika yük dengesini kontrol et | Secondary üzerindeki gereksiz yük secondary’yi yavaşlatır |
| Log compression veya tuning (SQL 2022+) | Replika trafiğini daha verimli hale getirebilir |
PWAIT
PWAIT beklemesi, page (sayfa) I/O işlemleri sırasında SQL Server’ın belirli bir veritabanı sayfasının diskten okumasını beklediği bir durumdur. Bu bekleme genellikle SQL Server’ın veritabanı sayfasını diske yazdıktan sonra, sayfaların diskten okunmasını beklediği zamanlarda ortaya çıkar. Sayfalar diske yazıldıktan sonra, SQL Server bu sayfayı tekrar okumaya çalıştığında bu tür beklemeler oluşur. Yavaş diskler veya diskten veri okuma gecikmeleri bu beklemeyi artırabilir. Disk I/O performansını artırmak, sayfa dosyalarını izlemek ve indeksleri optimize etmek, bu tür beklemeleri azaltabilir.
SELECT
wait_type,
wait_time_ms AS wait_time,
waiting_tasks_count
FROM
sys.dm_os_wait_stats
WHERE
wait_type LIKE 'PWAIT'
I/O Beklemelerinin Performans Üzerindeki Etkisi
I/O beklemeleri, SQL Server performansını doğrudan etkileyen beklemelerdir. Disk I/O gecikmeleri, sorguların yanıt sürelerini artırabilir, veritabanı işlem sürelerini uzatabilir ve genel sistem verimliliğini düşürebilir. Özellikle büyük veri işlemleri ve yoğun I/O aktiviteleri sırasında bu tür beklemeler daha belirgin hale gelir.
I/O beklemeleri, SQL Server’ın disk üzerinde işlem yaptığı süreyi etkiler ve bu da veritabanı sunucusunun genel yanıt verme süresini artırabilir. Veri okuma ve yazma işlemlerinin yavaşlaması, disk kaynaklarının tükenmesi veya disk tıkanıklığı gibi durumlar bu tür beklemelerin artmasına neden olabilir.
Disk I/O İyileştirmeleri İçin Çözüm Yöntemleri:
- SSD kullanımı: SSD’ler, geleneksel HDD’lere kıyasla çok daha hızlı okuma ve yazma işlemleri sağlar.
- Disk yapılandırması: RAID seviyeleri gibi disk yapılandırmalarını optimize etmek disk performansını artırabilir.
- Index optimizasyonu: Veritabanındaki sorguların daha verimli çalışması için index oluşturmak ve gereksiz indexleri kaldırmak disk I/O yükünü hafifletebilir.
Makalenin başında belirtilen diğer bekleme tiplerine değinelim.
1. ASYNC_NETWORK_IO
İstemci uygulamasının veriyi yeterince hızlı almaması durumunda oluşan bekleme süresidir. Ağ performansı veya istemci uygulamasındaki sorunlar bu bekleme türünü artırabilir.
2. SP_SERVER_DIAGNOSTICS_SLEEP
Sunucu tanılama işlemleri sırasında oluşan bekleme süresidir. Genellikle arka plan görevleriyle ilgilidir ve kritik değildir.
3. BROKER_TRANSMITTER
Service Broker iletim işlemleri sırasında oluşan bekleme süresidir. Service Broker ile ilgili işlemlerde bir gecikme olabilir.
4. CLR_SEMAPHORE
CLR semaforu ile ilgili bekleme süresidir. CLR ile ilgili işlemlerde bir gecikme olabilir.
5. CMEMTHREAD
Insert işlemlerinin çok yüksek olduğu durumlarda karşımıza çıkabilir.
6. RESOURCE_SEMAPHORE_SMALL_QUERY veya RESOURCE_SEMAPHORE
SQL Server’ın bellek havuzlarına kaynak tahsisi yapmaya çalışırken meydana gelir. SQL Server, sorgu yürütme sırasında her bir işlem için bellek ayırmak zorundadır. Eğer bellekte yeterli yer yoksa, SQL Server işlemi bekletir. Bu tür beklemeler, SQL Server’ın belirli bir işlemi çalıştırmak için bellek tahsis etmeye çalışırken ortaya çıkar.
7. RESOURCE_SEMAPHORE_QUERY_COMPILE
SQL Server’ın sorgu derleme sırasında bellek kaynaklarını almak için beklediği bir durumdur. Sorgular çalıştırılmadan önce SQL Server, sorgu planlarını oluştururken belirli bir miktarda bellek kullanır. Eğer bellek yeterli değilse, bu bekleme türü devreye girer. Bu bekleme türü genellikle çok karmaşık sorgular veya çok sayıda işlem sırasında görülür.
Bu makalede MSSQL Server Disk I/O Bekleme Tiplerini detaylı bir şekilde görmüş olduk. Başka bir makalede görüşmek dileğiyle..
Ey iman edenler, sabırla ve namazla yardım dileyin. Gerçekten Allah, sabredenlerle beraberdir. Bakara Suresi, 153. Ayet
