Performans analizi örneği

Video talimatlarını takip etmek için örnek raporu buradan açın.

Performans raporu nasıl yorumlanır

HQbird kullanarak veya cc.ib-aid.com adresinden ayrı bir hizmet olarak IBSurgeon Performance Analysis ile Firebird trace günlüklerinden bir performans raporu oluşturabilirsiniz.

Bu rapor, Firebird veritabanlarında SQL sorgu yürütme hakkında ayrıntılı bilgi sağlayan güçlü bir tanılama aracıdır. Bu kılavuz, performans darboğazlarını sistematik olarak tanımlamak ve çözmek için trace raporlarının nasıl yorumlanacağını ve kullanılacağını açıklar.

1. Performans Raporu Yapısı

┌─────────────────────────────────────────┐
│         Performans Raporu               │
├─────────────────────────────────────────┤
│ 1. Performans Özet Grafikleri           │
│    ┌────────────────────────┐           │
│    │  En İyi Sorgular       │           │
│    │     En iyi özet        │           │
│    │     En iyi sıklık      │           │
│    │     Süreler            │           │
│    │     Getirmeler         │           │
│    │     Okumalar           │           │
│    │     Yazmalar           │           │
│    │  Zaman Serisi Grafiği  │           │
│    │     Süreler            │           │
│    │     Sorgu sayıları     │           │
│    │     Getirmeler         │           │
│    │     Okumalar/Yazmalar  │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. En İyi Sorgular Analizi              │
│    ┌────────────────────────┐           │
│    │ Sorgu Sıralamaları     │           │
│    │                        │           │
│    │  Süreye Göre───┐       │           │
│    │                │       │           │
│    │  Zamana Göre────┤       │           │
│    │  Özet          │       │           │
│    │                │       │           │
│    │  Plana Göre────┤       │           │
│    │  Özet          │       │           │
│    │                │       │           │
│    │  Sıklığa Göre──┤       │           │
│    │                │       │           │
│    │  Plana Göre────┤       │           │
│    │  Sıklık        │       │           │
│    │                │       │           │
│    │  Getirmelere───┤       │           │
│    │  Göre          │       │           │
│    │                │       │           │
│    │  Okumalara─────┤       │           │
│    │  Göre          │       │           │
│    │                │       │           │
│    │  Yazmalara─────┘       │           │
│    │  Göre                  │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Süreç Özeti                         │
│    ┌────────────────────────┐           │
│    │ Süreç Başına İstatistikler│         │
│    │ - Yürütme sayıları     │           │
│    │ - Getirmeler, vb.      │           │
│    │ - Süre metrikleri      │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Adres Özeti                         │
│    ┌────────────────────────┐           │
│    │İstemci Adresi Başına    │           │
│    │İstatistikler            │           │
│    │ - Bağlantı sayıları     │           │
│    │ - Süreler               │           │
│    │ - Getirmeler, vb.       │           │
│    │ - Süreç adları          │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Sorgu Detayları Yapısı:
┌────────────────────┐
│ Sorgu Bilgileri    │
├────────────────────┤
│ - SQL Metni        │
│ - İşlem bilgisi    │
│ - Yürütme Planı    │
│ - Süre İstatistikleri│
│ - Kaynak İstatistikleri│
│   * Getirmeler     │
│   * Okumalar       │
│   * Yazmalar       │
│   * İşaretlemeler  │
│ - İstemci Bilgileri│
└────────────────────┘

Performans raporu, veritabanı etkinliğinin hiyerarşik bir görünümünü sağlar:

1. Performans Özet Grafikleri

• Temel metriklerin zaman içindeki görsel temsili - aktivite/yük zirvelerini kolayca görebilirsiniz. (HQbird’deki Gelişmiş Performans İzleme’de dakika bazında analiz raporu da mevcuttur, kısaltılmış sürümü Portal aracında bulunur - ayrıntılar için bu videoya bakın).

• Kalıpları ve anormallikleri belirlemeye yardımcı olur: iyi performans gösteren dönemlerdeki (ör. geçen hafta/ay) grafikleri performans sorunlarıyla karşılaştırmak sorunu belirlemeye yardımcı olabilir.

2. En İyi Sorgular Analizi

• Kapsamlı analiz için birden fazla sıralama perspektifi: en uzun sorgular, en sık çalışan sorgular, en çok zaman alan sorgular (metne veya plana göre gruplandırılmış) ve daha fazlası.

• Her boyut farklı optimizasyon fırsatlarını ortaya çıkarır

• Her sorgu için ayrıntılı istatistikler:

• Süre metrikleri (min, maks, ort, medyan)

• Kaynak tüketimi (getirmeler, okumalar, yazmalar)

• Yürütme kalıpları - en iyi sorgular için kaynak sayıları.

3. Süreç Özeti

• İstatistikleri yürüten sürece göre gruplar

• Sorunlu uygulamaları belirlemeye yardımcı olur

• Süreç başına kaynak tüketimini ve veritabanı işlemlerini (bağlantılar, sorgular vb.) ve metrikleri (getirmeler, okumalar vb.) gösterir

4. Adres Özeti

• İstatistikleri istemci bağlantısına göre gruplar

• İstemciler arasındaki yük dağılımını ortaya çıkarır

• Bağlantıya özgü sorunları belirlemeye yardımcı olur

Her bölüm performans analizini farklı düzeylerde destekler:

• Sistem genelindeki kalıplar (Grafikler) - sorunların genel olarak ne zaman ve nerede oluştuğunu görün.

• Sorgulardan kaynaklanan en belirgin etki (En İyi Sorgular) - önce optimize edilmesi gereken sorguları belirleyin.

• Uygulama düzeyindeki sorunlar (Süreç Özeti) - performans sorunlarına neden olan uygulamaları belirleyin.

• İstemci düzeyindeki sorunlar (Adres Özeti) - en büyük sorgu akışına sahip IP adreslerini (iş istasyonları, istemci bilgisayarlar) belirleyin.

2. Zaman Özeti ve Plan-Özet Analizi

Performans durumunun analizine Özet bölümleriyle başlanması önerilir. Örnek rapordaki Plan-Özet bölümünü açmak için buraya tıklayın.

Zaman Özeti, her benzersiz SQL ifade kalıbı için toplam yürütme süresini toplar.

Bunu, hangi sorguların zaman içinde en fazla veritabanı kaynağını tükettiğini gösteren bir “maliyet merkezi” raporu olarak düşünün.

Sorgular parametrelendirilmemişse, yani parametre yer tutucusu (:myparam1) yerine SQL metninde açıkça parametre değerleri içeriyorsa, en yüksek sıklığa sahip sorguları belirlemek için "Plan-Özet" bölümünü kullanmak gerekir.
Parametrelendirilmemiş sorgu örneği: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Parametrelendirilmiş sorgu örneği: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Özet bölümündeki her sorgu, aşağıdaki temel bölümleri içeren bir başlığa sahiptir:

• Özet: Toplam süre yüzdesi, bir sorgunun genel veritabanı süresinin ne kadarını tükettiğini gösterir.

• Sıklık: Sorgu kalıbının kaç kez göründüğü

• Getirme, Okuma, Yazma: kaynak metrikleri

Örneğin, eğer

Özet: %19.08 (20541791 ms'nin 3920272'si)

Bu, bu sorgu kalıbının toplam veritabanı süresinin neredeyse %20’sini tükettiğini söyler - acil dikkat gerektiren önemli bir bölüm.

Plan-Özet bölümünde başlığın altında, sorguları gruplamak için kullanılan SQL yürütme planını göreceğiz; Zaman-Özet’te ise sorgunun kendisinin metni olacaktır.

Sorgu kalıbı birden fazla belirli sorguyu temsil ettiğinden, bağlantıya özgü bilgiler kalıba karşılık gelen ilk sorgudan alınır:

Yukarıdaki ekran görüntüsünde, kalıp için örnek ifadenin başlığını görebilirsiniz; bu SQL’i başlatan uygulama adı, bağlantı kimliği ve işlem kimliği ile IP adresi ve işlem ayrıntılarından oluşur.

Aşağıda plan (Zaman-Özet için; Plan-Özet için atlanır çünkü zaten başta gösterilmiştir), parametre değerleri (görünüm sırasına göre) ve tablo başına istatistikler yer alır:

Lütfen unutmayın, Plan-Özet’te SQL’leri yürütme planını kullanarak gruplarız; bu, kalıp için yalnızca planın sabit olduğu anlamına gelir. Zaman-Özet’te ise SQL ifade metnini kullanarak gruplarız ve diğer şeyler (parametre değerleri, yürütme süreleri vb.) farklı olabilir. Bu bilgiyi yürütme kalıbının bir örneği olarak kullanın (vakaların %99’unda sorunu yeniden üretmek için yeterlidir).

Aşağıda, bu belirli sorgunun yürütmelerini içeren bireysel grafik bulunmaktadır. Gördüğünüz gibi, bu sorgu genel bakış grafiğinde fark ettiğimiz yüksek yük döneminde başlatılmıştır.

Ve sonunda, kalıba karşılık gelen TÜM sorgular için çok önemli bir istatistik koleksiyonu ve kaynak adreslerinin listesi bulunur:

Bu istatistiklerde minimum, maksimum, ortalama ve medyan yürütme sürelerini, ayrıca getirmeler, okumalar, yazmalar ve işaretlemeler (önbellek temizleme işlemleri) için aynı istatistikleri görebiliriz.

2.1. Zaman Özeti Nasıl Kullanılır:

• Önce orantısız zaman tüketen sorguları belirleyin (bu bölümün ilk 3’üdür - #1, 2, 3)

• Zaman tüketimini sıklıkla karşılaştırın

• Sorgunun bölümünün altındaki ortalama yürütme süresine bakın (toplam süre / sıklık) (aşağıya bakın)

• Şu kalıpları arayın:

• Yüksek süre + Düşük sıklık = Verimsiz bireysel sorgular

• Yüksek süre + Yüksek sıklık = Potansiyel olarak verimsiz ancak yoğun kullanılan sorgular

3. Sıklık Analizi: Sıklık ve Plan-Sıklık

Sorguların ne sıklıkta çalıştığını anlamak için sıklık analizini kullanın. Bunu, belirli bir yolun yoğun saatlerde kaç kez kullanıldığını saymak gibi düşünün.

Sorgular parametrelendirilmemişse, yani parametre yer tutucusu (:myparam1) yerine SQL metninde açıkça parametre değerleri içeriyorsa, en yüksek sıklığa sahip sorguları belirlemek için "Plan-Özet" bölümünü kullanmak gerekir.
Parametrelendirilmemiş sorgu örneği: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Parametrelendirilmiş sorgu örneği: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Sıklık Etkisini Anlama

Sıklık sorgu kalıbının temsili Plan/Zaman Özeti’ne çok benzer:

Yüksek sıklıklı sorgular yoğun kavşaklar gibidir - her araba (sorgu) hızlı hareket etse bile, hacim tıkanıklığa neden olabilir. Bu şunları etkiler:

• Veritabanı bağlantıları (park yerleri gibi - sayıca sınırlıdır)

• Ağ bant genişliği (yol kapasitesi gibi)

• CPU kullanımı (trafik kontrolörlerinin aşırı yüklenmesi gibi)

• Önbellek verimliliği (aynı bilgiye tekrar tekrar erişmek zorunda kalmak gibi)

Yüksek frekanslı sorguların etkisini tahmin etmek için parametre eşiği = 0 olan izleme toplayın.

3.2. Frekans Etki Kategorileri

3.3. Örnek Analiz

İzleme raporumuzdan gerçek bir durumu inceleyelim:

Frekans: 4.428 çalıştırma (toplamın %24,43'ü)
Etki: Kritik - yüksek hacimli SALES tablosu sorguları
Kök Neden: Tekrarlayan müşteri bakiye kontrolleri
Optimizasyon Önceliği: Yüksek

Açıklama: Bu sorgu binlerce kez çalışıyor, yoğun bir
kavşak gibi. Her çalıştırma hızlı olsa bile, kümülatif
etki önemlidir. Uygulama bakiyeleri gereğinden sık kontrol ediyor olabilir.

4. xx-Özet ve Frekans bölümlerinde en iyi sorguların istatistiklerinin analizi

Firebird izleme raporlarını analiz ederken, her sorgu grubu, performans desenleri hakkında önemli bilgiler sağlayan ayrıntılı toplu istatistikler içerir. Her metriği parçalayalım ve veritabanı optimizasyonu için önemini anlayalım.

4.1. Toplu İstatistik Analizi

Bu örnek istatistik setini inceleyelim:

Toplam: 4428 öğe:
Süreler: min: 351; maks: 3919; ort: 457.70; medyan: 455.00; toplam: 2026710 (%20.29);
Getirmeler: min: 7135; maks: 7168; ort: 7146.86; medyan: 7147.00; toplam: 31646289 (%0.75);
Yazmalar: min: 0; maks: 0; ort: 0.00; medyan: 0.00; toplam: 0 (%0.00);
Okumalar: min: 0; maks: 6995; ort: 3.13; medyan: 0.00; toplam: 13856 (%8.22);
İşaretler: min: 0; maks: 0; ort: 0.00; medyan: 0.00; toplam: 0 (%0.00);
1 benzersiz adresten: TCPv6:::1 (4428)

4.2. Çalıştırma Sayısı Analizi

4.2.1. Toplam Öğeler

Toplam: 4428 öğe

Bu, izleme dönemi boyunca bu belirli sorgu deseninin kaç kez çalıştırıldığını temsil eder.

Bu sayıyı anlamak şunları yapmanıza yardımcı olur:

• Çalıştırma başına kaynak kullanımını hesaplayın

• Sorgu önbelleğe almanın faydalı olup olmayacağını belirleyin (veya daha az sıklıkta çalıştırın)

Yüksek çalıştırma sayıları şu fırsatları gösterebilir:

• Hazırlanmış ifadeler (ve parametreli) uygulama - aynı sorgu aynı sıklıkta, parametreli ve tekrarlayan çalıştırma için hazırlandığında daha az kaynak gerektirir

• Sonuç önbelleğe alma ekleme - uzun işlem sırasında veya daha da uzun süre, kullanıcının oturumu boyunca kullanılmak üzere sonuç değerini önbelleğe almak, sorguyu sık çalıştırma ihtiyacını azaltabilir

• Toplu işlemler - aynı anda birçok kaydı döndürmek veya işlemek için sorguyu çalıştırmayı düşünün, bu sorguyu çalıştırma ek yükünü (hazırlama, ağ iletimi vb.) ortadan kaldırır.

4.3. Süre Metrikleri

4.3.1. Süre Bileşenleri Örneği

Süreler: min: 351; maks: 3919; ort: 457.70; medyan: 455.00; toplam: 2026710 (%20.29);

4.3.2. Süre Analizi

• Yakın medyan ve ortalama (457.70 vs 455.00 ms) tutarlı performans gösterir

• Maks/min oranı (~11x) bazı değişkenlikleri gösterir

• Toplam sürenin %20.29’u önemlidir - bu sorgu Frekans veya Plan-Frekans bölümünde ilk 3’te mi? (evet, öyle.)

4.4. Kaynak Kullanım Metrikleri

4.4.1. Getirme İşlemleri

Getirmeler: min: 7135; maks: 7168; ort: 7146.86; medyan: 7147.00; toplam: 31646289 (%0.75);

Getirmeler satır alımlarını temsil eder:

• Tutarlı getirme sayıları (min/maks farkı sadece 33) istikrarlı sonuç kümeleri gösterir

• Nispeten yüksek getirme sayıları (çalıştırma başına >7000) şunları gösterebilir:

• Çok sayıda kayıt döndürülüyorsa, sonuç kümesi sınırlama ve/veya sayfalama ihtiyacı.

• Sorgu optimizasyonu potansiyeli - özellikle sorgu Frekans/Plan-Frekans ilk 3’ündeyse mantıklıdır.

4.5. Okuma İşlemleri

Okumalar: min: 0; maks: 6995; ort: 3.13; medyan: 0.00; toplam: 13856 (%8.22);

Fiziksel okumalar disk erişimini gösterir:

• Sıfır medyan, sıfır olmayan maksimum ile ara sıra önbellek ıskalamalarını gösterir

• Toplam okumaların %8.22’si orta düzeyde I/O etkisi gösterir

• Min (0) ve maks (6995) arasındaki büyük fark değişken önbellek etkinliği gösterir.

4.6. Yazma İşlemleri

Yazmalar: min: 0; maks: 0; ort: 0.00; medyan: 0.00; toplam: 0 (%0.00);

Sorgu hiç yazma yapmıyorsa, genellikle salt okunur bir işlemdir.

4.7. İşaretleme İşlemleri

İşaretler: min: 0; maks: 0; ort: 0.00; medyan: 0.00; toplam: 0 (%0.00);

İşaretleme işlemleri veri sayfası önbellek yönetimiyle ilgilidir:

• Sıfır işaret, temizleme için işaretlenmiş veri sayfası olmadığını gösterir, basit SELECT sorguları için yaygındır

• Sıfır olmayan işaretler önbellek ile işlem

4.8. İstemci Bağlantı Analizi

1 benzersiz adresten: TCPv6:::1 (4428)

Bu, sorgu kaynak dağılımını gösterir:

• Tek istemci adresi uygulamaya özel sorgu olduğunu gösterir

• Yerel bağlantı (::1 IPv6 localhost’tur)

• 4428 çalıştırmanın tamamı aynı kaynaktan

4.9. Optimizasyon İçin Bu Metrikleri Kullanma

4.9.1. Performans Deseni Analizi

Çalıştırma Tutarlılığı

• Min/maks sürelerini karşılaştırın

• Kaynak kullanımında aykırı değerleri arayın

• Değişkenlik için medyan ve ortalamayı kontrol edin

Kaynak Kullanım Desenleri

• Yüksek getirmeler → Sonuç kümesi boyutunu gözden geçirin

• Yüksek okumalar → İndeks kapsamını kontrol edin

• Yüksek işaretler → Kilit çakışmasını inceleyin

İstemci Etki Analizi

• Birden fazla istemci → Bağlantı havuzu boyutlandırma

• Tek istemci → Uygulama optimizasyonu

4.9.2. Optimizasyon Öncelikleri

Bu metriklere dayanarak şunlara öncelik verin:

• Sonuç Kümesi Boyutu

• Çalıştırma başına 7000 getirme

• LIMIT/OFFSET eklemeyi düşünün

• SELECT sütun listesini gözden geçirin

Önbelleğe Alma Stratejisi

• Sık çalıştırma (4428 kez)

• Tutarlı sonuç boyutu

• Yazma içermez

Muhtemelen, bu sorgu daha az sıklıkta çalıştırılabilir.

İndeks Kullanımı

• Değişken okuma sayıları

• Sıfır medyan okumalar ancak yüksek maksimum

• İndeks kapsamını gözden geçirin

5. Pratik Uygulama

Bu özel örnek için:

Kısa Vadeli İyileştirmeler:

• Sonuç önbelleğe alma uygulayın (yüksek çalıştırma sayısı, tutarlı getirmeler)

• Sonuç kümesi boyutunu gözden geçirin (çalıştırma başına >7000 getirme)

Orta Vadeli Optimizasyon:

• İndeks kullanım desenlerini analiz edin

• Hazırlanmış ifade kullanımını düşünün

• Çalıştırma sıklığı için uygulama mantığını gözden geçirin

Uzun Vadeli Hususlar:

• Zaman içinde çalıştırma desenlerini izleyin

• İndeks bakım stratejisi planlayın

• Veri erişim deseni değişikliklerini düşünün

6. Süre Analizi

Süre analizi, bireysel sorguların çalışmasının ne kadar sürdüğünü inceler. Süreyi her sorguyu zamanlayan bir kronometre gibi düşünün - bir sorgu ne kadar uzun sürerse, performans sorunlarına neden olma olasılığı o kadar artar.

6.1. Süre Metriklerini Anlama

Süre metrikleri çok önemlidir çünkü kullanıcı deneyimini doğrudan etkiler, yani kullanıcılar “sistem yavaş” der. Müşteriler uzun kuyrukta beklemekten hayal kırıklığına uğradığı gibi, kullanıcılar da sorguların tamamlanması çok uzun sürdüğünde hayal kırıklığına uğrar. Uzun süren sorgular şunlara neden olur:

• Ekranların yüklenmesi çok uzun sürdüğünde kötü kullanıcı deneyimi

• Sistem kaynaklarının uzun süre meşgul edilmesi

• Diğer sorguların yavaş olanların arkasında sıraya girmesi

• Uygulamalarda potansiyel zaman aşımı sorunları

6.2. Etki Kategorileri

6.3. Örnek Analiz

Süre: 77.793ms
Etki: Kritik - tek sorgu 77,7 saniye tüketiyor
Kök Neden: PRC_COLLECT_RANKCATEGORY içinde karmaşık toplama
Optimizasyon Önceliği: Acil

Açıklama: Bu sorgu bir dakikadan fazla sürüyor, bu da
tam bir trafik durması gibi. Saklı yordam muhtemelen
çok fazla veri işliyor veya verimsiz algoritmalar kullanıyor.

7. Uygulama Stratejisi

Optimizasyonu bir ulaşım sistemini iyileştirmek gibi düşünün - sorunları belirlemeniz, çözümleri planlamanız ve değişiklikleri dikkatlice uygulamanız gerekir.

7.1. Önceliklendirme Matrisi

Bu matris, bir şehirdeki trafik sorunlarını triyaj yapmak gibi, önce neyin ilgi gerektirdiğine karar vermenize yardımcı olur:

7.2. Adım Adım Optimizasyon Süreci

1. Kritik Sorguları Belirleyin

• En büyük trafik sıkışıklıklarını arayın (yavaş sorgular)

• En yoğun kavşakları bulun (yüksek frekanslı sorgular)

• Verimsiz rotaları tespit edin (yüksek kaynak kullanımı)

2. Yürütme Planlarını Analiz Edin

• Mevcut rotaları inceleyin (indeks kullanımı)

• Trafik desenlerini inceleyin (birleştirme yöntemleri)

• Darboğazları kontrol edin (sıralama işlemleri)

3. Optimizasyonları Uygulayın

• Yeni yollar inşa edin (indeksler)

• Rotaları yeniden tasarlayın (sorguları yeniden yapılandırın)

• Kısayollar ekleyin (önbelleğe alma)

4. İyileştirmeleri Doğrulayın

• Yeni trafik akışını ölçün (yeni izleme raporu)

• Önce/sonra metriklerini karşılaştırın

• Ne işe yaradığını belgeleyin

Herhangi bir sorunuz için IBSurgeon ile iletişime geçin

Herhangi bir sorunuz için bizimle iletişime geçmekten çekinmeyin: [email protected].