Kronik Firebird Problemleri 1 :)

[Kuri_YJ]

Selamlar,

Söylediğim ayarlamaları yaptınız mı? Ayrıca Sistemin %100'ünü kullanması sorun değil, sorun çalışma sırasında size verdiği yanıttır. Sistemin %100'ünü kullanması verimli kullanım anlamına gelir (kanaatimce) CPU veya sistem kaynaklarının %5'lerde veya %10'larda kullanılıyor olması ATIL kapasitenin göstergesidir.

Sorduğum sorulara yanıt alabilirsem belki yardımım dokunabilir.

Kolay Gelsin

[husonet]

Merhabalar

Ayarlamaları yaptık değişen bişey olmadı.

Bizdede FB server loglarına baktığımızda 10054 nolu hatayı görüyorz.

Teşekkürler...

[Kuri_YJ]

Selamlar,

Uygylamanız hangi dilde yazıldı? Loglardaki bu hata Clientlar ile alakalı bir durum gibi görünüyor. Özellikle .Net versiyonları ile sıkıntı yaşanabiliyormuş.

http://www.mail-archive.com/firebird-ne ... 07016.html

Buraya bir göz at. Bu threadlerde benzer sorunlar yaşanmış ve adamlar Firebird Client'ı .Net 2.0 için derleyerek sorunu çözmüşler.

Bak bakalım işini görecek mi?

Sizin iş yeri nerede Server nerede?

[Kuri_YJ]

Bir de buraya bak bakalım,

http://firebird.1100200.n4.nabble.com/l ... 07183.html

Ayrıca, 10054 Hatası hakkında FB geliştirmenlerinin notları var oda şurada

http://www.firebirdfaq.org/faq119/

Oraları inceleyip bir fikir üretebilirsiniz belki. Ama hız ve performans konusunda sıkıntı yaşıyor olmanız ilginç mutlaka farkında olmadığımız bir etmen var gözden kaçan.

Kolay Gelsin

[integra_sir]

Selamlar,

Konuyu tesadüfen buldum ve biraz katkıda bulunmak istedim. 2004 yılından beri firbird üzerinde program yazıyorum ve olabilecek her türlü kötü senaryo ile karşılaştım. Firebird CPU dan beslenen bir veritabanı, RAM ile çok işi olmuyor. Yazdığım en son programın veritabanında tek bir table da 310 alan ve 150 bin kayıt var. Bu, master dosya. Detailleri ile birlikte 2 milyonu geçkin kayıt ile raporlama ve çalışma yapılıyor ve bu program internet üzeriğnden VT na bağlanıyor. Server 8 Çekirdekli ve 2 GB Ram li. Anlık kullanıcı sayım 200 civarında ve hedefim en az 3000 Kullanıcı. Fb 2.5 Kullanıyorum.

Tabi deneme yanılmalar ile geçen bunca senenin ardından bir kaç önemli konuya kendimce çözümler ürettim. Örneğin Veritabanı tasarımını bir defa yapıp bitirmek yerine olası tüm senaryoları düşünerek 2-3 defa tasarlayıp en uygun olanı üzerinde kod yazmaya başladım. Raporlarda neyi isteyeceğiz sorusunun yanıtını ilk başta vermek lazım ki çalışma başladığında yama yapmaya gerek kalmasın.

Somut örneklerle açıklayım: Stok takibi yapıyoruz diyelim. İlk kural sistemden hareket görmüş Malzemenin silinmemesi. Bu malzemenin toplam alış miktar ve tutarları, çıkış miktar ve tutarlar, ikisi arasındaki fark (yani mevcut stok) , ortalama alış ve satış tutarları v.s.

Çok basit bir iki procedure yazıp, alış veya satış anında malzemenin kartına bu değerleri işliyorum. Mesela 10 tane alınmış, procedure insert ve update olaylarında devreye girip o malzemenin geçmiştekilerle birlikte toplam alış miktarını hesaplayıp malzeme kartına işliyor. Satışda da aynı işlemi uyguluyor. Bu işlem 1 -2 saniye sürüyor. Malzeme kartında da alış ve satış adetleri ile toplam tutarları belli artık. Ortalamaları da COMPUTED BY alan ile hesaplatıyorum. Rapor alırken 15 bin kalem malzemenin yıllık hareket raporu Table Nesnenisin SUM işlemi ile toplanmak zorunda kalmıyor, var olan bilgi direkl listeleniyor ve 1 dakikadan kısa sürüyor. Bunu geliştirip kendi projelerinize adapte ederseniz emin olun Hız Sorunu diye bir sorununuz olmayacaktır.

FBI Plus bileşenini mutlaka kullanın. Çok güçlü. Firebird.Conf ile fazla oynamaya gerek yok, ama Table larda AutoCommit özelliğini TRue yapın.

Ve program çalışırken , tam kayıt yapılırken isterseniz makinenin fişini çekin. FB tarafı sizi yarı yolda bırakmayacaktır.

[Murat DİCLE]

Merhabalar

Ayarlamaları yaptık değişen bişey olmadı.

Bizdede FB server loglarına baktığımızda 10054 nolu hatayı görüyorz.

Teşekkürler...

Anti-virüs veya firewall kontrol et. Firebird portu kullanamıyor, ve bağlantı kesiliyor demektir. İkinci bir sebepte, başka bir program firebird ile aynı portu kullanıyor, yani firebird'den önce aynı portu tahsis etmiş demektir.

[csunguray]

Firebird'ü severim ama buraya iyi şeyler yazamayacağım. Bu kadar yıldır MS-SQL kullanıyorum. Hiç bir zaman bu bahsettiğini sorunlarla karşılaşmadım. Bir Database imde milyondan fazla kayıt var. İndekssiz sahalara göre gruplama veya filtreleme yapsam bile sıradan P4 CPU'lu 4 GB RAM'li makinede 20 saniyeden uzun süren bir sorgum olmadı. Üstelik 20'den fazla kullanıcı aynı DB'yi günlük işler için kullanıyorken. Şimdi bu sorunları duymak FireBird kullanımı konusunda beni korkuttu açıkçası. Hayırlısı diyelim.

[Kuri_YJ]

Selamlar,

Benim de bahsettiğim şey integra_sir arkadaşımızın yazdıklarıyla ilgilidir. Yani dizayn çok önemli. Hangi raporu almak, hangi işlemi yapmak istiyorsanız iş akışınızı buna göre düzenleyip DB'nizi tasarlamanız gerekmekte.

Ben de hız konusunda FB'de şimdiye kadar herhangi bir sıkıntı yaşamadım. Daha geçende bir firmada, aynı anda yaklaşık 70 Kullanıcı ile Predictive Dialer yaptık. Bana mısın demedi Üstüne üstlük 1'e 12 çağrı başlatmalarına rağmen. Ha bir de çalıştığı makina 1 Ghz 1 GB RAM olan Sanal bir Server.

Yani hız veya benzeri bir şeyde sorun yaşanması, çok büyük ihtimalle dizayn ile alakalıdır.

20 Saniye beklemek çoook uzun bir süre. 1 -2 saniye haydi 5 saniye (ki bu rakamlar raporlamalar ile ilgili)

Örnek vereyim benim geliştirdiğim bir program var yaklaşık şu an itibariyle 100,000 Kayıt civarında hareket kaydı var ve Cari Hareket Ekstresi veya Stok Hareket Ekstresini raporlamak (Query Result 2.5 Sn., Raporun Tamamının Hazırlanması 15 sn. kadar sürüyor) Bu hareket ekstrelerinden oluşan Raporun büyüklüğü ise 1400 Sayfa kadar Bu raporları bilenler, Kart Ekstrelerinin tek tek ve kümülatif bakiyeli olduğunu bilirler

Yani bir de bu bahsettiğim şey benim kendi Laptop'umdaki skorlar, bunlar iyi bir Server'da çok daha hızlı ve iyi yanıt verir

Yani olay Dizaynda diye diretiyorum

Kolay Gelsin

[AhmetNuri]

ne kadar etkisi olur bilmiyorum ama test amaçlı sistemi 30 saniyede bir kesip tekrar bağlanacağına sürekli bağlı kalmayı deniyebilirsin.
yeni kayıt varmı diye bir sql kullanıyor olman lazım. Bunun için mümkünse tek alan kullanman iyi olur.eğer yeni kayıt varsa sonradan başka bir sql ile diğer verileri çekmen faydalı olabilir.

[Kuri_YJ]

Hüseyin Selamlar,

Şimdi bazı bilgiler vereceğim. Bir de bunları göz önünde bulundurarak Server ve DB'nizi bir kontrol ediver.

CPU Affinity Mask'ı efektif kullanmak için Zilyon çekirdekli bir sunucu yerine Clock Hızı Yüksek ama daha az çekirdekli bir sunucuda çalışmak Super Server için daha iyi. Çünkü SMP desteğinde yeterince iyi değil. CPU kullanımlarını FB SuperServer Her bir DB'yi bir Çekirdeğe Assign ediyor. Dikkat bu sadece Super Server'da böyle. Diğer versiyonlarında değil. Ancak diğer versiyonların da başka kısıtları mevcut. Cache olaylarında da İşletim sistemi sebebiyle 32 bit versiyonda MAX 131000 küsür page set edebiliyorsunuz. Çok daha yüksek page yüklemek isterseniz o zaman da 64 Bit versiyonu kurmanız gerekiyor. Bu sınır işletim sisteminden kaynaklı. 2 GB'dan daha büyük bellek bölgesini adresleyemediği için.

FB 3.0'da (ki 2012 Quarter 1'de Alfa Releaseler çıkması planlanıyor) o zaman Real SMP desteğini vereceklerini söylüyorlar. Biraz bu konuda beklemek gerekiyor. Ben bu CPU kullanımlarını baya bir inceledim ve dört gözle 3.0'ı bekliyorum. Ayrıca Sweep Intervallerinin seti nasıl? Çok mu yüksek çok mu düşük? Bunlara ek, Raporlama yaptığın DB ile iş yaptığın DB aynı mı? Yoksa ayrı mı? Bir deneme daha yapmanı isteyeceğim.

Backup-Restore yapmayı hiç denediniz mi?

Kolay Gelsin

Not : Eski yazıları okumaya üşendim, aynı soruları tekrarlamış olabilirim, sen yine de yanıtla