IBAnalyst: InterBase/Firebird veritabanından istatistikleri doğru şekilde nasıl alırsınız

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

Özet

Bu belge, IBAnalyst ile veya IBAnalyst olmadan InterBase/Firebird veritabanlarından istatistik toplama ve analiz etme ipuçlarına ve püf noktalarına ayrılmıştır.

Doğru zaman, doğru yer

Kulağa tuhaf geliyor, ancak yalnızca gstat veya Services API aracılığıyla istatistik almak yeterli değildir. İstatistikler, uygulamaların veritabanındaki verileri ve işlemleri nasıl etkilediğini göstermek için doğru zamanda alınmalıdır. İstatistik almak için en kötü zamanlar:

• Geri yüklemeden hemen sonra
• -g anahtarı olmadan yedekleme (gbak -b db.gdb) yapıldıktan sonra
• Manuel süpürme (gfix -sweep) sonrası

Ayrıca, çalışma sırasında veritabanının doğru durumda olduğu anlar olabilir; örneğin, uygulamaların normalden daha az veritabanı yükü oluşturduğu zamanlar (kullanıcıların başlangıcı, öğle yemeği veya belirli iş süreci saatlerine göre).

Veritabanında bir sorun olduğunu nasıl yakalarsınız?

Evet, uygulamalarınız o kadar mükemmel tasarlanmış olabilir ki her zaman işlemler ve verilerle doğru çalışır, süpürme boşlukları, çok sayıda aktif işlem, uzun süreli anlık görüntüler vb. oluşturmaz. Genellikle bu olmaz. En azından bazı geliştiriciler uygulamalarını aynı anda 2-3 eşzamanlı kullanıcıyla test ettikleri için, daha fazlasıyla değil. Bu nedenle, yazılmış uygulamaları 15 ve daha fazla eşzamanlı kullanıcı için kurduklarında, veritabanı öngörülemez davranabilir. Elbette, çok kullanıcılı mod iyi çalışabilir, çünkü çok kullanıcılı çakışmaların çoğu 2-3 eşzamanlı çalışan uygulamayla test edilebilir. Ancak, daha fazla eşzamanlı uygulama çalıştığında, en azından çöp toplama sorunları ortaya çıkabilir. Ve bu, istatistikleri doğru anlarda alırsanız yakalanabilir.

Periyodik performans sorunları yaşamıyorsanız

Bu, uygulamalarınız doğru tasarlandığında, düşük veritabanı yükü olduğunda veya donanımınız modern ve çok güçlü olduğunda (mevcut kullanıcı sayısını ve verileri iyi işlemek için yeterli) gerçekleşebilir.

En değerli bilgi, işlem yükü ve sürüm birikimidir. Bu yalnızca düzenli istatistik kaydetmeyi ayarlarsanız görülebilir.

InterBase dahili bir görev zamanlayıcıya sahip değildir, bu nedenle standart Görev Zamanlayıcı (Windows) veya cron (Unix) gibi herhangi bir harici zamanlayıcıyı kullanmakta özgürsünüz.

En iyi kurulum, saatlik işlem istatistikleri almaktır. Bu, aşağıdaki komut çalıştırılarak yapılabilir:

gstat -h db.gdb >db_stat_.txt

burada

db.gdb veritabanınızın adıdır,

db_stat_.txt istatistiklerin kaydedileceği metin dosyasıdır,

- istatistiklerin alındığı geçerli tarih ve saattir.

Periyodik performans sorunları yaşıyorsanız

Bu sorunlar genellikle otomatik süpürme çalıştırmasından kaynaklanır. Öncelikle bu tür performans düşüşleri arasındaki süreyi belirlemeniz gerekir. Ardından, bu aralığı en az 4’e (8, 16 vb.) bölün. Günümüzde bilgi sistemleri çok sayıda eşzamanlı kullanıcıya sahiptir ve yapılandırılmamış sunucu ve veritabanıyla ilgili performans sorunlarının çoğu günde 2 veya 3 kez meydana gelir. Örneğin, performans düşüşleri her 3 saatte bir oluyorsa, şunları almanız gerekir:

gstat -h db.gdb

istatistiklerini her 30-45 dakikada bir ve

gstat -a -r db.gdb -user SYSDBA -pass masterkey

her 1-1.5 saatte bir.

En iyisi, yaklaşan performans düşüşünden hemen önce gstat -a -r istatistiklerini almaktır. Gerçek çöpün nerede olduğunu ve kaç tane eski kayıt sürümünün biriktiğini gösterecektir.

Bu istatistiklerle ne yapmalı

Uygulamanız işlemleri açıkça kullanıyorsa ve bunları iyi kullanıyorsa, yani read_committed’in ne olduğunu ve ne zaman kullanılacağını biliyorsanız, anlık görüntü işlemleriniz gereğinden uzun sürmüyorsa ve işlemler minimum süre boyunca aktif kalıyorsa, süpürme aralığını ayarlayabilir veya kapatabilirsiniz ve ardından yalnızca uygulamanın (uygulamaların) kaç güncelleme yaptığını ve hangi tabloların daha az güncellenmesi veya güncellemelere dikkat edilmesi gerektiğini önemsersiniz.

Bu ne anlama geliyor, diye sorabilirsiniz? Her sabah 20-30 dakika performans sorunlarının yaşandığı bir sistem örneği vereceğiz. Bu, “sabah” uygulamaları için çok yeterliydi ve daha uzun süremezdi.

Veritabanı yöneticisine doğru sorular soruldu ve işte tablo:

Günlük iş bölümlere ayrılmıştı - analistler sabah çalışıyor, ardından veriler normal operatörler tarafından ekleniyor ve düzenleniyor ve günün sonunda özel prosedürler, ertesi gün (en azından) analistler tarafından kullanılacak verileri toplamaya başlıyordu.

Günün sonunda veritabanındaki son iş, çok sayıda güncelleme ve analistlerin sabah kullandığı tabloların güncellenmesiydi. Bu nedenle, sabah çalışan uygulama tarafından toplanmaya başlanan çok sayıda çöp sürümü vardı.

Ve bu sorunun cevabı basit bulundu - günün sonunda gfix -sweep çalıştırmak.

Süpürme, veritabanındaki tüm tabloları okur ve commit edilmiş ve geri alınmış işlemler için tüm çöp sürümlerini toplamaya çalışır. Süpürmeden sonra veritabanı, geri yüklemeden hemen sonraki kadar temiz hale geldi.

Ve “sabah sorunu” ortadan kalktı.

Bu nedenle, istatistikleri diğer birçok faktörle birlikte değerlendirmeniz gerekir:

1. Gün boyunca ortalama kaç eşzamanlı kullanıcı çalışıyor

2. Çalışma günü ne kadar uzun (8, 12, 16, 24 saat)

3. Günün farklı saatlerinde hangi tür uygulamalar çalışıyor ve aynı anda veya sonraki çalışan diğer uygulamalar tarafından kullanılan verileri nasıl etkiliyorlar. Yani, tüm gün ve tüm hafta boyunca gerçekleşen iş süreçlerini anlamalısınız.

DBA’nın hiçbir şey yapamadığı durumlar

Ne yazık ki, bu durumlar olur. Ve yine bir örnek:

~15 kullanıcı için kurulmuş bir sistem. Periyodik olarak performans o kadar kötü ki, DBA’nın sunucuyu yeniden başlatması gerekiyor. Sunucu yeniden başlatıldıktan sonra her şey bir süre iyi çalışıyor, sonra performans tekrar kötüleşiyor. İstatistikler, ortalama günlük işlem sayısının yaklaşık 75.000 olduğunu ve günün başlangıcından performansın düştüğü ana kadar aktif işlemlerin olduğunu gösterdi.

Ne yazık ki, uygulamalar BDE ile ve hiç işlem kullanılmadan yazılmıştı; yani tüm işlem yönetimi otomatikti ve BDE tarafından kullanılıyordu. Bu, bazı işlemlerin uzun süre aktif kalmasına neden oldu ve DBA sunucuyu yeniden başlatana kadar çöp (kayıt sürümleri) birikti. Yeniden başlatmanın ardından otomatik süpürme çalıştı ve çöp toplandı (ortadan kaldırıldı).

Tüm bunlara uygulamalar neden oldu, çünkü yalnızca 2-3 eşzamanlı kullanıcıyla test edildiler ve yaklaşık 15 kullanıcı olduklarında, uygulamalar çok yüksek yük oluşturmaya başladı.

Bu yapılandırmada kullanıcıların %70’inin yalnızca veri okuduğunu ve diğer %30’unun bazı (!) verileri eklediğini ve güncellediğini söylemek gerekir.

Bu durumda performansı iyileştirebilecek tek şey, uygulamaları tamamen yeniden tasarlamaktır.

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