Buffer Cache Hit Radio : SQL Server’ın bufffer cache den istediği ve getirdiği page miktarına dair bir orandır. Yüksek olması buffer cache’de yüksek miktarda page’e erişiliyor ve çekiliyor demektir. Page Life Expectancy değeriyle birlikte önemli bir göstergedir. Memory baskısı yoksa %90’ın üzerindedir.

Page Life Expectancy : Page’in buffer da kalma süresini gösterir. Memory baskısı yoksa yüksek değerlerdedir. Bu ve yukarıdaki değer sys.dm_os_perfomrance_counters DMV’sinden görüntülenebilir.

MEMORY_ALLOCATION_EXT  :  İşletim sisteminin ya da SQL Server’ın memory allocation süreciyle ilgili bir beklemedir.

RESOURCE_SEMAPHORE : Bir worker thread’in sorguyu çalıştırabilmek için memory kaynağına izin verilmesini bekliyor. Eş zamanlı sorgular çalıştırıldığında sıklıkla gözlenen bir beklemedir.

Working set trimmed log mesajı : SQL server error log dosyasında “A significant part of SQL Server process memory has been paged out” hatası alıyorsak, SQL Server harici bir memory baskısı altındadır.  

Hafıza Performansı yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

TempDb geçici işlemlerin tutulduğu bir sistem veritabanıdır. Diğer sistem veri tabanlarına nispeten daha kritik bir konumdadır. Genel olarak şunları barındırır:

• Geçici tablolar (temp tables) ve bu tablolara ait veriler
• İstatistik güncellemeleri (Statistics updates)
• Trigger’lar
• Online index işlemleri (sort_in_tempdb)
• Cursor’lar
• Geçici değişkenler
• DBCC CheckDb komutu operasyonları
• Join işlemleri

SQL Server servisini yeniden başlattığımızda TempDB tekrar drop edilip oluşturulur. Diğer veritabanları gibi sürekli değildir. Servis her başladığında Model veritabanından kopyalanarak oluşturulur. TempDB’nin yedeği alınamaz, yedekten geri dönülemez ve recovery modeli değiştirilemez. Simple modeldedir. Drop edilemez. Filegroup sayısı artırılamaz. Collation bilgisi değiştirilemez. Offline ya da read only mode’a alınamaz. Yukarıda sıraladığımız içeriğinden dolayı, sorgu performansını direkt etkileyen bir sistem veritabanıdır.
TempDb’de bir geçici tablo oluşturduğumuzda, normal veritabanında tablo oluşturduğumuzda nasıl yer ayrılıyorsa (allocation), tempdb de de öyle bir allocation süreci işler. Bu süreçte üç page sözkonusudur. PFS(Page Free Space) , GAM(Global Allocation Map), SGAM(Shared Global Allocation Map). Bir sql server objesini oluşturmak ya da silmek için Sql server PFS ve SGAM page’lerine yazar. Latch dediğimiz, aşağıda açıkladığımız yapılar bu page’leri hafızada korur. Her bir tempdb data file için birer adet PFS ve SGAM page mevcuttur.

PFS(Page Free Space) : Her page için bir byte’lık bir bilgi tutar. Bu bilgi , ilgili page de ne kadar boş alan olduğunu, ne için kullanıldığını tutar. Bir PFS page yaklaşık 64MB boyutunda page’e dair bilgileri tutar. Bir data file içerisinde her 64MB için bir PFS page den söz edebiliriz. Herhangi bir veritabanı data file için ilk page PFS dir. Page ile ilgili bir veritabanı hatasında bunu görebiliriz. Örneğin 2:1:1 ifadesi, database id:2 ve 1 numaralı page demektir. Keza tempdb içn şu ifade 5:3:1 database id : 5, file id:3 ve ilk PFS page i göstermektedir.
GAM (Global Allocation Map) : GAM Page her extent (8 page) için, hangisinin dolu hangisinin boş olduğunu gösteren bir bitlik bir bilgi tutar. SQL Server boş extent’leri bu page’lere bakarak tespit eder. Her extent için bir bit kullanılması bir GAM page’in 4GB bir alanı yönetmesine olanak tanır. Bir data file’daki ilk GAM page’in page numarası 2’dir. 2:1:2 TempDB deki ilk GAM page’i gösterir.
SGAM (Shared Global Allocation Map) : Her extent için yine bir bit olarak mixed extent mi full extent mi bilgisini tutar. SQL server küçük verileri yerleştirmek için boş alan içeren mixed extentleri bulmak için bu page’i kullanır. GAM gibi 4GB lık bir alanı yönetir. Bir data file daki ilk SGAM page’in numarası 3 tür. Yani 2:1:3 tempdb nin ilk SGAM page’idir.

Tempdb içerisinde çok fazla nesne oluşturulduğunda tempdb contention oluşur. Yukarıda bahsettiğimiz PFS, GAM ve SGAM page’lerinde exclusive lock durumu oluşur. Bu durumda sistemde PAGELATCH_xx wait türü görülmeye başlanabilir. Bu beklemenin tempdb contention kaynaklı olduğuna amin olabilmek için wait’in açıklamasında page’a dair 2:1:1 gibi bir rakam dizisi görülüyorsa bu beklemenin tempdb contention kaynaklı olduğu söylenebilir. Zira rakam dizisindeki ilk rakam veri tabanı id’sidir ve tempdb’nin id’si 2’dir.

Latch Kavramı
Buffer pool, işletim sisteminin SQL server için hafızada(memory) rezerve ettiği bir alandır. SQL Server gelen taleplere göre diskten ilgili page’leri memory de buffer pool’a atar. Bu sistem içerisinde, verinin buffer pool içerisinde tutarlılığını korumak için bir sisteme ihtiyaç vardır. Latch, SQL Server’ın memory içindeki bu verinin tutarlılığını sağladığı bir lock mekanizmasıdır. Paylaşılan hafıza haynaklarını korumaya yarar. Bir thread bir page üzerinde çalışmayı talep ettiğinde, aynı anda bir page’i sadece bir thread değiştirebileceğinden bu latch üzerinde “latch queue” denilen kuyruk oluşur. Bu page taleplerini dağıtmak amacıyla tempdb data file sayısının , işlemci çekirdek sayısıyla orantılı olarak artırılması önerilir. Çünkü her bir data file için ayrı bir “latch queue” vardır. Bu data file sayısını artırma işlemi thread’in page’i bekleme süresini azaltır. Bu da sorgu performansının artması demektir. Aşağıda bu konuyu resmetmeye çalıştım.

TempdDB Metadata Contention
Birden fazla session geçici tablo oluşturduğu esnada, TempDB’nin sistem tablolarına aynı anda erişmek istediğinde metadata contention oluşur. Bu iş yükü sistem tablolarında gecikmeye sebep olur ve sorgu performansları düşmeye başlar.

TempDb yapılandırması için öneriler:

• Antivirüs taramasından SQL Server dosyalarını exclude etmek
• TempDB yi ayrı bir diskte ve mümkünse SSD üzerinde tutmak. Data ve Log dosyalarını ayrı diskte tutmak.
• Raid0 ya da Raid10 yapısında tutmak.
• TempDB yi başka uygulamaların, veritabanlarını kullandığı disklerde konumlandırmamak
• Index Rebuild işleminde “sort in tempdb” seçeneği tempdb performansını etkiler. Gereksiz kullanımından kaçınılmalıdır.
• Sec/Read ve Avg. Sec/Write oranını takip edip 50ms altında kalmasına dikkat etmek
• Şu wait türleri TempDb performansıyla doğrudan ilişkilidir. PAGELATCH_EX, PAGELATCH_UP, CXPACKET
• TempDb contention durumunu takip etmek. Microsoft’un “allocation contention” problemini azaltmak için önerilerine şu yazıdan ulaşabilirsiniz.
• TempDB data file sayısını, sisteminiz 8 core dan az ise core sayınız kadar, 8 core dan fazla ise 8 data file olarak ayarlamak. Data file boyutlarının aynı olması önemlidir. İşlemci sayısının 8 den fazla olduğu durumda 8 den fazla her 4 core için bir data file eklenebileceğini söyleyenler de vardır. Onlarca core içeren sunucular için bu düşünülebilir. Yani 12 core varsa 8 + 1 (kalan 4 core için bir file) = 9. Düşük ölçekli sunucularda daha önceleri 8 core için 8 dosya uygundu. Ancak onlarca core içeren sistemler için yük testi yaparak 8 den fazla dosya sayısına karar vermek daha yerindedir.
• Autogrowth özelliği açık olmalı. Tempdb her otomatik büyüme esnasında “exclusive lock” mekanizmasıyla kilitlenir. Bu da performansı doğrudan kötü etkiler. Veritabanı kurulurken en uygun başlangıç boyutunu (en az 2048 MB gibi) ve auto growth boyutunu vermek bu yüzden çok önemlidir.

TempDB nin sistem üzerinde tutulduğu yer bilgisi için sp_helpdb tempdb komutu kullanılabilir.

TempDb’nin kullandığı disk alanını sys.dm_db_file_space_usage DMV’sini sorgulayarak görebiliriz. Tempdb içerisinde çok fazla yer kaplayan nesneleri görmek için ise sys.dm_db_session_space_usage ve sys.dm_db_task_space_usage dmv’leri kullanılabilir.

TempDB yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

 SQL server’a bir veri isteği geldiğinde bu istek normal, optimum şartlarda işlemcinin hızına göre hemen gerçekleştirilebilecek bir işlem iken, kaynakların (ram, işlemci core sayısı, disk boyut ve hızı vb.) sınırlı olması ve gelen isteğin çokluğu sebebiyle işlemci bu istekleri hemen yerine getiremez, bir işlem kuyruğuna sokar ve bu istekler için bekleme sözkonusu olur. İşte SQL Server bu beklemeleri türü, süresi vb. bilgileriyle kaydeder. Çeşitli bekleme türleriyle ilgili bu kayıtlara wait statistics adı verilir. Yüzlerce wait türü vardır. Performans analizi yapabilmemiz için çok önemli göstergelerdir. Performance counters ile birlikte yorumlamak daha doğru sonuçlar üretmemizi sağlar.

Beklemeler temel olarak iki kategoriye ayrılır:

Kaynak Beklemeleri (Resource Wait) : Görev bekleme listesindedir ve suspended statüsündedir. Disk/hafıza’da yazma/okuma beklemesi ya da başka bir transaction tarafından kilitlenen page’in beklenmesi gibi.

Sinyal Beklemeleri (Signal Wait) : Görev runnable statüsündedir ancak işlemcide sıra beklemektedir

 SQL server’a bir istek(request) geldiğinde bu istek kendisine bir “worker thread” atanan bir  göreve dönüştürülür. Bir istek “worker thread” talep ettiğinde,  SQL server bu isteğe atamak için boşta bir worker thread arar. Bulamazsa ya da sunucunun maximum worker threads limitine ulaşılmışsa istek kuyruğa eklenir ve herhangi bir worker thread’in boşa çıkmasını bekler. Worker thread sayısı sunucumuzun özelliklerine göre parametrik belirlenen bir rakamdır. Örneğin 64 bit ve 4’ten fazla core içeren bir sunucuda worker thread sayısı 512+((core sayısı -4)*16) formülüyle bulunur. 16 core içeren bir sunucu için bu rakam 704 e tekabül eder. Aşağıdaki ekranda maximum worker threads ile iligili bir ayar sözkonusudur.

 Proses diskte yüklü uygulamanın çalıştırıldığı, hafızaya yüklendiği, işlemci tarafından yürütüldüğü anda aldığı isimdir. Bir proses birden fazla thread barındırabilir ve buna multithreading adı verilir.

  Örneğin bir select sorgusu çalıştırdık diyelim, bu sorgunun istediği bilgi için önce buffer pool’a bakılır. Burada yoksa diske gider thread, diskten yanıt beklediği sırada suspended statüsündedir ve PAGEIOLATCH wait türü oluşur. Veri diskten alınıp buffer pool’a taşındığında statüsü runnable dır ancak bu kez de CPU zamanlayıcısından sinyal beklemeye başlar. Kuyruğun sonundadır. CPU core ları başka threat lerle meşguldür. Sıra kendisine geldiğinde listenin başına alınır ve sorgu çalıştırılır. Her ne kadar bu işlemlerin bazısı eş zamanlı gerçekleşse de aşağıda bu işlemleri bir nebze sıralı olarak şematize etmeye çalıştım:

Wait istatistiklerine ait bilgi alabileceğimiz iki önemli DMV (dynamic management view) vardır:
sys.dm_os_waiting_tasks :  herhangi bir kaynağı bekleyen aktif görevleri
sys.dm_os_wait_stats :  instance seviyesinde, sql server servisinin son başlamasından bu yana toplam bekleme sürelerini gösterir.

Sunucunun son başlamasından bu yana toplanmış olan bu istatistikler aşağıdaki komutla temizlenebilir:

DBCC SQLPERF(‘sys.dm_os_wait_stats’,CLEAR);Bir de SQL Server 2016 versiyonuyla birlikte gelen sys.dm_exec_session_wait_stats view’ı vardır ve session bazında thread’lerin karşılaştığı beklemeleri gösterir.

 Yukarda bahsettiğimiz sys.dm_os_wait_stats view’ını sorguladığımızda aşağıdaki bilgileri alırız:

Wait_type : Gerçekleşen bekleme türü
Waiting_task_count : Bu bekleme türü kaç kez gerçekleşti
Wait_time_ms : Wait_type alanında belirtilen beklemenin toplam geçen zamanı. signal_wait_time_ms bekleme süresini de içerir. Runnable ve suspended statüsünde kuyrukta harcanan toplam zamanı gösterir. 
Max_wait_time_ms : Bir thread in bu bekleme türü için beklediği en fazla süre
signal_wait_time_ms : Thread’in runnable statüsünde kuyrukta CPU beklediği zaman. Yüksek değerler görüyorsak CPU darboğazı(bottleneck) olduğunu düşünürüz.

Latch, Hafızadaki veriyi korumak için kullanılan bir lock mekanizmasıdır ve kullanıcı tarafından kontrol edilemez. Bir proses latch için beklediğinde de bazı beklemeler oluşur. Latch’in üç türü vardır ve bu üç türe göre aşağıdaki isimlendirmelerde beklemeler kaydedilir: 
      – I/O Latch : PAGEIOLATCH_*
      – Buffer Latch : PAGELATCH_*
      – Non-buffer latch : LATCH_*

Yukarıdaki tanımlamalardan sonra SQL Server’ı gözlemlemek için hangi wait türlerinin takibinin önemli olduğu konusuna geçebiliriz. CPU yoğunluğu, I/O yoğunluğu, memory yoğunluğu, block/deadlock durumları gibi durumları analiz etmek için yaygın olarak gözlemlediğimiz wait türleri vardır. Yüzlerce bekleme türü var ancak SQL Server performansını gözlemlemek için yaygın olarak aşağıdakiler izlenir.

PAGEIOLATCH_* : Bir görev buffer pool’da olmayan bir Page’in diskten getirilmesini bekliyor. I/O yoğunluğu yüksek veri tabanlarında çok sık görülen bir beklemedir. Bu beklemeyi sık görüyorsak diskte I/O darboğaz(bottleneck) oluştuğundan söz edebiliriz. Disk sistemlerinizin Sql Sever’a cevap vermekte yavaş kaldığına işaret eder. Ancak bu gecikme başka sebeplerden de kaynaklanabilir. Optimize olmayan sorgular, index sorunları, güncel olmayan istatistikler, implicit conversion gibi konular da sebep olabilir. _sh shared latch , _up update latch, _ex exclusive latch için beklendiğini gösterir.

PAGELATCH : PAGELATCH beklemesi, bir görevin(task), başka bir task tarafından latch edilmiş(lock), buffer pool’daki page’e erişmek için beklediğini gösterir. İndex’lemenin gözden geçirilmesi, partitioning çalışması ve tempdb performansının iyileştirimlesi gibi çalışmalarla azaltılabilir. 

WRITELOG : Transaction commit edildiğinde ya da checkpoint işleminde log block diske yazılırken oluşan bekleme türüdür. Bir task transaction log bloğunun diske yazılmasını beklemektedir. Çok sık karşılaşılıyorsa transaction log’ların bulunduğu disklerde bir problem varlığından söz edilebilir. Ancak yine tek sorun diskler olmayabilir. Çok fazla transaction çok sık aralıklarla commit ediliyorsa bu da sebep olabilir. Transaction sayısı azaltılabilir. Yine gereksiz index’ler de bu beklemeye sebep olur. Bir tabloda ne kadar fazla index varsa, tablo her insert/update aldığında oluşan log miktarı da o kadar fazla olur. İndex parçalanmaları da yine bu beklemeye sebep olabilir. 

LCK_M_* : Thread veriye erişmek ve lock koymak için başka bir görevin kilitlediği kaynağı bekliyor. M harfinden sonra gelen harf lock türünü gösterir. LCK_M_S shared lock, LCK_M_U update lock, LCK_M_X exclusive lock bazı örnekleridir. 60’dan fazla türü vardır. Şu sebeplerle görülür genel olarak:
– Büyük bir tablo tarama ya da update işlemi tabloda “lock escalation” a sebep oluyor.
– Ulaşılan datadaki gereksiz shared lock’lar 
– Optimize edilmesi gereken update, insert sorguları var (LCK_M_U )
– Optimize edilmesi gereken select sorguları var (LCK_M_S )

RESOURCE_SEMAPHORE : Bir worker thread bir sorgu için memory kaynağı beklerken ortaya çıkar. Çok fazla hafıza ihtiyacı olan eş zamanlı sorguların çok fazla olduğu sistemlerde görülür. Bu bekleme türünü ve memory_allocation_ext beklemesini alıyorsak veri tabanımız üzerinde memory baskısı olduğunu düşünebiliriz.

I/O_COMPLETION, ASYNC_I/O_COMNPLETION : Backup gibi uzun süren I/O işlemlerinde görülebilir. Bu bekleme türünü görüyorsak diskte bir darboğaz(bottleneck) oluştuğunu düşünebiliriz.

CXPACKET : Paralel sorgu çalıştırılması sırasında thread’lerin senkronizasyonu için beklenen zamandır. Kaynaklara dair bir darboğaz olduğunu göstermez. Veri tabanında paralel sorguların çalıştığını ve beklenenden fazla zaman aldığını gösterir. Belirli bir miktar işi on tane işçiye paylaştırdığımızı farzedelim, işçilerden bazıları işlerini erkenden bitirdi ve yeni iş bekliyorlar. İstatistikler güncellenerek azaltılabilir.

SOS_SCHEDULER_YIELD: Thread’in işlemciden zamanlayıcı(scheduler) beklediği ve runnable statüsünde olduğu süredir.

THREADPOOL : Yukarda daha önce bir isteğin kendisine “worker thread” atanması için beklediğinden bahsetmiştik. Bu bekleme o anda oluşur. İşlemci sayısına göre worker thread sayısı olduğunu gözönüne alırsak, bu beklemeyi sürekli görüyorsak sunucumuzun işlemci core sayısını artırmamız gerektiğini düşünebiliriz. Ya da maximum worker thread sayısı düşük kalmış olabilir.

ASYNC_NETWORK_IO : Network’te darboğaz oluştuğu gibi yorumlanır ama tek sebebi bu değildir. Veri tabanımızı kullanan uygulamanın satır satır veri çekip işlediği durumlarda oluşur. Bir satır çeker işler, bir satır daha çeker işler böyle devam eder. İstemcinin veri tabanından çektiği veriyi kullanma şekli sebebiyle oluşturduğu bir beklemedir. 

HADR_WORK_QUEUE : Always On yapısına dahil olan veri tabanları için ayrılmış olan thread’lerin görev atanmasını beklediklerini gösterir. Boşta kalma bekleme süresini gösterdiği için yüksek olması umulur.

Son olarak, beklemeler tek başlarına tüm sistem performansı hakkında yeterli bilgi vermezler. Sql Server’ı barındıran işletim sisteminin performansına dair bazı bilgilere de ihtiyaç duyarız. İşletim sistemine dair bu bilgilere de performans counters adı verilen sayaçları izleyerek ulaşırız. Bu sayaçlar bize sistem kaynakları üzerindeki yoğunluğu ve beklemeleri(queue) gösterir. Wait türlerini ve kuyrukları(queue) birlikte izlemek daha iyi sonuç verecektir

SQL Server’da Wait Statistics Konusu yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Bu bekleme türlerine (wait types) dikkat!

sys.dm_os_wait_stats view’ı çalıştırılan tüm görevlere dair bekleme durumları ile ilgili edinebileceğimiz view’dır. Aşağıdaki bekleme türlerinde performas kaybı gözlediğimizde sistemde I/O Bottleneck oluştuğunu düşünebiliriz.

•PAGEIOLATCH
•WRITELOG
•TRACEWRITE
•SQLTRACE_FILE_WRITE_IO_COMPLETION
•ASYNC_IO_COMPLETION
•IO_COMPLETION
•LOG_BUFFER

Nasıl İzlenir?

Microsoft’un «best practice» en iyi deneyimlerinde bottleneck(darboğaz) durumu ile ilgili bazı sayaçlar (performance counter) ve referans değerler belirlenmiştir. Bu darboğazı gözlemlemek için Performance Monitor aracı ve sayaçlar (performance counters) kullanılır. SQL server ile ilgili yüzlerce sayaç vardır ancak disk performansını gözlemlemek için gerekli olanları aşağıda özetlemeye çalıştım. Bunları sys.dm_os_performance_counters dmv’si aracılığıyla görebiliriz. Bu izleme yavaş diskler, tıkanan işlemler vb. sorunlarda bize yardımcı olur.

SQL Server’ın kullandığı depolama ünitelerinin performansı üç farklı yönden ölçülür. Bunlar:

• Saniyedeki I/O işlemleri (I/O operations per second, IOPS)
• Akan veri miktarı diyebileceğimiz disk throughput
• Gecikme (Disk Latency)

Bunların nasıl ölçülebileceğini sırayla açıklayalım

• IOPS şu performans sayaçlarıyla ölçülür:

Disk Reads / Sec : Saniyedeki okuma sayısı
Disk Writes / Sec : Saniyedeki yazma sayısı

• Throughput kavramı periyodik belirli bir sürede aktarılan veri miktarını ifade eder. Şu sayaçlarla ölçülür:

Disk Read Bytes / Sec : Okuma işlemleri sırasında diskten saniyede okunan veri miktarı
Disk Bytes /Sec : Okuma ya da yazma işlemleri boyunca diskten okunan ya da yazılan veri miktarı
Disk Write Bytes / Sec : Yazma işlemleri boyunca saniyede diske yazılan veri miktarı

• Latency(gecikme) I/O isteğinin oluşmasından cevap gelmesi arasında geçen süreyi ifade eder. Şu sayaçlarla ölçülür:

Avg. Disk sec / Read : Diskten veriyi okumak için geçen ortalama zaman
Avg. Disc Sec / Write : Diske veriyi yazmak için geçen ortalama zaman  

Microsoft’un her  iki sayaç için best practice değerleri şunlardır:

Log Dosyaları için 1-5 ms (1ms ideal)
OLTP Data dosyaları için 4-20 ms (10 ms ideal)
OLAP Data dosyaları için <= 30 ms

Aşağıdaki tabloda I/O performansını ölçmek için kullanılan diğer bazı sayaçların anlamlarını ve referans değerlerini görebiliriz. 

I/O Bottleneck yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.