Data Collector, Management Data Warehouse, Perfmon
Data Collector SQL Server 2008 ile gelen bir özelliktir. SQL Server sistemlerinin performans’larını izlemek ve raporlamak için güzel bir teknoloji. Data Collector’ları birkaç farklı şekilde kullanabiliriz.
Perfmon kullanarak anlık olarak izleyebilir ya da Data Collector set kullanarak bir baseline oluşturabilirsiniz. Baseline oluşturmamız genelde sistemde anlık bir problem olduğunda problemi tespit etmek için faydalı olabilir. Örneğin sistemdeki Buffer Cache Hit Ratio counter’u(sorguların yaptıkları isteklerin ne kadarının buffer cache’den (memory) alındığını gösterir. Counter’ların detaylarını makalenin sonundaki tablodan bulabilirsiniz) için bir data collector set oluşturdunuz. Ve “t” anında veritabanında bir problem oluştu. Data Collector Set’ten “t” anındaki Buffer Cache Hit Ratio oranını kontrol ettiniz. Ve bu oran sürekli %99 iken sorun anında %70’lere düştüğünü gördünüz. Bu sorun anında memory’de bir yetersizlik olduğu anlamına gelir. Bu şekilde data collector’lar ile oluşturduğunuz baseline’lar sorun anında size yardımcı olabilir.
Perfmon üzerinden counter’ları anlık olarak izlemek ve data collector set’ler ile baseline’lar oluşturmak için “Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak” isimli makaleyi okumalısınız.
Data Collector’ların bir başka kullanımı da Management Data Warehouse ile mümkündür. Management Data Warehouse ile data collector’ları kullanarak SSMS üzerinden bir baseline oluşturabiliyoruz. Ama default konfigürasyonunda CPU, Disk, Memory ve Network için bu baseline’lar oluşuyor. Custom baseline’lar oluşturmak da mümkün ama yapılmasının bir hayli zor olduğunu söyleyebilirim. Microsoft’tan bir arkadaşım bir zamanlar böyle custom bir management data warehouse uygulaması yapmıştı fakat o da stabil çalışmadı. Bu yüzden custom ihtiyaçlar için ben genelde permon üzerinden data collector set oluşturuyorum. Yukarda belirttiğim makalede detayları bulabilirsiniz. Default konfigürasyonla sadece Disk ve Cpu incelemesi size yeterli ise bu sefer size tavsiyem Utility Control Point olacaktır. Utility Control Point ile ilgili makaleleri aşağıda bulabilirsiniz.
“Utility Control Point ile SQL Server’ı Monitor Edin“,
“Utility Control Point’i Yönetin“,
“Utility Control Point’e Başka Bir Instance Eklemek“
Management Data Warehouse kurulumunu da bir örnekle inceleyelim.
SSMS üzerinde Management sekmesinden aşağıdaki gibi Data Collection’a sağ tıklayarak Tasks ve Configure Management Data Warehouse diyoruz.
Karşımıza gelen ekranda Do not show this page again diyerek ilerliyoruz.
Management Data Warehouse’un topladığı bilgileri saklaması için bir veritabanına ihtiyacı vardır. Bir sonraki ekranda bizden bilgileri kaydedeceği veritabanını belirlememizi istiyor. Mevcut bir veritabanını da seçebiliriz. New diyerek bu işlem için yeni bir veritabanı da oluşturabiliriz.
Bir sonraki ekranda Management Data Warehouse için yetkilendirmek istediğimiz kullanıcıyı soruyor. Ben kendi test ortamımdaki TestLogin kullanıcısına admin hakkı vererek ilerliyorum. Siz isterseniz New Login buton’una tıklayarak yeni bir login oluşturabilirsiniz. mdw_reader yetkisi raporlama için, mdw_writer yetkisi veri yüklemek için, mdw_admin yetkisi de her ikisini yapmak için gerekli yetkiler.
Bir sonraki adım olarak Data Collection Set’lerimizi oluşturmak için aşağıdaki gibi Configure Data Collection diyoruz.
Karşımıza gelen ekranda,
Server name kısmında bir önceki adımda oluşan MDW veritabanımıza ait instance’ı,
Database name kısmında ise MDW veritabanımızı seçiyoruz.
Cache directory’de veriler toplanıp MDW veritabanına aktarılmadan önce tutulacağı dosyayı seçmemiz gerekiyor. Ben C’nin altında Temp isminde bir klasör oluşturarak bu klasörü seçtim.
Alt tarafta ise aktif etmek istediğimiz data collector set’lerini soruyor. System Data Collection Sets’i de Transaction Performance Collection Sets’i de seçerek ilerliyoruz ve son ekranda finish diyerek işlemimizi tamamlıyoruz.
Aşağıdaki gibi Management > Data Collection > Reports > Management Data Warehouse sekmelerinden raporlara ulaşabilirsiniz.
Management Data Warehouse’un yanı sıra “Veritabanı Sunucunuzun Yaptığı IOPS ve Throughput’u Data Collector Kullanarak Bulmak” isimli makalede anlattığım şekilde istediğiniz counter’ı kullanarak data collector set’ler oluşturup baseline oluşturup raporlayabilirsiniz.
Aşağıda bazı önemli counter’ları ve best practice’lerini bulabilirsiniz.
Object |
Counter |
Counter Açıklama |
Alert Üretilebilecek Değer Aralığı |
Memory |
Available MBytes |
Sistemdeki boş bellek miktarı |
< 3 GB |
Memory |
Pages Input/Sec |
Bellekte bulunmadığı için, saniyede diskten erişilen page sayısı(hard page fault) |
> 20(Ortalama) |
Paging File |
%Usage |
Paging File’ın kullanım oranı |
> 70% |
Processor |
Privileged Time |
Windows Kernel işlemlerin CPU üzerinde harcadığı zaman. Yüksek miktarda I/O veya kesintiler olduğunu gösterir. DPC Time ve Interrupt Time’a ve Context Switches’e bakılmalıdır. |
> 30%(İki dakika süreyle bu seviyede kaldığında alert üretilebilir) |
Processor |
Processor Time |
Kullanılan CPU yüzdesi |
> 90%(İki dakika süreyle bu seviyede kaldığında alert üretilebilir) |
System |
Context Switches/sec |
İşlemcinin işlediği thread’i değiştirmesi. Cpu başına 6000’i geçmemeli. |
> 384000 |
System |
Processor Queue Length |
İşlemci kuyruğundaki çalışmayı bekleyen process sayısı |
> 640 |
PhysicalDisk |
Avg. Disk sec/Read |
Saniyede, ortalama okuma yapılan zaman |
> 0.30 |
PhysicalDisk |
Avg. Disk sec/Write |
Saniyede, ortalama yazma yapılan zaman |
> 0.30 |
PhysicalDisk |
% Idle Time |
Diskin kullanılmayan kısmının yüzdesi |
< 50%(İki dakika süreyle bu seviyede kaldığında alert üretilebilir) |
SQLServer:Access Methods |
Forwarded Records/sec |
Update sırasında page’e sığmaması ve pointerle başka bir page’e işaret edilmesi. Sadece heap tablolarda olur. Cluster index create-drop yapılabilir. |
>(SQLServer:SQL Statistics:Batch Requests/sec)/10 |
SQLServer:Access Methods |
FreeSpace Scans/sec |
Insert yapılan heap tablolarda insert edilecek row için boş page taraması yapılması. |
>(SQLServer:SQL Statistics:Batch Requests/sec)/10 |
SQLServer:Access Methods |
Index Searches/sec,Full Scans/sec |
Saniyedeki index search ve table scan sayıları. Index ihtiyacı var demektir. |
(Index Searches/sec) / (Full Scans/sec) < 100 |
SQLServer:Access Methods |
Page Splits/sec |
Saniyedeki bölünen page sayısı. Fillfactor sorunu çözecektir. |
>(SQLServer:SQL Statistics:Batch Requests/sec)/5 |
SQLServer:Access Methods |
Scan Point Revalidations/sec |
Scan işlemi sırasında, işlemin devam edebilmesi için scan pointin saniyede yeniden doğrulanma sayısı |
>10 |
SQLServer:Access Methods |
Worktables Created/sec |
Saniyede, tempdb ‘de oluşturulan tablo sayısı(Table spool,Index spool vb..) |
> 400 |
SQLServer:Buffer Manager |
Buffer cache hit ratio |
SQL Server’ın bellekten istediği veriyi bulma oranı |
< 97% |
SQLServer:Buffer Manager |
Lazy writes/sec |
Buffer cache’i boşaltmak için dirty page’lerin saniyedeki diske yazılma sayısı |
>20 |
SQLServer:Buffer Manager |
Page life expectancy |
Data page’lerin saniye cinsinden buffer ‘da kalma süresi |
< 300 |
SQLServer:Buffer Manager |
Page lookups/sec |
Saniyede, page’i buffer pool’da bulmak için gönderilen istek sayısı. Saniyedeki Batch Requests sayısından 100 kat daha fazla olursa query planlar verimsiz demektir. Yüksek I/O yapan sorgular tune edilmeli. |
(Page lookups/sec) / (Batch Requests/sec) > 100 |
SQLServer:Latches |
Latch Waits/sec |
Saniyede oluşan latch request bekleme sayısı |
(Total Latch Wait Time) / (Latch Waits/Sec) > 10 |
SQLServer:Locks |
Lock Requests/sec |
Saniyede, lock isteği olan request sayısı |
(Lock Request/sec) / (Batch Requests/sec) > 500 |
SQLServer:Locks |
Lock Timeouts (timeout > 0)/sec |
Lock nedeniyle timeout’a düşülmesi |
<>0 |
SQLServer:Locks |
Number of Deadlocks/sec |
Deadlock oluşması |
>0 |
SQLServer:Memory Manager |
Memory Grants Pending |
Memory için bekleyen connection sayısı |
<>0 |
SQLServer:SQL Statistics |
SQL Compilations/sec |
Saniyede, derlenen sorgu sayısı |
>(Batch Requests/Sec)/5 |
SQLServer:SQL Statistics |
SQL Re-Compilations/sec |
Saniyede, derlenen ve daha önce en az bir kere derlenmiş olan(query plan’ı çıkartılmış) sorgu sayısı |
>(SQL Compilations/sec)/10 |
SQLServer:Database |
Log Flush Waits/sec |
Veritabanının log’una yazarken SQL Server’ın ortalama bekleme süresini gösterir. Yükselen değerler log’a yazarken uzun zaman geçtiğini gösterir.
Bu da sistemde concurrency sorunlarına ve performans kaybına neden olur. |
Artan değerler kötüdür. |
Network Interface |
Bytes Received/sec
Bytes Sent/sec |
Saniyede network’ten alınan ve gönderilen veri miktarını byte olarak gösterir.
Ani artışlar, performans sorunları ile aynı zamanda meydana geliyorsa sorunun kaynağı olabilirler. |
Artan değerler kötüdür. |
SQLServer:Buffer Manager |
Checkpoint pages/sec |
SQL Server’ın checkpoint işleminin saniye kaç kez gerçekleştiğini gösterir.
Checkpoint işlemi sık gerçekleşiyorsa çok fazla değişiklik yapılıyor demektir. Bu da daha fazla IO demektir. IO anlamında darboğaza sebep olabilir.
Ani artışlar, performans sorunları ile aynı zamanda meydana geliyorsa sorunun kaynağı olabilirler. |
Artan değerler kötüdür. |