database'te Performans problemlerim.

[cecihan]

Merhaba arkadaşlar. aslında forumda bir çok yerde konuşuldu. bir kısım önerileri de elimden geldiğince uyguladım ama.
Bundan yaklaşık 5 yıl önce bir devlet laboratuvarı için komik denebilecek bir bedelle yeni bir projeye başladım. Daha öncede firebird ile hiç sıkıntım olmadığı ve çok çetin şartlarda test ettiğim için SQL motoru olarak firebird'ü seçmiştim. Proje c++builder'le ve fibplus ile yazıldı.
Projede 2-3 yıl hiç bir sıkıntımda olmadı. Ama ilk başta 10-15 olan client sayısı 50ye, tablo sayısı 60'lara, sadece tanımlar varken database büyüklüğü 400 mb'a, yılda 1000 tane gelen numune sayıları günde 400'e çıktı. önceden raporlar her seferinde database'den yeniden üretilirken şimdi üretilen raporlar ayrı databasede saklanıyor. o database zaten 3 gb oldu. 3-4 yıllık tüm kayıtlarda tek databasede saklanınca clientler oldukça yavaşladı. Çalıştığım kurum özerk bir kurumken 2 yıl önce sağlık bakanlığına bağlandığı için bilgi işlem desteği, bir şey satın almak veya tamir ettirmek vs oldukça zorlaştı. Fiziksel bir takım sıkıntılarında yavaşlığa neden olabileceğini düşünüyorum. tabii ilk başta program daha bir hoyrat yazılırken ( herşey datasetler üzerinden düzeltilmeye çalışılırken, select * ile kayıtlar çekilirken ) artık mümkün olduğunca daha optimize yollar seçiyorum.
Çeşitli ayırmalar, sqlleri elimden geldiğince optimize etmeler vs. ile idare ediyorum ama yakın bir gelecekte doküman yönetimide devreye girecek. bu yapıda bile Firebird beni hiç yüz üstü bırakmadı, hiç çökmedi ama database dahada büyüdükçe performansı nasıl iyileştirebilirim. Zannetmiyorum (ve o kadar kodu değiştirmek herhalde ölüm olur.) ama şu meşhur paralı bir sql' geçmek bir çözümmüdür.

[Battosai]

şu meşhur paralı bir sql' geçmek bir çözümmüdür

Çözüm değildir. Ayrıca geçiş işi çok zor olur.

Bağlantı sayısı ve buna bağlı olarak sql sorguları işlemci yükünü artınca mecburen paralel genişlemeye gidilmesi gerekiyor. Yazılımsal müdahale yanında donanımsal genişlemede yapılmalıdır. Veritabanı açısından genel formül load balancer(yük dağılımı) yaparak sorguları farklı db hatta farklı sunucu üzerine yönlendirerek sistem yükünü dengelemekdir. Yapılması zahmetli ve tecrübe isteyen bir iştir. Kısa vadede client programda sadece lazım gelen yerde gerekli miktarda kayıt çekerek ve donanımsal performansı arttırarak çözüm bulabilirsiniz.

[Kuri_YJ]

Selamlar,

Yük dağılımı konusunda DB'nin veya DB'lerin CPU'lara dağıtımı gibi işlemleri de gerçekleştirebilirsiniz. Bilmiyorum bunları denediniz mi?

DB'de kullanılan FB Versiyonu kaçtır? İşletim sisteminiz nedir? 32 Bit / 64 Bit. Kullandığınız makinenin işlemci sayısı ve çekirdek hızları, Hard diskler nerede? Network yapısı nasıl?

Performansa etkiyen çok madde var. Bunları gözden geçirmek gerek. Ayrıca, bazı püf noktaları da mevcut bunlar üzerinde çalışma yaptınız mı?

Yeriniz nerede? İstanbul filan mı? Donanımı/yazılımı ve ortamı görmek söz konusu mu? Belki bazı tavsiyelerde bulunabilirim.

Kolay Gelsin
Adnan

[Kuri_YJ]

firebirdsql.org adresindeki case studylere bakarsanız dokuman yönetimi ile ilgili ürün kullanımı hakkında da bir örnek mevcut.

http://www.firebirdsql.org/en/case-stud ... sses-9892/

[cecihan]

veri girişinin çok olacağı uzak bir ildeki üniversiteye satış yapma ihtimalim var. Birde İstanbul'dakiler yavaşlıktan şikayet edince acaba yanlış yolda mıyım. zararın neresinden dönsek karmıdır? gibi düşüncelerim olmuştu.
İstanbuldaki müşterim yedi kule göğüs hastanesinin bahçesinde. server çift xenon işlemcili bir server. raid 5 yapılmış bir diski var. ama sanallaştırmayla 1 işlemcisi bana ayrılmış durumda. işin ilginç tarafı sadece benim program çalışır kaldı. birde file sharing yapıyorlar. diğer programların (personel vs.) çalıştığı serverların hepsi işlevsiz kaldı. server'ı ben hiç görmedim. hep uzaktan bağlandım. işletim sistemi 64 bit Windows 2008. serverda 64 bit firebird 2.5 çalıştırıyorum.
önceden programıma girişler bu kadar yoğun değildi. ayda 1000 civarıydı. her numuneyi sisteme girmiyorlardı. şimdi her gün en az 300 kızamık numunesi geliyor en az.
kurumda önceden özerk bir kurumdu. 2.yılı sağlık bakanlığına bağlı. o yüzden kurumun yeniden yapılanması biraz yavaş oluyor.
yok zaten sizin yazdıklarınızdan sonra kafamda bir soru işareti kalmadı. eğer sağlık müdürlüğünü ikna edebilirsem fiziki şartlarda biraz daha iyileştirme isteyeceğim. bazı çok kullandığım select ifadeleri view'lara çeviriyorum. vs. vs. firebird ile yola devam.

[Kuri_YJ]

Selamlar,

64 Bit FB kullanıp hız problemi yaşaman da ayrıca ilginç. Çünkü bahsettiğin DATA öyle ahım şahım bir data değil. Benim yazdığım bir sistemde acayip yoğun bir trafik mevcut ve FB bunu kotarıyor, hem de 32 Bitte.

firebird.conf dosyasında hiç değişiklik yaptın mı? Çekirdek tayini, Page Size, DBCaches, Affinity gibi. Yapmadıysanız bu ayarlamaları yapın.

Ha bu arada hem sanalda çalışıyorsunuz hem de 1 CPU verdiler demek. Peki CPU'daki çekirdek sayısı ve çekirdek hızı konusunda bilgi nedir? Size ayrılmış olan Bellek Miktarı?

Kolay Gelsin

Adnan

[cecihan]

doğruyu söylemek gerekirse firebird.conf' da hiç ayarlama yapmadım. ilk kurulum konfigürasyonu. konuyu çok ayrıntılı bilmiyorum. bu konuda okuduğum bir iki yazı ile kafam daha çok karışmıştı. araştıracağım.
zaten sizin işlediğiniz datayı başka iletilerde okuyunca 'hımm sıkıntı bendeymiş, bir şeyleri yanlış yapıyorum.' dedim.
çekirdek sayısı ve hızlarını oraya gittiğimde 2-3 gün içinde öğreneceğim.

[Kuri_YJ]

Selamlar,

Muhtemelen bu performans ayarlarını yaptıktan sonra ortaya çıkacak sonuçları paylaşmak isteyeceksiniz.

Firebird.conf sizin sisteminizin daha fazla bellek kullanması daha fazla CPU kullanması gibi özellikleri ayarlayabildiğiniz bir ayar noktasıdır.

Makinenin tam konfigürasyonunu söyeyecek olursanız size ayar yapabileceğiniz noktalar hakkında bilgi verebilirim.

Kolay Gelsin
Adnan

[cecihan]

maalesef ki satanda, sistemi kuranda kurumdan ayrılmış. öğrenebildiklerim:
makinada
2 x xenon E5520 2.27 Ghz işlemci var.
benim sanal makinamda Windows 2003 server 64 sp1 ve 2 gb ram var. ama kaç çekirdek bana verilmiş göremedim.
Edit:Cpuz ile baktım. Her iki işlemciden de 1 çekirdek vermişler.

[Battosai]

İşlemci yeterli sayılır. 2 gb ram çok düşük.

[Kuri_YJ]

Selamlar,

firebird.conf'u açıp,

Aşağıdaki bölümü bulup

Kod: Tümünü seç

# ----------------------------
# Number of cached database pages
#
# This sets the number of pages from any one database that can be held
# in cache at once. If you increase this value, the engine will
# allocate more pages to the cache for every database. By default, the
# SuperServer allocates 2048 pages for each database and the classic
# allocates 75 pages per client connection per database.
#
# Type: integer
#
DefaultDbCachePages = 524288

DefaultDbCachePages kısmına bellekte her bir Database için ayırmak istediğin bellek sayfası sayısını yazın.

Örnek hesaplama,

Database'inizin PageSize'ı 8 K ise ve 64 Bit İşletim sisteminde her bir Database (FDB Dosya için) kullanmak istediğiniz Page Sayısı 65536 olduğunu var sayarsak,

Firebird, İşletim sisteminden 8 * 65536 = 524,288 K (Yani 0.5 Gig RAM tüketecektir.)

Aynı şartlarda, PageSize'ınız 4 K ise, o zaman

Firebird, İşletim sisteminden 4 * 65536 = 262,144 K (Yani 0.25 Gig RAM tüketecektir.)

Tabi FDB Dosya boyutunuz bu miktarlardan büyük ise. Böylelikle Firebird'ün, disk IO'sunu düşürebilirsiniz edebilirsiniz ve daha fazla bellekte işlem yaptırabilirsiniz. Ama bu ayarı yaparken şu hataya da düşmeyin,

Elinizde 4 Tane FDB Dosya hepsinin page size'ı 8 K var ve hepsi çeşitli uygulamalar tarafından kullanılmakta. İşletim sisteminiz 64 bit, ve makinenizin belleği 2 GB.

Siz kalkıp, DefaultDbCachedPages'i 131072 yaparsanız (hesabını kendiniz yaparsınız) o makine cortlar. Windows Swapping'e bir girer bir daha da iflah olmaz.

Dikkat edeceğiniz husus, verilen bu değer ile, toplam kullanılan Database sayısını ve toplam kullanılabilir fiziksel belleği taşırmamak ve Windowsu Swapping'e sokmamaktır.

Buna göre hesabınızı yapın belleği Firebird'e maximum kullandıracak şekilde yapılandırmaya çalışın bakalım. Sonra oradaki başka püf noktalardan da bahsedeceğim.

Mesela Database Page Size'ı neye göre belirlenmeli?

Kolay Gelsin
Adnan

[cecihan]

Merhaba.
En başta yardım eden moderatorlerimize defalarca çok teşekkür ederim.
Adnan bey.bugün forumda bir hayli sizin yazılarınızı okudum.
en başta database pagesize'ım 16384'tü. onu sector size ile aynı 4096'ya düşürdüm.
CpuAffinityMask'ı 3 yaptım.
DefaultDBCachePages değerini de 131072 yaptım. ve server'ı resetledim. kullandığım fdb dosyası sayısı şu an 2. Doküman yönetimi,kalite vs. ile anca 3-4 olur. bakalım sonucu yarın göreceğim.

[Kuri_YJ]

Selamlar,

Sunucuya ayrılmış bellek miktarını mümkünse 2 GB'dan daha yukarılara taşıyın. Madem 64 Bit bir işletim sistemi var, sömürün makinenin belleğini. Olabildiğince çok bellek almaya çalışın.

Yalnız Affinity Mask için, sizde kaç çekirdek var?

3 Demek = Çekirdek 1 ve 2 yi kullan demek olur. Bu da aslında sizin için şu anlama gelir.

Toplamda 2 DB var olduğu için, FB şöyle bir tercih yapacak, DB'nin bir tanesini 1 Çekirdeğe, diğerini de 2. Çekirdeğe assign edecek.

4096 PageSize ve 131072 CachPage demek de 512 MB her bir DB için kullanacak demektir. Eğer Sunucunun RAM'ini arttırırsanız CachedPage'i de arttırabilirsiniz.

Ayrıca Index ve Sorting İçin Cachelemeler var ama önce bakalım buralardan nasıl bir yanıt alacaksınız.

Nasipse yarın görürüz inşallah.

Kolay Gelsin
Adnan

[Kuri_YJ]

Selamlar,

Madem araştırıyorsunuz,

viewtopic.php?f=18&t=581&hilit=Performans+Index

Buradaki performans hakkında 10 yıl önce yazdığım bir yazı var onu okuyun ve Database'inize bir de bu açıdan bakın. Ancak 10 Sene önce yazmışım Oraya daha ekleyeceklerim var aslında da bir ara vakit bulup yazayım veya toparlayım yazayım

Çünkü indexlerde bazı metodlar var onları tırmalaya tırmalaya öğrendim ve benim yazdığım indexler ile sorgu çekip query analyze planina baktığımda genelde Seek sırasında eriştiği kayıt sayısında 1 görüyorum Yani tam anlamıyla Nokta Atış

Tabi yazdığım query'lerde yıldırım hızıyla çalışıyor ve performans sıkıntısı çekmiyorum (çok şükür).

Kolay Gelsin
Adnan

[anemos]

Selamlar,

.... Ancak 10 Sene önce yazmışım Oraya daha ekleyeceklerim var aslında da bir ara vakit bulup yazayım veya toparlayım yazayım
...

Merakla bekliyoruz.