Firebirde zaman içinde yavaşlama

[serbek_tr]

Merhaba arkadaşlar;
Şu an kullanımda olan ciddi bir projem var. Az buz değil içinde sürekli belge tutulan bir yapısı var. Günlük nerden baksanız 2000 e yakın kısa yada uzun text veri giriliyor. Her yıl başında boş veri tabanı ile devam edip eskisinin yedeğini alıyoruz. 150 civarı kullanıcı var. Veri tabanındaki dökmanlarda sürekli arama tarama ekleme değiştirme yapılıyor. Gün içinde çok aktif kullanılan bir sistem. Yılda kayıt sayısı 1.000.000 olabiliyor veri uzunluğuna göre veritabanı boyutu 2 GB tı geçmedi. Ancak 1-2 ay içinde gözle görülür şekilde kat kat yavaşlık söz konusu oluyor. Bunuda backup restore yaptığımda aşıyorum. Bu yavaşlığın sebebi ne olabilir. Tavsiye ve çözümlerinizi bekliyorum teşekkür ederim.

[Kuri_YJ]

Selamlar,

İşlem yaptığınız DB'deki tabloların dikkat edilmesi gereken özellikleri var. Örneğin, belge mi giriyorsunuz? Belgeler BLOB alanda mı duruyor, yoksa varchar tanımlı alanlarda mı? Backup-Restore yapıldığında toparlıyor diyorsunuz. Bu da Sweep Intervaliniz ile ilgili bir şey olma olasılığı demektir. Ayrıca alanlar indexli mi? Indexli ise, index selectivity için Re-Calculate filan yaptınız mı hiç? Ya da yaparak denediniz mi?

Kullanılan Server ve Konfigürasyonu nedir? Memory'si, kullandığınız İşletim sistemi? FB Versiyon? vb. vb. vs. vs.

Performansı etkileyen, görüldüğü üzere pek çok nokta var. Bunları biraz daha açarsanız yardımcı olmaya çalışırız.

Kolay Gelsin

[serbek_tr]

Belgeler BLOB alanlarda saklı, Blob alan haricindeki hemen hemen tüm alanlar indexli tabi bu indexleri aramalarda kullandığım alanlara göre yaptım, örneğin oluşturulma değiştirilme tarihi ve buna benzer diğer alanlar için indexler tanımlı.

"index selectivity için Re-Calculate" demişsiniz açıkçası bunun nereden ve nasıl yapıldığını bilmiyorum. Kullandığım DB Aracı EMS SQL Manager ve burda bu işlemin nasıl yapıldığını bilmiyorum yada göremedim şu ana kadar. bu konuda da ayrıca bil verirseniz sevinirim.

Server konfigürasyonu iyi sayılır, en azından ben yettiğini düşünüyorum.İyi bir işlemci ve 4GB Ram'i var. Ve bu Makina sadece bu iş için çalışıyor başka herhangi amaca hizmet etmiyor.

İşletim sistemi MS W2003 Server.
FireBird sürümü 2.1.3.18185

Fikir yürütmeniz konusunda belki yardımı olur ayrıca belirtmek isterim. Veri tabanı işletim sisteminden ayrı disk üzerinde duruyor ve diski formatlar iken küme boyutunu 4096 verdik aynı şekilde performans açısından daha verimli olsun diye de Veri tabanını oluşturunca page size olarak ta 4096 değerini verdim. Her restore olayında aynı değeri vermeye de devam ediyorum.

Veri tabanı dosyasının uzantısı GDB ve bildiğim kadarı ile bu windows sitemlerde sorun çıkarıyormuş. Yine burda okumuştum sanırım sistem geri yüklemeyi kaldırırak bu sorun aşılıyormuş. Sistem geri yükleme kapalı şu anda.

Bu arada veritabanı uzantısını değiştirmek için restore ederken bunun FDB olacağını belirtmem yeter mi yoksa illaki yenide create etmem mi gerekir diye bir soru sormuş olayım

Bu arada sistem belge yönetimine dair olduğundan database de her an insert yada edit olayları sürekli gerçekleşiyor. Sistemin kullanıldığı yerde ki ağ bağlantılarında ki kopmalar buna sebep olabilir diye düşündük ve bu konuda iyileştirme yapmalarını istedim. Mümkün olduğunca yapıldı. Açıkçası işlerin düzgün yürümesi açısından hiç birşeyden kaçınmayacak bir zihniyete sahipler bu konuda gerekeni yaptıklarını söylüyorlar bence de doğrudur. Yani bu ihtimali ben çoktan gözden çıkardım.

Dosya boyutu şu an itibari ile 1.9 GB tan fazla, deneme amaçlı backup aldım ve restore ettim restore sonucu 1.87 GB. Bahsettiğim yavaşlama sorunu olduğu zaman genelde restore işleminden sonra en az 400 Mb civarı bir küçülme olur. 600 Mb küçüldüğü zamanlar oldu. Şu an bir yavaşlık yok ve restore dan sonra ki küçülmede az.

Sizinde aklınıza gelebilecek bir çok ihtimale şimdiden cevap vemeye çalıştım. İlginize teşekkür ederim. Çok sağ olun.

Kolay Gelsin...

[Kuri_YJ]

Selamlar,

Birkaç tavsiye,

firebird.conf dosyası ile alakalı yazdıklarımı bir gözden geçirin. Sistem 24 Saat ayakta kalıyor ise Cache Page'lerin değerleri ile oynama yapabilirsiniz. Ek olarak Database Sweep Interval'inizi düşürün. Şu anda muhtemelen yüksek bir seviyededir. Default olarak 20,000'dir. Ancak siz onu mesela 10,000'e filan düşürün. Sweep Interval'ı da araştırın. Backup Restore yapmak zorunda kalmayın. Uzun süren Query'lerinizi inceleyin ve ihtiyaç duyulacak Indexleri bir daha gözden geçirin.

Indexlemelerle ilgili yazdığım bir yazı vardı onu okudunuz mu bilmiyorum ama ona da bir göz atın. Performans ve Index ile alakalı yazdıklarıma bakın.

firebird.conf dosyasındaki CPUaffinity ve dbchachedpages değerleri sizin işinize yarayacaktır.

Kolay Gelsin

[Kuri_YJ]

Tekrar Selam,

Ben Veri Tabanı yönetimi için, DBWorkbench kullanıyorum. Firebird için Free Lite edition'ı var. Ancak ben Pro'yu şahsıma satın aldım. Çok güzel bir tool, programcılar düşünülerek tasarlanmış olduğundan pek çok aradığınız yardımcı nitelikte işlev var. DBWorkbench'de Maintenance bölümünde sizin adınıza Re-Compile Procedures gibi, Re-Calculate Index Selectivity gibi özellikleri yapıyor.

Ben oradan yapardım ama EMS'de nerededir var mıdır bilmiyorum. Ama mutlaka bu iş için bir SQL komutları vardır. Onları bir araştırın.

Kolay Gelsin.

[AhmetNuri]

Selam, bende uzun yıllardır firebird veri tabanı ile uğraşıyorum. Fakt veri tabanlarım sizin ki kadar büyük değil. Sorulardan bazılarını cevplıyım.
gdb yi fdb yapmak için restore yeterli . yeni yayınlanan firebird 2.5 i deniyebilirisin. özellikle düşük seviyeli senkrenisasyon yapıyorsan ve sql kodu ile kullanıcı ekleme silme filan yapman gerekirse.
page size ı ben en yüksekte tutuyorum. ama benim dbler ufak. ayrıca buradaki analizler işine yarıyabilir. firebird de 1 tb data ile bazı değeleri veriyor
http://www.ibsurgeon.com/articles/item104

[emin_as]

Performance ilgili sorunlar iki yönlü ele alınmalıdır.
1- Server tarafında: page size, bufferler vs gibi firebird.conf dosyasında yapılacak ayarlarla, en iyi server performansı saglanabilir.
Aşagıdaki linkte bu konuda yapılabilecekler listeleniyor.
http://www.firebirdfaq.org/cat6/

2- Client tarafında: delphi ile yazılmış programda kullanılan bileşenler ve bu bileşenleri kullanma şekli performansı dogrudan etkileyecektir.
Örnegin recordcount veya last gibi dataset fonksiyonlarının çagrılması tablodaki tüm kayıtların okunmasına neden olur ve bu nedenle sistem yavaşlayacaktır.
select * from tablo yerine, select alan1,alan2 from tablo where gerekli_sartlar gibi gerekli şartları saglayan ve gerekli alanlar listelenirse daha iyi performans elde edilebilir.
Bazı bileşen setleri datasetlerde okuma ve yazma için iki farklı transaction kullanarak daha iyi performans saglarlar.

Ayrıca programda tam olarak nerede yavaşlama yaşanıyorsa, o bölümdeki sql kodları ve yapılanlar mercek altına alınıp, incelenebilir.

[serbek_tr]

Arkadaşlar hepinize cevaplarınız için ayrı ayrı teşekkür ederim. Tüm tavsiyeleriniz ve konu araştırma önerilerinizi tek tek araştırıp deneyeceğim. Sorunlarımın devamında yada tavsiyelerinizle bir çözüme ulaştığımda çözüme nasıl ulaştığımıda yazarım.

Ayrıca emin_as arkadaşım sana 2. madde de yazdıklarına dair birşey söylemek isterim. Yazdıklarında haklısın dikkat edilmesi gereken ve performans için ayrıca düşünülecek ipuçları. Ancak ben bir konuya tekrar üstüne basa basa değinmek istiyorum. Kullanmış olduğum bileşenlerin, veya sorgularımın benim yaşadığım problem ile alakası olduğunu düşünmüyorum(Bunu bir ihtimal olarak görüyorsanız). Aynı sorgular ve bileşenler restore olayından sonrada aynı şekilde çalışmaya devam ediyor ve restore dan sonra performans ilk hali kadar iyi oluyor. Tabiki zaman içinde arama sorgularının sonuçlarının gelmesi zaman alıyor buda günlük 2000 civarı kayıt arttığını düşünürsek bence normal. Ben bu sorunu db 500mb ikende yaşıyorum 1.5gb ikende. Ben firebird kullanıyorum ama galiba administration kısmında baya bir eksiğim.

Konuyu ilk yazdığım kısımda da belirttim aslında sorun ortada restor yaparken restor dan önceki boyut ile sonra ki arasında büyük bir fark oluyor bu sorunu yaşadığım zamanlar. Çogu zaman deneme amaçlı backup restore yapıyorum sorun yok ikende, bu durumda önce ve sonrasında boyut farkı yok denecek kadar az oluyor zaten. Bu fazladan veri şişmesi asıl problem gibi görünüyor bence bu şişmeyi önlemek gerek ve bunun sebebini bilmiyorum.

Dediğim gibi hepinizin bu yöndeki tavsiye ve önerilerinizi tek tek araştırıp deneyeceğim. Ama bunun sonuçlarını görmek galiba bir kaç ayı bulacak.

Tekrar hepinize ilginizden dolayı teşekkür ederim...

[serbek_tr]

Tekrar Merhaba;

Bu arada Kuri_YJ, index ve performans ile ilgili yazınızı okudum. Benim indexleri oluştururken kurduğum mantık tavsiyelerine büyük çoğunlukla uyuyor. Sadece bir sorum olacak. Ben genelde bir index içinde birden çok alanı tanımlamaktan kaçınırım. Yani müşteri no için index ayrıdır, şirket kodu için ayrıdır.
Ama Farklı şirket şirket kodlarının ama aynı müşteri nolarının olabileceği yapılar( A şirketi ABC müşterisi, B şirketi ABC müşterisi) aynı index içinde uygun birden fazla alan kullandım.

Yani sadece şirket kodu, müşteri no suna göre ayrı ayrı sorgulama yaptığım halde bu iki alanı tek tek ayrı indextemi tutmalı yoksa tüm indexlenebilecek alanları tek indextemi tutmalı. Bu konuda görüş ve taviyenizi almak isterim. Teşekkür ederim.

[emin_as]

Yedekleme sonrası performans düzeliyorsa, transaction yönetiminle ilgili sorunlar var demektir.
Aşagıdaki sitede bulunan transaction logger i yükleyip, veritabanını izle, eger fazla transaction görüyorsan, bunları düzeltmelisin.
http://blog.upscene.com/thomas/index.ph ... ategory=12

Hangi bileşen setini kullandıgını yazmamışsın, ibdac veya fibplus gibi bileşen setlerinde read ve write için ayrı transactionlar kullanılabiliyor. IBX tek bir transaction kullanıyor. Eğer transactionlar uzun süre açık tutulursa veritabanı şişer. Sql kodları çalışırken, şişen veritabanı yüzünden, işlemler daha fazla zaman alır.

[Kuri_YJ]

Selamlar,

Aramalarda birleşik Alanlardan oluşan index oluşturursanız, FB onu kullanır.

Yani WHERE ADI ='ADNAN' AND SOYADI = 'ÖNCEVARLIK' olarak bir sorgu için TBL_MUSTERI tablosunda eğer ADI ve SOYADI'ndan oluşan bir indexiniz varsa, FB bunu kullanır. Eğer yok ise, Yani ADI alanı bir index ve SOYADI alanı bir diğer index ise FB onu da kullanır. Yaniş her ikisinde JOINED bir index mantığıyla oluşturup sorgusunu çeker.

Ama sıklıkla ADI ve SOYADI beraber bir sorgu çekiyorsanız, bu iki alanı içeren bir index tanımlamanız daha faydalı olacaktır. Bu sefer de şöyle bir durumla karşılaşıyorsunuz, SOYADI ve ADI şeklinde bir sorgu olursa ne olacak. Bunun gibi kombinasyonlar ortaya çıkmakta. Artık bu durumda da olabilecek ihtimallerde en fazla hangisi daha az zaman yiyecekse, ona göre indexlerinizi oluşturursunuz.

Bundan da ötede bir sorun var ki, bu şekilde kombine edilmiş alanlarla bir bakmışsınız ki, tablonuzdaki neredeyse bütün alanlar için indexler oluşmuş. Bu bir sorun mudur? Duruma göre evet duruma göre hayır.

Yani otomatik kayıtların oluşturulduğu bir mekanizmada, 25 tane index olduğunu var sayarsak, her kayıt INSERT/UPDATE'inden sonra ilgili indexler de güncellenmek zorunda. Bu da hız kaybınızı oluşturur. Otomatik olarak ard arda kayıt atarken buradaki performansınız düşer. Ama Kullanıcı ekranı açıp bir sürü alan doldurup kaydet tuşuna bastığı bir durumda bu o kadar da problem teşkil etmez. Yani kullanıcı ekranı ne kadar hızlı kullanırsa kullansın 1 sn'lik bir gecikme onda bu kadar sorun oluşturmaz

Bu ada artık Performans Tuning işine girer Bu durumda da siz uygulamaya, işin niteliğine, ihtiyaçlara vs. gibi bir çok kriteri göz önünde bulundurup tercih yapacaksınız.

Umarım açıklayıcı olmuştur.

Kolay Gelsin

[serbek_tr]

Kuri_YJ ve Emin_as ikinize de çok teşekkür ederim.

Emin_as, bileşen olarak fibplus kullanıyorum, ayrı transaction olayını biliyorum ama açıkçası tek transaction kullanıyorum. Transaction lar açık kalmıyor. Tüm uygulamalarımda transactionları işlem yaptığım anda başlatıyor ve sonlandırıyorum yöntemim doğrumu bilmiyorum ama ufak bir örnek kod yazdım daha iyi bir mantık öneriniz olursa seve kulanırım.

Kod: Tümünü seç

procedure TfUrun.T_UrunAfterPost(DataSet: TDataSet);
begin
  with T_Urun do
  begin
    DM.TR.StartTransaction;
    try
      DurumMesaj('Ürün bilgileri kayıt ediliyor...');
      ApplyUpdates;

      DM.TR.CommitRetaining;
      fProcess.Close;
    except
    begin
      DM.TR.RollbackRetaining;
      RevertRecord;
      fProcess.Close;
      Mesaj('Uyarı','Ürün bilgileri kayıt edilirken beklenmeyen hata oluştu.',
      'ME','Tamam','','',True,False,False);
      raise;
    end;
    end;
    CommitUpdToCach;
  end;
end;

Tabi bu örnek bahsettiğim sorun yaşadığım uygulamamdan bir kod değil ama Query ler ile çalışıyorum ve CachedUpdates True çalışıyorum ve Query nin AfterPost, AfterDelete gibi Eventler ını kullanıyorum. Ve bildiğim kadarı ile Transaction başlatıldıktan sonra Commit veya Rollback komutlarından sonra transaction otomatik olarak sonlanır. Ayrıca bir transaction sonlandırma olayı yada yöntemi varmı ben bilmiyorum. Yardımlarınız için teşekkür ederim.

Kuri_YJ, Yazdıkların gayet açık ve net oldu çok teşekkür ederim. Ben bu yazdıklarından kendim için şu sonucu çıkardım. Tüm alanlara göre aynı anda yada seçilecek alanlara göre filtreleme sunduğum uygulamalarda, bu filtre seçenekleri içinde bulunan tüm alanları tek bir index içinde bulundurmam her bir alana göre ayrı ayrı index oluşturmamdan daha mantıklı . Tabi alanları en ayırt edici olana göre sıralamak şartıyla yani SIRKET_KODU alanını en başta tutmak gibi. (Doğru anlamışmıyım )

Çok teşekkürler.

Hepinize saygılar...