IBAnalyst: Özet Görünümünde neler görebilirsiniz

Dmitry Kuzmenko, son güncelleme 31-03-2014

Özet

Bu belge, IBAnalyst’ın “Summary view” sayfasındaki bilgilerin açıklanmasına ve bu bilgilerin kendi veritabanı istatistikleriniz için nasıl yorumlanacağına ayrılmıştır. Ayrıca, tüm InterBase istatistiklerinin inceliklerini öğrenmenizi kolaylaştırmak için kurulum paketine birkaç örnek istatistik ekledik. Bunlar, IBAnalyst kurulumunun Examples dizinindedir.

Oldest transaction, Oldest snapshot, active ve Next’in ne olduğunu bilmiyorsanız, lütfen önce Craig Stunz’ın “Understanding Transactions Lifetime” makalesini okuyun:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Transaction numaraları

Understanding Transaction Lifetimes makalesini okuduysanız, OIT/OST/OAT numaraları hakkında hâlâ sorularınız olabilir. İşte kısa bir açıklama:


Numaralar	Şunları tutar, …	Şu durumlarda ileri hareket eder, …
Oldest transaction	bu numaraya sahip transaction geri alındığında ve içinde çok sayıda veri değişikliği olduğunda veya istemci bağlantısı kaybolduğunda	otomatik veya manuel sweep başarılı olduğunda.
Oldest Snapshot	snapshot (veya IB 7.1’den önceki read committed write) uzun süre aktif olduğunda (en eski aktif snapshot’ı yerel OST olarak hatırladı)	yeni bir transaction başladığında, OST’yi tutan transaction sona erdiyse
Oldest Active	bu numaraya sahip transaction uzun süre aktif olduğunda	yeni bir transaction başladığında, OAT’yi tutan transaction sona erdiyse
Next	asla	yeni bir transaction başladığında

not: Buradaki Oldest transaction, birçok başka makalede bahsedilen Oldest Interesting Transaction (OIT) ile aynıdır.

Standart ayarlarla ince istatistikler

IBAnalyst’ı başlatalım ve (Statistics/Load statistics from file menüsüyle) !allok.txt dosyasını açalım.

IBAnalyst yalnızca veritabanı oluşturma tarihini bildirmekle kalmaz, aynı zamanda istatistikler Services API aracılığıyla alındıysa sunucudaki geçerli tarih/saati veya yüklenen bir istatistik dosyasıysa dosya tarih/saatini de tanır.

Bu yüzden istatistik dosyalarını değiştirmemenizi öneriyoruz, çünkü bu durumda IBAnalyst günlük ortalama transaction sayısını yanlış hesaplayacaktır. Buradaki günlük transaction satırı, günde yaklaşık ~12500 transaction olduğunu ve bu veritabanının oluşturulmasından veya geri yüklenmesinden itibaren 8 gündür “yaşadığını” gösterir.

Oldest, Oldest snapshot, Oldest active ve Next transaction’lar burada mükemmel durumda; istatistiklerinizin her zaman böyle görünmesini dileriz.

Çok sayıda aktif transaction

Şimdi !lotofactive.txt dosyasını açalım (karşılaştırma için istediğiniz zaman !allok resmine geri bakabilirsiniz).

Burada Active transactions satırı kırmızı olarak işaretlenmiştir, çünkü Oldest active ve Next transaction arasında büyük bir fark vardır. Bu, istatistiklerin alındığı anda bazı transaction’ların hâlâ aktif olduğu ve başlangıcından sonra 55.000 transaction’ın başladığı anlamına gelir (bunlar herhangi bir durumda olabilir - aktif, commit edilmiş, geri alınmış). Günlük ortalama transaction sayısı ~12500 olduğundan, IBAnalyst size bazı transaction’ların 4,4 gündür yaşadığına dair bir uyarı gösterir. Bu şu durumlarda olabilir:

bazı uygulamalar hâlâ çalışıyor ve en az bir transaction açık - bazı kullanıcılar uygulamayı uzun süre açık tutuyor olabilir
uygulama uzun süre çalışıyor ve transaction tanıtıcılarını kaybediyor - yani kodunuz (veya kullandığınız bileşenler/kütüphaneler) dinamik olarak transaction başlatıyor ve bazı durumlarda bunları rollback veya commit ile sonlandırmayı “unutuyor”.
uygulamanız açık transaction kullanmıyor (BDE), transaction yönetimini kullanılan bileşenlere bırakıyor. Sonuç olarak transaction ömürleri uygulama tarafından kontrol edilmiyor ve Next-OAT transaction’larının çoğunun gerçekten aktif olduğundan emin olabilirsiniz.
uygulamanız “varsayılan transaction"a izin veren bir sürücü veya bileşen kullanıyor. Kodunuz bu transaction’ı kontrol etmiyorsa, çok uzun süre çalışabilir.

Üzülerek söylüyoruz ki, istatistikler şu anda aktif olan transaction’ların gerçek sayısını göstermez. Bu yalnızca InterBase 7.x’te IBConsole, IB Performance Monitor veya tmp$transactions geçici sistem tablosuna doğrudan sorgu ile görülebilir. Firebird 1.5’te isc_database_info’yu isc_info_active_transactions parametresiyle çağırabilirsiniz.

Sweeping

Şimdi !needsweep.txt dosyasını açalım.

Sweep, InterBase içindeki bir bakım sürecidir. Sweep, veritabanındaki tüm kayıtları tarar ve tüm eski sürümleri temizlemeye çalışır, ardından Oldest transaction numarasını yukarı taşımaya çalışır. Yeni oluşturulan bir veritabanında Sweep interval varsayılan olarak 20000’dir. Transaction’lar arasındaki fark (aşağıdaki tabloya bakın) sweep interval’den büyük olduğunda, sweep otomatik olarak çalışır. Böylece veritabanınızda periyodik performans düşüşleri görebilirsiniz. Örneğin, uygulamalarınız Pazartesi ve Salı günleri iyi çalışır, ancak Çarşamba günü kullanıcılar birkaç saat performans sorunları bildirir ve sonra performans tekrar iyi olur.

Benzer bir davranış görürseniz - bu otomatik sweeping’dir.


Sunucu sürümü	Sweep ne zaman çalışır
InterBase 7.x	(Oldest Active - Oldest) > Sweep interval
InterBase 4.x, 5.x, 6.x, Firebird 1.5.2’den önceki, Yaffil	(Oldest Snapshot - Oldest) > Sweep interval

Tablo 1. Otomatik sweep’in çalışma koşulları

not: IBAnalyst tüm sürümler için doğru Sweep gap bilgisini otomatik olarak gösterir. IBAnalyst sunucu uygulamaları arasındaki farkı yalnızca ODS kimliğiyle algılayabilir; örneğin, InterBase 7.x ODS 11.x’e sahiptir, diğer modern sunucular ODS 10.x’e sahiptir. Yalnızca Interbase 7.x veritabanlarıyla (ODS 11) çalışıyorsanız, Options iletişim kutusunda uygun seçeneği değiştirebilirsiniz.

Veritabanınızın sweep interval’i <> 0 olduğunda, IBAnalyst bu satırı temel olarak sarı işaretler (otomatik sweep’in öngörülemeyen bir anda başlayabileceği konusunda sizi uyarır). Genel olarak, tüm uygulamaların %60’ı otomatik sweeping ile ilgili sorunlar yaşar. Bu sorunu önlemenin en kolay yolu, sweep interval’i 0 olarak ayarlamaktır; bu, otomatik sweeping’in kapatılmasına yol açar. Ancak, bazı uygulamalar çok sayıda değişiklik yapıp sonra rollback yaparsa, Oldest transaction donar ve sweep çalışana kadar yukarı hareket etmez. Etkin transaction durumu Oldest’ten Next transaction’a kadar hesaplandığından, bu mesafe büyür ve performans düşer. Bunu önlemek için sweep’i manuel olarak çalıştırmalısınız (gfix -sweep). Bu resimde, sweep interval’in 0 olduğu ve büyük bir transaction’ın geri alındığı davranışı görebilirsiniz:

Burada sweep gap değeri, büyük (çok sayıda değişiklik yapan) bir transaction’ın yaklaşık 4,5 gün önce geri alındığını gösterir. Her gün sweep’i manuel olarak çalıştırmanızı öneririz.

Elbette, bahsedilen %60 uygulama için sweep interval’i 20000’den büyük veya küçük ayarlamak daha iyi olabilir, ancak bu birçok faktöre bağlıdır (günlük transaction bunlardan biridir, örneğin) ve yalnızca deneysel yolla anlaşılabilir. Bu nedenle, Sweep interval’i 0 olarak ayarlarsanız, sweep’in öngörülemeyen bir anda otomatik olarak çalışmayacağından emin olabilirsiniz.

Aynı resmi !rollback.txt dosyası için de görebilirsiniz.

not: Sweep otomatik olarak çalışıyorsa, büyük bir veritabanı veya çok sayıda eski kayıt sürümü olan bir veritabanı için Snapshot, Active ve Next transaction’lar sweep çalışırken ileri hareket edebilir ve sweep en yakın transaction başlangıcında tekrar başlayabilir.

Sweep’in işini yapamadığı durumlar

Sweep’in Oldest transaction’ı daha yükseğe taşıyamadığı birçok durum vardır. Elbette, sweep önce işini yapmaya çalışır, yani veritabanındaki tüm kayıtları kontrol eder ve gereksiz kayıt sürümlerini toplar. Ancak aşağıdaki durumlarda tekrar tekrar başarısız olarak çalışacaktır:

sweep çalışırken bir sorun oluştu: sweep sırasında sunucu durduruldu veya eski kayıt sürümü temizliği sırasında bir hata oluştu. Ayrıca, bu resmi şu durumlarda görebilirsiniz:

istatistikler sweep çalışırken alındı
sweep çalışıyor ve sürekli güncellenen bir tablo için eski sürümleri toplamaya çalışıyor. Bu, güncellemeler bitene kadar sürebilir.
sweep, çok sayıda kullanıcı veriyle çalıştığı için sayfa kilitlerinde takılı kaldı.

Genel olarak, sweep’in yüksek veritabanı yükü sırasında bitirme şansı yoktur. Genellikle performans normal çalışmaya devam etmeyi imkânsız kılacak şekilde düştüğünde, DBA sunucuyu yeniden başlatır ve sweep ilk kullanıcı bağlantısında çalışır. Diğer kullanıcılar bağlanana kadar biraz zaman olacağından, sweep işini bitirmek için zaman bulacaktır.

InterBase 7.1/7.5, Sweep gap’i önceki sürümlerden farklı hesapladığından, sweep’in işini yapamadığı diğer durum, bazı uygulamaların uzun süre çalışan snapshot transaction’ına sahip olmasıdır:

Burada iki uyarı vardır - biri (sarı) uzun süre çalışan snapshot hakkında, diğeri (kırmızı) Sweep interval ve Sweep gap hakkında.

Uzun süre çalışan snapshot

Önceki resim, InterBase 7.1/7.5’te uzun süre çalışan snapshot’ı gösterir. Sweep interval 0 olarak ayarlanmış olsaydı, kırmızı uyarılar olmazdı, sadece sarı olurdu. Benzer bir resim, diğer Interbase, Firebird ve Yaffil sürümlerinde uzun süre çalışan snapshot transaction’ını gösterecektir:

Gördüğünüz gibi, burada Sweep gap, Oldest Snapshot ve Oldest transaction farkıyla hesaplanır (ODS 10, IB 7.x öncesi sürümler için). Yani sweep uyarısı yoktur (varsayılan sweep interval dışında).

Ancak, yalnızca snapshot transaction’ları transaction durumunu bu şekilde etkilemez. InterBase 7.1/7.5 dışındaki tüm InterBase, Firebird ve Yaffil sürümleri, “read committed artifact” olarak adlandırdığımız aşağıdaki davranışa sahiptir.

Snapshots tekrar ve ReadCommitted’ın Oldest Snapshot’ı dondurduğu durumlar

!snapshot2.txt dosyasını açalım:

Oldest transaction’ın Oldest snapshot’tan büyük olduğuna dikkat edin. Ve Sweep gap negatif bir değere sahiptir. Bu iki durumda olabilir. İlk durum, bazı snapshot transaction’larının birbiri ardına başlayıp commit edilmesidir. Yani bu resim, önceki resim gibi snapshots ile de olabilir. Sonraki durum yalnızca IB 7.1/7.5 dışındaki sunucularda ReadCommitted transaction’larıyla (veya ReadCommitted ve Snapshot transaction’larının kombinasyonuyla) oluşur. Bunlar, Oldest Snapshot numarasını Snapshot transaction’ları gibi kilitleyebilir. Geçerli transaction durumu aşağıdaki sırayla simüle edilebilir:

transaction 1’i başlat, snapshot veya read_committed
bazı read_committed transaction’ları başlat/commit et
transaction 2’yi başlat, snapshot veya read_committed
bazı read_committed transaction’ları başlat/commit et
transaction 1’i commit et

(elbette, burada read_committed write transaction’larından bahsediyoruz, salt okunur değil).

Bu noktada, snapshot 1’den sonra başlayan (madde 3) şu anda aktif olan transaction 2 (snapshot veya read committed), snapshot numarasını Oldest Snapshot olarak tutacaktır (IB 7.1/7.5 ile çalışıyorsanız bu yalnızca eşzamanlı snapshot transaction’ları için olabilir. read_committed veya read_committed+snapshot bu etkiyi üretmez). Büyük rollback’ler olmadığından, Oldest transaction ileri hareket eder ve Oldest Snapshot’tan büyük hale gelir.

Şimdi, uzun süre çalışan read committed transaction’ınız varsa, böyle bir resim görürsünüz. Üzülerek söylüyoruz ki, uygulamalarınızla burada yapabileceğiniz hiçbir şey yoktur (salt okunur transaction’lar için “read” parametresi eklemek dışında). Ve elbette, bu durumda sweep otomatik olarak çalışmayacaktır (<> 0 olarak ayarlanmışsa).

not: bu davranış Firebird 2.0’da düzeltilecektir

Mutlak ve göreli görünümler

Varsayılan olarak IBAnalyst, transaction satırlarını mutlak değerlerinin yüzdesine göre doldurur. Yani %100, 0’dan Next transaction’a kadardır. Bazen, veritabanı uzun süre çalıştığında transaction bilgisini şu şekilde görebilirsiniz:

Çok sayıda transaction varken, snapshot, active ve oldest arasındaki fark çok küçük görünür (%98’e yakın). Durumu daha net hale getirmek için Options iletişim kutusunu açın, Transactions sekmesine gidin ve “Relative (from oldest) bars %” seçeneğini işaretleyin (eski tarz görünüm kullanıyorsanız, grafik çubukları olmadan bu onay kutusunu ayarlayamazsınız). OK düğmesine bastıktan sonra transaction görünümü şu şekilde değişecektir:

Artık işlem farkını göreli görünümde görüyorsunuz (%100, 0’dan değil, En Eski (veya anlık görüntü) işleminden Sonrakine kadardır). Mevcut durumu anlamak ve uyarıları (varsa) görmek daha kolaydır.

Bu görünüm, Options iletişim kutusunda işaretini kaldırana kadar devam eder. Hangi görünümü gördüğünüzü En Eski İşlem veya En Eski Anlık Görüntü satırından anlayabilirsiniz - göreli görünümde bu satırlardan biri asla yeşil renkle doldurulmaz. Mutlak görünümde ise her zaman (tabii ki kısmen) doldurulur.

Hâlâ sorularınız mı var? Bize [email protected] adresinden ulaşın.