sorgu zamanla yavaşlıyor.

[kgnonr]

projemde günlük ortalama 5000 kez çalışan şöyle bir procedure tanımlı. bu işlem ile veritabanında bulunan batch isimli tabloya veri işleniyor. fakat bu sorgunun her çalışmasından sonra bir sonraki sorgu yavaşlıyor. ilk başlarda gözle görülür bir fark olmamasına rağmen sorgu sayısı 3000'i geçtiğinde bariz bir yavaşlama ortaya çıkıyor ve buda programa (donmalar şeklinde) olumsuz yansıyor. program kapatılır açılırsa veya firebird server durdurulup yeniden başlatılırsa sorgu süresi normale dönüyor tabi zamanla yeniden donmalar başlıyor. konu hakkında yardımlarınızı bekliyorum. cevaplarınız için şimdiden teşekkür ederim.

proje delphi 2010 projesi. firebird 2.5 superserver kurulu ve database local olarak çalışıyor. fibplus 6.9 ile bağlantı sağlıyorum.
ibx ve ibdac ile yaptığım testlerde de aynı sorunu yaşadım.

Kod: Tümünü seç

procedure TForm1.WriteBatch(Silo:Byte;Value: Integer);
var
  ProductID:Integer;
  SiloName : String;
  SiloValue : Double;
  pQuery    : TpFIBQuery;
begin
  ProductId := tbProductPRODUCT_ID.AsInteger;
  SiloName  := 'SILO'+IntToStr(Silo)+'_RECEIVED';
  SiloValue := Value;

  pDatabase.Open();
  pTransaction.Active := True;

  pQuery    := TpFIBQuery.Create(nil);
  with pQuery do
  try
    Database := pDatabase;
    Transaction := pDatabase.DefaultTransaction;
    SQL.Text := 'UPDATE BATCH SET '+SiloName+' = '+StringReplace(FloattoStr(SiloValue),DecimalSeparator,'.', [rfReplaceAll])+' WHERE PRODUCT_ID = '+IntToStr(ProductId)+' AND BATCH_NO = 1';
    ExecQuery;
    Database.DefaultTransaction.Commit;
    pQuery.Close;
    pDatabase.Close;
  finally
    pQuery.Free;
  end;

  tbBatch.FullRefresh;
end;

[kgnonr]

konuyu biraz daha basite indirmek istedim.

kullandığım tablo şu şekilde

Kod: Tümünü seç

CREATE TABLE BATCH (
    BATCH_ID        INTEGER NOT NULL,
    PRODUCT_ID      INTEGER NOT NULL,
    BATCH_NO        INTEGER NOT NULL,
    SILO1_RECEIVED  NUMERIC(15,2) NOT NULL,
    SILO2_RECEIVED  NUMERIC(15,2) NOT NULL,
    SILO3_RECEIVED  NUMERIC(15,2) NOT NULL,
    SILO4_RECEIVED  NUMERIC(15,2) NOT NULL
);

delphi tarafında ibx seti ile database bağlantısını kuruyorum. (fibplus, ibdac, dbexpress ilede denemeler yapıp aynı sonuçları aldığımı ayrıca belirteyim.)

işlem şu : delphi ile yazılmış uygulamam, harici bir cihazdan veri topluyor ve topladığı verileri yukarıda belirttiğim tabloya yazıyor. bu cihazdan gelen bilgiler günde ortalama 5000 - 10000 civarı. buda tabloya günlük 5000-10000 arasında veri girmek demek. duruma göre insert veya update olabiliyor. şimdilik sadece günceleme için konuşalım. tablodaki veriyi güncelemek şu sql kodunu hazırlayıp işletiyorum. (ibquery kullanarak).

Kod: Tümünü seç

UPDATE BATCH SET SILO1_RECEIVED = 100 WHERE BATCH_ID = 1;

gerçek çalışma ortamını simule etmek için interval değeri 150 olan bir timer içinde sürekli olarak bu kodu işlettim. ve kaç defa işlettiğimi görebileyim diye bir sayaç kullanarak değerini bir label'a yansıttım. ilk 1000 hemen hemen stabil giderken. daha sonrasında takılmalar başlıyor. 3000'ni geçince takılma süreleri dahada artıyor ve artmaya devam ediyor. ve sonunda pencere mousela bile kontrol edilemez hale geliyor.

testi ilk önce firebird 2.5 superserver ile yaptım. classic server ile denedim o daha beter donmaya başladı. emded kullanma şansım olmadığı için embed ile test etmedim.
testi sqlite ile yaptım. hiçbir şekilde takılma veya donma olmadı.
testi firebird 3.0 Alfa superserver ile yaptım. hiçbir takılma veya donma sorunu olmadı.

sorun firebird 2.5'ta gibime geliyor. eğer öyle ise delphi tarafından gönderdiğim her sorgunun bir öncekine göre yavaş çalışması ciddi bir sorun. günlük 500-1000 civarı veri girişi yapılan bir sistemde göze çarpmaz belki ama bu sayının artması kullanıcıyı rahatsız edecek bir yavaşlamanın ortaya çıkması demek. kullanıcıya bilgisayarı kapat aç demekte profesyonel bir yaklaşım olmaz. firebird 3.0'te bu sorunun yaşanmamasına rağmen henüz alfa aşamasında ve final sürüm ne zaman çıkar hiç bir fikrim yok.

buna benzer sorunlar yaşamış arkadaşlar varsa ve izledikleri yolu burada paylaşırlarsa sevinirim. ayrıca sorun bende de olabilir. yukarıda anlattığım testi imkanı olan arkadaşlar firebird 2.5 ile yapıp sonuçlarını buradan paylaşırsa durum netliğe kavuşmuş olur. şimdiden teşekkür ederim.

[warder]

Probleminizi okuduğumda ilk aklıma gelen olduğu için yazıyorum. Bir not olarak değerlendirin.
Kullandığınız bilgisayarın RAM stoğunun 0 ile 3000 sorgu sonrası ne durumda olduğuna baktınız mı?
MySQL sunucunun varsayılan ayarlarında, kullanılan sorguların tekrar kullanıldığında hız sağlamak adına cache yöntemi kullanılıp RAM şişmeleri makineyi tökezletiyordu.
Bu not MySQL 3 versiyon içindi. Hala öylemi bilmiyorum. Artık optimizasyon ile ilgilenmiyorum.

[omurolmez]

Yaşamadım benzer bir problem, tamamen tahmine dayalı bir kaç şey ...

* transaction commit(tavsiye ederim) mi ediyorsunuz yoksa commitRetaining mi ?
* Her bir insert/update vs için yeniden mi bağlanıyorsunuz yoksa program boyunca tek bir bağlantı (database ve transaction ikilisi) kullanıyorsunuz (2. tavsiye ederim)
Veya yazılımınızda veya bileşen setinizde siz istemeseniz de ilk duruma yol açacak bir bug mı var ?
* seçtiğiniz transaction isolation level repetable read den daha mı sıkı (read-write isolation vs kadar yüksek mi ?)

[kgnonr]

Konuyla ilgili en nihayet bir sonuca ulaştık. Bunu sizinlede paylaşmak istedim. Lakin bu durum başka soru işaretlerine neden oldu. onları da sizinle paylaşmak istedim.

Yazılım genel itibari ile ağır bir yazılım değil. harici bir cihazdan günde ortalama 5000 civarı veri alınıp database işleniyor ve bu veriler raporlanıyor. programın genel amacı bu.
bu alınan veriler HAREKET tablosuna işleniyor ve KART tablosunada bu işlenen verilerin toplamları yazılıyor. bu konuda http://www.delphiturkiye.com/trigger.htm bağlantısında geçen makaleden faydalandım. emeği geçen arkadaşlara ayrıca teşekkür ederim.

Gelelim soruna; HAREKET tablosunun AfterUpdate tetiklemesi (trigger) içerisine yukarıda bahsettiğim makaleden yola çıkarak şu şekilde yazdım.

Kod: Tümünü seç

UPDATE
      TARGET
  SET
      SILO1_RECEIVED  = SILO1_RECEIVED  + NEW.SILO1_RECEIVED,
      SILO2_RECEIVED  = SILO2_RECEIVED  + NEW.SILO2_RECEIVED,
      SILO3_RECEIVED  = SILO3_RECEIVED  + NEW.SILO3_RECEIVED,
      SILO4_RECEIVED  = SILO4_RECEIVED  + NEW.SILO4_RECEIVED,
      SILO5_RECEIVED  = SILO5_RECEIVED  + NEW.SILO5_RECEIVED,
      SILO6_RECEIVED  = SILO6_RECEIVED  + NEW.SILO6_RECEIVED,
      SILO7_RECEIVED  = SILO7_RECEIVED  + NEW.SILO7_RECEIVED,
      SILO8_RECEIVED  = SILO8_RECEIVED  + NEW.SILO8_RECEIVED,
      SILO9_RECEIVED  = SILO9_RECEIVED  + NEW.SILO9_RECEIVED,
      SILO10_RECEIVED = SILO10_RECEIVED + NEW.SILO10_RECEIVED,
      SILO11_RECEIVED = SILO11_RECEIVED + NEW.SILO11_RECEIVED,
      SILO12_RECEIVED = SILO12_RECEIVED + NEW.SILO12_RECEIVED,
      SILO13_RECEIVED = SILO13_RECEIVED + NEW.SILO13_RECEIVED,
      SILO14_RECEIVED = SILO14_RECEIVED + NEW.SILO14_RECEIVED,
      SILO15_RECEIVED = SILO15_RECEIVED + NEW.SILO15_RECEIVED,
      SILO16_RECEIVED = SILO16_RECEIVED + NEW.SILO16_RECEIVED,
      SILO17_RECEIVED = SILO17_RECEIVED + NEW.SILO17_RECEIVED,
      SILO18_RECEIVED = SILO18_RECEIVED + NEW.SILO18_RECEIVED,
      SILO19_RECEIVED = SILO19_RECEIVED + NEW.SILO19_RECEIVED,
      SILO20_RECEIVED = SILO20_RECEIVED + NEW.SILO20_RECEIVED,
      SILO21_RECEIVED = SILO21_RECEIVED + NEW.SILO21_RECEIVED,
      SILO22_RECEIVED = SILO22_RECEIVED + NEW.SILO22_RECEIVED,
      SILO23_RECEIVED = SILO23_RECEIVED + NEW.SILO23_RECEIVED,
      SILO24_RECEIVED = SILO24_RECEIVED + NEW.SILO24_RECEIVED
  WHERE
      PRODUCT_ID = NEW.PRODUCT_ID;

  UPDATE
      TARGET
  SET
      SILO1_RECEIVED  = SILO1_RECEIVED  + OLD.SILO1_RECEIVED,
      SILO2_RECEIVED  = SILO2_RECEIVED  + OLD.SILO2_RECEIVED,
      SILO3_RECEIVED  = SILO3_RECEIVED  + OLD.SILO3_RECEIVED,
      SILO4_RECEIVED  = SILO4_RECEIVED  + OLD.SILO4_RECEIVED,
      SILO5_RECEIVED  = SILO5_RECEIVED  + OLD.SILO5_RECEIVED,
      SILO6_RECEIVED  = SILO6_RECEIVED  + OLD.SILO6_RECEIVED,
      SILO7_RECEIVED  = SILO7_RECEIVED  + OLD.SILO7_RECEIVED,
      SILO8_RECEIVED  = SILO8_RECEIVED  + OLD.SILO8_RECEIVED,
      SILO9_RECEIVED  = SILO9_RECEIVED  + OLD.SILO9_RECEIVED,
      SILO10_RECEIVED = SILO10_RECEIVED + OLD.SILO10_RECEIVED,
      SILO11_RECEIVED = SILO11_RECEIVED + OLD.SILO11_RECEIVED,
      SILO12_RECEIVED = SILO12_RECEIVED + OLD.SILO12_RECEIVED,
      SILO13_RECEIVED = SILO13_RECEIVED + OLD.SILO13_RECEIVED,
      SILO14_RECEIVED = SILO14_RECEIVED + OLD.SILO14_RECEIVED,
      SILO15_RECEIVED = SILO15_RECEIVED + OLD.SILO15_RECEIVED,
      SILO16_RECEIVED = SILO16_RECEIVED + OLD.SILO16_RECEIVED,
      SILO17_RECEIVED = SILO17_RECEIVED + OLD.SILO17_RECEIVED,
      SILO18_RECEIVED = SILO18_RECEIVED + OLD.SILO18_RECEIVED,
      SILO19_RECEIVED = SILO19_RECEIVED + OLD.SILO19_RECEIVED,
      SILO20_RECEIVED = SILO20_RECEIVED + OLD.SILO20_RECEIVED,
      SILO21_RECEIVED = SILO21_RECEIVED + OLD.SILO21_RECEIVED,
      SILO22_RECEIVED = SILO22_RECEIVED + OLD.SILO22_RECEIVED,
      SILO23_RECEIVED = SILO23_RECEIVED + OLD.SILO23_RECEIVED,
      SILO24_RECEIVED = SILO24_RECEIVED + OLD.SILO24_RECEIVED
  WHERE
      PRODUCT_ID = OLD.PRODUCT_ID;

Sizlere bahsettiğim donma ve takılmalara bu trigger kodları neden oluyor. örneğin sorgu sayısı 3000'lere ulaştığında program takılmaya başladığında harici bir tool (ibexpert) ile database'e bağlanıp bu triggeri devre dışı bıraktığımda donma ve takılma tamamen ortadan kalkıyor. devreye aldığımda tekrar başlıyor. yani konu delphi tarafından gönderdiğim sorgu sayısında değil. firebird tarafında çalıştırılan trigger sayısı ile alakalı. yukarıdaki kodlardan anlaşılacağı üzere 24 ayrı veri var. bunlardan birincisi için 1 kez insert triggeri 23 kez update triggeri (yukarıda yazdığım) çalıştırılıyor.

ikinci aşamada Firebird 3.0 Alfa ile aynı şartlarda deneme yaptım donma ve takılma yine oluştu. (yukarıda firebird3 ile donma yaşamadığımı yazmıştım. fakat o zaman trigger olmadan denemiştim)

üçüncü aşamada yine aynı şartlarda Sqlite ile deneme yaptım. hiç bir takılma ve donma olmadı. hatta ve hatta sorgu sayısı değil 3000, Otuzbinlere ulaştığında bile en ufak bir problem olmadı.

test için hazırladığım database ve delphi source kodlarını http://www.mediafire.com/download/7z4au ... FBTest.rar linkinden indirebilirsiniz. (Firebird 2.5 + Delphi 2010). Bir timer vasıtası ile tabloyu sürekli update ediyorum ve sonucu dbgrid'e yansıtıyorum. benim testim'de sorgu sayısı 3000'lere ulaştığında bariz takılmalar başlıyor. program çalışmaya devam ederken trigger devreden çıkartırsam takılmada tamamen ortadan kalkıyor.

Değerli fikirlerinizi bekliyorum. İlginiz için teşekkür ederim.

İsteyen arkadaşlar indirip test edebilir.

[mussimsek]

product id alanı indekslimidir? Değilse indeks yapıp bir deneyin...

Kolay gelsin.

[esistem]

Merhaba;
Değil firebird de paradox yada dbf tablosu bile olsa 5-10 bin kayıtta, eğer alanlarınız indexli ise hiçbir yavaşlama olmadan işlemi yapması gerekir. mussimsek in dediği gibi indexlerinizi kontrol ediniz bencede.

[kgnonr]

productid master tabloda primary key, detail tabloda foreign key. dolayısıyla indexli olması gerek yanlış bilmiyorsam. yinede ayrı olarak indexleyerek denedim. sonuç değişmedi. yukarıda yaptığım test programındaki veritabanında 2 adet tablo, 1 adet trigger, her tabloda birer adet kayıt var. bunu değişik konfigurasyonlu başka pc lerdede denedim. sonuç değişmedi. eğer imkanınız varsa indirip gözlemlerinizi yazarsanız çok sevinirim. program içerisinde start butonuna basıp sorguyu başlatın. bu arada gönderilen sorgu sayısı bir label ile pencereye show ediliyor. sorguyu başlatınca penceyi tutup taşıyın. sorun çıkmayacak. fakat sayac 3000'e ulaşınca tekrar taşımaya çalışın. aradaki farkı göreceksiniz. en azından bende öyle oluyor .

[esistem]

merhaba;
intervali 150 olan bir timer ne kadar uzun süre çalışırsa ve her çalıştığında vt ye veri yazıp güncelleyip bunu ekranda gösteriyorsa bir süre sonra programın donması normaldir, işlemi thread ile yaparsanız donma sorunu kalmaz, kaldı ki yanlış hesaplamış olabilirm ama interval 150 ise 10.000 kayıt max. 25 dakika sürer, bence farklı bir şekilde simüle edin programı, programı indirip deneyemiyorum zira 2,1 yüklü bende + d7 ile çalışıyorum.

[kgnonr]

lakin bu testleri fb 1.5, 2.0, 2.1, 2.5 ve 3.0 ile yaptım. hepsinde aynı neticeye ulaştım. yıkarıda da bahsettim. problem sorgu sayısında değil. update edilen tablonun after update triger'ı var. trigger kodları yukarıda mevcut. eğer bu trigger devre dışı kalırsa değil 10bin 100binlere geldiğinde dahi bir takılma olmuyor. kodları incelerseniz bu trigger içerisinden biri old biride new değerler için olmak üzere iki kez update ifadesi çağırılmakta. çok ilginçtir ki eğer bu trigger içerisindeki update ifadelerinden birini devreden çıkarsam yine takılma olmuyor. zira kesin teşhisim şu. bir trigger içerisinen 2 veya daha fazla update sorgusu çağırılırsa her defasında firebird bir geçikme süresine giriyor ve bu gecikme süresi giderek artıyor. artan bu süre delphi tarafında yapılan işlemleride olumsuz etkiliyor. yani yazılım durduk yere kasıntı yapmaya başlıyor. demek istediğim soruna ulaşıldı ama çözülemedi. isteğim, sizlerinde bu sonucu tecrübe etmesini sağlamak ve böylelikle firebird'de yer alan bu olumsuz durumun giderilmesini sağlamaktı. zira sqlite ve sybase(asa) ile yaptığım testlerde (aynı tablo ve trigger kodları ile) hiç bir takılma yaşamadım. ikisinde de böyle bir sorun yok. ilginiz için teşekkür ederim.

[esistem]

O zaman şöyle ir ihtimal daha olabilirmi?

Hareket tablosunun afterupdate triggerinde update edilen TARGET tablsonun da update triggerinde bi işlem yaptırıyor olabilirmisiniz?
Yada;
Nasıl anlatıcam bilemiyorum ama, mantık hatası yapılıp, x ve y tablolarının update triggerleri birbirlerine sürekli güncelleme gönderip kısır döngüye sebep oluyor olabilirmi?

yani; X tablosunun afterupdate triggerinde git Y tablosunu update et, Y tablosunun afterupdate triggerinde git X tablosunu update et şeklinde bir yol izlenmiş olabilirmi?

Veya update trigger kodunu şöyle düzenleseniz?
Silo isminde bir alan olduğunu varsayıyorum, yoksada declare veriable ile oluşturulabilir.

Kod: Tümünü seç

if (new.silo=1) then UPDATE TARGET SET SILO1_RECEIVED  = SILO1_RECEIVED  + NEW.SILO1_RECEIVED WHERE PRODUCT_ID = NEW.PRODUCT_ID;
if (new.silo=2) then UPDATE TARGET SET SILO2_RECEIVED  = SILO2_RECEIVED  + NEW.SILO2_RECEIVED WHERE PRODUCT_ID = NEW.PRODUCT_ID;

if (old.silo=1) then UPDATE TARGET SET SILO1_RECEIVED  = SILO1_RECEIVED  + OLD.SILO1_RECEIVED WHERE PRODUCT_ID = OLD.PRODUCT_ID;
if (old.silo=2) then UPDATE TARGET SET SILO2_RECEIVED  = SILO2_RECEIVED  + OLD.SILO2_RECEIVED WHERE PRODUCT_ID = OLD.PRODUCT_ID;

şeklinde deneseniz?

Birde anlamadığım neden hem OLD hemde NEW şeklindekayıtları hep arttırıyorsunuz, OLD ile eksiltip NEW ile arttırmanız gerekmezmi? Siz aynı tabloyu (TARGET tablosunu) hep arttırıyorsunuz?

Ayrıca yukarıda anlatmak istediğim olayda buydu, TARGET tablosunun update triggeride gidip başka bir işlem yapıyormu? yada BATCH tablosunu direk yada dolaylı yoldan etkileyecek bir işlem yapıyormu desem daha doğru olur.

[kgnonr]

gerçek projede target tablosunun update triggerı mevcut ki oda stok tablosundaki stok miktarlarını aynı mantık ile arttırıp azaltıyor. fakat yinede gözden kaçırdığım bir nokta varsa diye bilinçli olarak böyle bir döngü oluşturdum hangisi emin değilim ama ya ibexpert, yada firebird bu duruma izin vermedi. OLD değerler konusunda haklısınız. ben buraya geçirirken hatayla arttırma şeklinde geçirmişim. aslında old değer sizin dediğiniz gibi eksiltme yapıyor. velhasıl bir türlü çözüme ulaşamadık. her ne kadar bir çok emeği heba edecek olsada veritabanını değiştirmeyi düşünüyoruz. fakat bu durum üzerinde de çözüm bulana kadar çalışmaya devam edeceğim. eğer bir çözüm bulabilirsem sizlerle paylaşacağım. ilgi gösteren ve ilgi gösterecek tüm arkadaşlara teşşekkür ederim.

[esistem]

Selam;

gerçek projede target tablosunun update triggerı mevcut ki oda stok tablosundaki stok miktarlarını aynı mantık ile arttırıp azaltıyor.

ibexpert kullanıyorsanız evet bahsettiğim gibi bir duruma izin vermez, mantık hatası şeklinde uyarı verir, veritabanının kısır döngüye girmesine izin vermez.
ayrıca yukarıdaki yazdığına dayanarak varsayımda bulunayım;

peki, target ablosu update triggerinda da stok tablosu miktarlarını değiştiriyorsanız, stok tablosunu target tablosuna bağlayan foreign idlerinizde indexlimi? eğer onlarda indexli değilse yavaşlama yapabilir.
Yada kurgu hatası yapıp update edilmesine gerek duyulmayan işler içinde gidip tabloda boşu boşuna update yapıyor olabilirsiniz.

[Kuri_YJ]

Selamlar,

Şu database'i, tabloları ve bahsettiğiniz programınızı bana yollar mısınız. Ben de bir incelemek isterim, bahsettiğiniz konu record versioning, index ve page yapılanmasıyla alakalı gibi görünüyor.

Ben de incelemek isterim.

adnanoncevarlik@gmail.com

Kolay Gelsin

[Kuri_YJ]

Selamlar,

Emeklerinizi heba etmeyin bir çözümü mutlaka vardır, olayın bütününü görebilirsek bir çözüm oluşturabiliriz gibi geliyor bana.

Öncelikli öğrenmek istediğim şeyler, Server nedir, üzerinde hangi işletim sistemi var, disk yapılanması ve disk hızları, CPU yapılanması ve model ve hızları, memory???? Bunlar hakkında da bilgi verin. Ben bahsettiğiniz bir şeyle hiç karşılaşmadım, şöyle ki, bir gün içerisinde birbirine bağlı 4-5 tablo ve her tablodada triggerlar mevcut, bu tablolarada gün içerisinde bırkaın 5000 defa, yüzbinlerce defa kayıt işleniyor ve tetikleniyor ve bahsi geçen türde bir yavaşmala söz konusu değil.

Mutlaka atladığınız bir nokta vardır.

Kolay Gelsin