FireBird Tıkandı....

[recepgalip]

merhabalar arkdaşlar..
yaklaşık 150 terminalli bir sistemde ve surekli kayıt yapılan bir projemiz var. sebebini tam anlayamamakla beraber 10 gundur sistemimiz aşırı bir yavaşlık olmakta. bunun sebebi ne olabilir. acaba aşırı bi yuklenmeye cevap mı veremiyor FireBird.
FireBird 1.5 kullanıyorum
win2003 işletim istemi.
fizikse 2 işlemcili 4 çekirdekli exper server var.
3gb Ram

FireBird sankim işlemcileri tam kullanamıyor gibime geldii.

hatta ibconfig dosyasıda aşagıdaki dzenlemeleri yaptık.

ProcessPriorityLevel = 1
DefaultDbCachePages = 16384
SortMemBlockSize = 4194304
SortMemUpperLimit = 1073741824

Bugunde FireBİrd2.0 kurduk. oracle duzeyide diye bi ara işitmiştim. Acaba Çift İşlemci Destegi Varmı. Yada En uygun ayaları nasıl yapabiliriz.
Acil Yardımcı olursanız sevinirimm. ii çalışmalar.

[fduman]

Firebird'ün birden fazla işlemciye desteği var. Ancak bu destek oldukça ilkel. Mesela uzun sürebilecek zorlu bir sorguyu işlemciler arasında paylaştıramıyor.

Örneğin eğer 2 bağlantı yapar iseniz, bağlantılar diğer işlemcilere paylaştırılıyor.

Firebird'ü birden fazla işlemciye sahip bir sistemde deneme şansım olmadı. Ancak okuduklarıma göre çoklu işlemci desteğini kapatarak sadece bir işlemcinin Firebird'ü çalıştırmasının sağlanması öneriliyordu. Conf dosyasındaki CPUAffinity ayarı ile hangi işlemcinin Firebird işlemi yapacağını belirtebilirsiniz.

Gerçek SMP desteği için Firebird 3.0'ı beklemelisiniz.

[freeman35]

10 gibi kısa bir sürede sorun direk meydana geldiyse bence FB de bir problem yoktur. Networkte yada donanımsal bir sorun olabilir. FB 2.0 çift işlemci konusunda fazla bilgim yok ama mikisoft için 64 bit henüz deneme aşamasında. bunuda hallederlerse oldukça iyi olacak. FB 2.0 a direk geçmeden önce mutlaka ve mutlaka iyice testler yapmanızı öneririm özellikle SP trigger gibi yazdığınız SQL kodlarını.

Benim başıma gelen bir kaç sefer karşılaştım bununla. server da FBServer acaip kasışlıyordu. işlemcinin %100 nü kullanıyordu. işlem olmamasına karşılık. server ı down edip tekrar açtığımda sorun çözülüyordu. Tam nedenini bulabilmiş değilim. ama tahminin remote bağlantı var ve bu olmadık zamanda kesilip transactionlar düzgün sonlandırılımıyor olabilir. yani gene donanımsal bir sebep.
Server ı down edin. "lck" file larını silip tekrar deneyin. Yapmış olabilirsiniz ama programınızda transaction işlemlerini tekrar gözden geçirin. commit ve rollback lerin tüm olasılıklarını tekrar inceleyin.

kolay gele

[recepgalip]

Abi 9-11 Arası terminallerin en yogun yıgıldıgı an. 10-15 gundur çok ağırlaştı.

abi network normal gorukuyor. şöle sorsam

-150 teminal 900mb bi data üzeirnde aktif çalışsalar firebird bunu kaldırabilirmii ?
-Networku nasıl test edebilirim.Arza varmı yokmu diyee
-Server çift işlemcili (fiziksel 2 mantıksal 4 cpu ),win2003 stantart,3 gb ram var. firebird çift işlemci desteği daha tam değil yaaa acaba bu makina ters tepki yaparmııı.
-bide 7 ayrı gdb var. ve baktım 700 bağlantı kullanıyor. bunlar nsıl oluşurkine. ben bağlantı kurdum orn. programı kapattım bu bağlantılarda kopmuyormuuu. yada nasıl koparabilrizz

teşekkürler.
_________________

[vkamadan]

Merhaba,
Programınızda aktif TibConnection nesnesi kaç taneyse o istemci sunucuda okadar bağlantı olarak görünür.Birden fazla bağlantı nesnesini kullanıyorsanız bu normal.

[doganzorlu]

Selam,

Muhtemelen uygulamadan çıkılırken db bağlantısı close edilmiyor bir şekilde. Açık bağlantıların nu kadar öyle kalacağına işletim sistemi karar verir (uygulama içinde ayrıca bir kod yazılmamışsa). Bunu tcp keepalive_timeout değeri belirler ve default 3600 sn. yanlış hatırlamıyorsam. Yani bu tip askıda kalan oturumlar 1 saat açık kalıyor nerdeyse. Bunu w2k3 için registry den azaltabilirsiniz. Bu şekilde ucu açıkta olan bağlantıların kendiliğinden reset edilmesi sağlanabilir.

900mb çok küçük bir veritabanı. Bununla birlikte bağlantı sayısının artması ile ortaya çıkabilecek en belirgin problem classic server dır. Zira herbir bağlantı için ayrı bir server process oluşur. Tüm bağlantıların birer process i vardır ve aynı anda bir process db ye erişebilir. Sizin yaşadığınız darboğaz muhtemelen bundan oluyordur. Bunu sınamak isterseniz swap io suna bir bakın. Utilizasyonun swap io yüzünden çok yükseldiğini göreceksiniz. Yani RAM yetmiyor. 3gb size büyük gelebilir ama bağlantı sayısı arttıkça çok küçük birşey haline geliyor. Düşünün, bir instance 10mb kullansa 700x10mb = 7gv yapar. en az 5gb swap kullanmaya başlar sistem ve dramatik şekilde yavaşlarsınız.

Çözüm olarak superserver kullanmanızı önereceğim. Bu durumda tek server process çalışacağından kaynak sorunu olmayacaktır.

Kolay gelsin,

[recepgalip]

abi zaten superserver kullanıyorum zaten. ama anlamadıgım bi sebep var. hala bulamadımm.

[recepgalip]

yok yok abiler ablalar FireBird 150 terminali kaldıracak gucte değil. Bu3.0 çıkana kdar ben çoktan oracleli olurum. of ulen of. ne bel bağlamıştım bu FireBird e

[rsimsek]

Veritabanı iyileştirme/optimizasyonu olmadıktan sonra hangi veritabanı sunucusu olursa olsun teklemeye mahkümdür Bence ne zaman hangi olaydan sonra bu durama geldiğinizi bir kez daha geriye dönük sorgulayıp araştırınız. Mümkünse sunucunun belleğini bir miktar daha artırıp, tampon/swap kullanımını kapatınız (xp de var 2003 de var mı emin değilim). Böylece hdd ye erişim en aza iner. Bir de sorgularda mı yoksa kayıt girişinde mi, ya da çoğunlukla terminallerden ağırlıklı yapılan işlemlerin istatistiki sonuçlarını yazarsanız belki daha isabetli öneriler yapabiliriz. SP içinden SP çağırmaları belli bir perfomans kaybına sebep oluyor

[Hakan Can]

yok yok abiler ablalar FireBird 150 terminali kaldıracak gucte değil. Bu3.0 çıkana kdar ben çoktan oracleli olurum. of ulen of. ne bel bağlamıştım bu FireBird e

Arkadaşım değil Oracle, Moracle kullansan bile (bunu ben uydurdum) problemin gitmeyecektir. Çünkü problemlerin %99.99999'u yazılımcıya aittir.

Hem öyle Oracle vs. düşündüğün gibi mucize bir veritabanı değildir. Performans açısından umduğunun aksine hüsrana uğrayacaksındır.

Ben şu ana kadar 1000 tane problemle karşılaştıysam belki de tamamı bana aitti. Her defasında bu sefer bana ait olmayacak diye ümit etmiş olmama rağmen maalesef bu yazılımcıların kaderidir.

Eğer zahmet edip daha detaylı bilgi verirsen problem mutlaka çözülecektir.
Örneğin veritabanın hakkında daha detaylı bilgi verebilirsin. Kaç tablo (kabaca kaç alanlı, integrity var mı?), kaç view, kaç SP, kaç trigger kullandın? En çok kullanılan tabloların, SP'lerin, triggerların tam yapılarını (SQL scriptlerini) bize gösterebilir misin? Client programında hangi componentleri kullandın (IBX, BDE, dbExpress vs.)? Transactionları nasıl kullanıyorsun. Tutup en basit işlemlerde de transaction kullandın mı?

Değil 150 terminal tek kullanıcılı bir sistemde bile kötü yazılım ve kötü VT dizaynı ile değil 900 MB'lık bir VT'yi 10 MBlık bir VT'yi bile kilitlemek çok basit. 3 tane bol FULL OUTER JOIN'li query gönder sonra CPU'yu %100 olarak 8 saat süreyle gözlemlersin. Tabi bu Oracle için de MS-SQL için de hepsi için de geçerli.

Sonuç olarak sorun VT'de değil. Sorun bizde yani yazılımcı da.

İyi çalışmalar.

[Kuri_YJ]

Selamlar,

700 connection????? Pardoon????? 150 Terminalden 700 Connection demek yazılımlarda sorun var demektir.

150+150+150+150+150=750

Yani her terminalde ya ayrı ayrı 5 program çalışıyor yada her program en az 5 connection kuruyor demektir.

Bu da yazılımcı birşeyleri yanlış yapıyor demektir. İstediğiniz versiyonu, istiyorsanız istediğini VT'yi kullanının sorununuz değişmeyecek, ve hatta daha da artacaktır, zira diğer VT'leri Client Connectionlarındaki bellek kullanımları daha da fazladır.

FB'de sorun aramayın, FB'yi kullanan öyle yerler var ki adamlar 400 GB civarı Database'i olan yerler var, Almanya'daki bir haber alma ajansında günde binlerce dokuman kaydı yapılıyor sisteme, database'in boyutunu varın tahmin edin. Ama adamlar takır takır kullanıyorlar (dünyanın her yerinden erişilebilir durumda)

Örnekler daha da arttırılabilir. Sorun emin olun yazdığınız veya kullandığınız programla alakalıdır.

Kolay Gelsin

Not : Eğer bir BUG varsa (ki sizden önce bulmuşlardır)

[Kuri_YJ]

Selamlar,

ProcessPriorityLevel = 1
DefaultDbCachePages = 16384
SortMemBlockSize = 4194304
SortMemUpperLimit = 1073741824

Bu değerlerdeki SortMemUpperLimit'i düşürün. 1 GB vermişsiniz. Sort işlemleri için bu kadarına gerek yok, bunun yerine DefaultDBCachePages'i arttırın öyle denemelerinizi yapın. DBCachepages'isi atıyorum 80,000-100,000 gibi bir şey yapın. Server'ı bir durdurup-başlatın bakalım performansta neler değişecek (muhtemelen iyileşme olacaktır) ama sorun çözülmemiş olacaktır. Sadece sabunlamış olacağız

Ancak bir önceki mesajımdaki söylediklerim hala geçerli. Bu kadar kullanıcı ile bu kadar connection'ın açılması konusunda bir yerlerde bir sorun var demek.

[serkan]

Hocam bende forumda sormuştum bikaç soru firebird kilitleniyor diye filan.yazdığım sql kodlarına bakarak bikaç index tanımladım sorum giderildi.Öyleki stok hareketleri 25.000 kayıt iken problem yok 30.000 olduğunda ağırlaştı.index çaktım problem düzeldi.sende istersen bi bak bakalım böyle bir durum sözkonusumu diye.

[rsimsek]

WHERE içinde kullanılan alanlar da indekslenmeli

[mkysoft]

Her şeyi düzeltiğini varsayarak bence işletim sistemi seçimi hatalı. Gerçi kullanıcı sayısı o kadar fazla değil ama ziraat bankasının oracle veri tabanı micrsoftun işletim sisteminin gelen isteklere geç cevap verdiği için problem çıkartmıştı zamanında. Bildiğim kadarıyla zaten firebird öncelikli olarak linux destekli olarak geliştiriliyor. Böyle bir proje için ben olsam öncelikle servera linux yüklerdim. Hem kurulum maliyeti düşerdi.
Benim aklıma gelen bir başka konu bu bilgisayar büyük ihtimalle sadece veri tabanı sunucusu olarak kullanılmıyor. Aynı zamanda bir active directory, proxy server işleri içinde kullanılıyor olabilir. Belki bu ekstra uygulamalar nedeniyle problem yaşıyordur.