firebird performans için
firebird performans için
Sel.al arkadaşlar firebird 1.5 ve d7 de bi proje geliştirdik.şuan için gözle görülür bi yavaşlama yok ama belli bölümelerimde kayıt sayısı fazl aolan tablolarımda bazı yavaşlamalar başladı.vt boyutu 145 mb kayıt sayısı 300 bin civarında.page size ım 8192 yalnız vt de bazı tablolarımda 2000 karakterlik alanlarım var.ve firebird ü kurduğum serverımda (2003 server.)herhangi bi ayar yapmadım firebird le ilgili.sormak istediğim şey page size ımı tam olarak benim projemde nasıl olması gerektiğini nasıl hesaplarım.birde server da fire birdle ilgili herhangi bi ayar yapmam lazımmı performans için(projemde sp trigger index kullanıyorum.forumdaki kaynaklardan faydalandım.)bu konuda yardımlarınızı bekliyorum arkadaşlar iyi çalışmalar
Sayfa boyu/PageSize ın işletim sistemi küme/cluster boyutu ile aynı olması gerekiyor diye biliyorum.. Daha önce epey konuşuldu 
Tabi ki en önemli etken vertabanı yapısını uygun şekilde tasarlamak.. Arama yapılan alanların indeksli olması.. SP ve sorgularda gereksiz alanların döndürülmemesi, mümkün olduğunca karakter işlemlerden çok sayısal bilgilerin döndürülmesi vs.. Son kısım şu demek bir kaç SP birbirini çağırıyor da stok adı en sonunda size lazım fakat diğer SP lere sadece girip çıkıyorsa bu bir kambur 
Tabi ki en önemli etken vertabanı yapısını uygun şekilde tasarlamak.. Arama yapılan alanların indeksli olması.. SP ve sorgularda gereksiz alanların döndürülmemesi, mümkün olduğunca karakter işlemlerden çok sayısal bilgilerin döndürülmesi vs.. Son kısım şu demek bir kaç SP birbirini çağırıyor da stok adı en sonunda size lazım fakat diğer SP lere sadece girip çıkıyorsa bu bir kambur Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!
Performansla ilgili probleminiz VT'den ziyade kullanıcı arayüzü (Client programı) ile ilgili.
Siz VT'nizde performansı ne kadar arttırırsanız arttırın, kullanıcı arayüzünde uygun bir dizayn yapmadıysanız bu problem artarak devam edecektir. Öyle bir dizayn yapmalısınız ki kullanıcı bir tablodan hiçbir zaman belirli bir kayıttan fazlasını görme gereği hissetmeyecek ve siz de ona o kadar kayıt göstereceksiniz.
Örneğin bir tablo düşünün devamlı büyüyor ve siz kullanıcıya bu tablonun tamamını gösteriyorsunuz. Kullanıcının yeni bir kayıt girdiğini düşünün. 100 kayıtta sorun yok. 1000 kayıtta yarım saniye bekliyor. 10 bin kayıtta 5 saniye 50 bin kayıtta 50 saniye 200 bin kayıtta artık çay veya yemek molası vermesi gerekiyor. Bu biraz abartılı gibi gelse de Paradox tabloları dışında maalesef üç aşağı beş yukarı bu şekilde.
Tabi bunun için kullandığınız komponent, VT de çok önemli. Ben şahsen dbExpress kullanmanızı tavsiye ederim.
İyi çalışmalar.
Siz VT'nizde performansı ne kadar arttırırsanız arttırın, kullanıcı arayüzünde uygun bir dizayn yapmadıysanız bu problem artarak devam edecektir. Öyle bir dizayn yapmalısınız ki kullanıcı bir tablodan hiçbir zaman belirli bir kayıttan fazlasını görme gereği hissetmeyecek ve siz de ona o kadar kayıt göstereceksiniz.
Örneğin bir tablo düşünün devamlı büyüyor ve siz kullanıcıya bu tablonun tamamını gösteriyorsunuz. Kullanıcının yeni bir kayıt girdiğini düşünün. 100 kayıtta sorun yok. 1000 kayıtta yarım saniye bekliyor. 10 bin kayıtta 5 saniye 50 bin kayıtta 50 saniye 200 bin kayıtta artık çay veya yemek molası vermesi gerekiyor. Bu biraz abartılı gibi gelse de Paradox tabloları dışında maalesef üç aşağı beş yukarı bu şekilde.
Tabi bunun için kullandığınız komponent, VT de çok önemli. Ben şahsen dbExpress kullanmanızı tavsiye ederim.
İyi çalışmalar.
hakan bey programın arayüzünü tasarlarken çok dikkatli çalıştığımıza inanıyorum.öyleki kullanıcı programda sadece ihtiyac duyduğu zaman ihtiyac duyduğu verileri alıyor.component olarak ibx kullanıyrum.tablolara kayıtları hazırladığım insert queryleriyle giriyorum.sorgu vb olaylarda sp kullanıyorum(sadece ihtiyac duyduğum alanları alıyorum.).serverdan gereksiz hiç bir veri çekmiyorum.bunun yanında güncelleme ve silme işlemlerimide yine hazırlamış olduğum sql lerle yapıyorum(queryler içine yazılmış sorgularla.update ve delete sorguları.) şuan için öyle ciddi bi performans kaybı yok .ben ilerisi için fikrim olsun istiyorum.serverda bi yapılması gereken bişey varmı diye.
Komut satırında c:\>chkdsk demeniz yeterli. Fakat benim de söylediğim ve @Hakan Can arkadaşımızın örneklediği şekilde ince ayarlara gelmeden önce yada bu tür bir ayarlama ile perfomans beklemektense iyi bir tasarımı yapmak gerekirmeron06 yazdı:Peki recep abi işletim sisteminin kümesinin kaç olduğunuz nasıl bulacağız.
Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!
Aslında en güzeli basit bir program yazıp kayıt sayısını belirli miktarlarda arttırıp bizzat görerek test etmeniz olacak.
Ben bu testi defalarca yaptım. En kesin çözüm bu olacaktır.
Karşılaştığım en büyük sorunlardan bir tanesi belki de aşılması en zor olanı da VT belirli bir boyuta geldikten sonra VT'ye ilk bağlanmanın bile çok uzun sürmesi idi ki bu 17 dakika gibi insanı çileden çıkartacak bir süreydi. Test ettiğim bilgisayarlar da iyi bilgisayarlardı.
Özetle; bir noktadan sonra işiniz çok zorlaşıyor.
En güzeli 1 yıllık, 5 yıllık, 10 yıllık, 20 yıllık ve son olarak da 50 yıllık veri girerek test yapmanız olacaktır. Yaptığınız tasarımın (hem VT tarafında hem de Client tarafında) doğruluğu tam olarak 50 yıllık testte çıkacaktır.
İyi çalışmalar.
Ben bu testi defalarca yaptım. En kesin çözüm bu olacaktır.
Karşılaştığım en büyük sorunlardan bir tanesi belki de aşılması en zor olanı da VT belirli bir boyuta geldikten sonra VT'ye ilk bağlanmanın bile çok uzun sürmesi idi ki bu 17 dakika gibi insanı çileden çıkartacak bir süreydi. Test ettiğim bilgisayarlar da iyi bilgisayarlardı.
Özetle; bir noktadan sonra işiniz çok zorlaşıyor.
En güzeli 1 yıllık, 5 yıllık, 10 yıllık, 20 yıllık ve son olarak da 50 yıllık veri girerek test yapmanız olacaktır. Yaptığınız tasarımın (hem VT tarafında hem de Client tarafında) doğruluğu tam olarak 50 yıllık testte çıkacaktır.
İyi çalışmalar.
Böyle 17 dk. da açan bir VT yi görmek, incelemek isterdimHakan Can yazdı:...
Karşılaştığım en büyük sorunlardan bir tanesi belki de aşılması en zor olanı da VT belirli bir boyuta geldikten sonra VT'ye ilk bağlanmanın bile çok uzun sürmesi idi ki bu 17 dakika gibi insanı çileden çıkartacak bir süreydi. Test ettiğim bilgisayarlar da iyi bilgisayarlardı.
.....
5 yıldan fazla süreleri hesaplamanın hiç bir mantığı yok. Çünkü sene değil altı ayda teknoloji değişiyor, gelişiyor. O Yüzden onca uzun vadelerde atomik yapıya mı kuark yapıya mı gelinir bilemeyiz... Belki de hiç bilemiyeceğizHakan Can yazdı:...
En güzeli 1 yıllık, 5 yıllık, 10 yıllık, 20 yıllık ve son olarak da 50 yıllık veri girerek test yapmanız olacaktır. Yaptığınız tasarımın (hem VT tarafında hem de Client tarafında) doğruluğu tam olarak 50 yıllık testte çıkacaktır.
...
Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!
yavaşlayan tablomu akşam bi ara inceleyeyim dedim.ve çok dikkatsiz ce yaptığım bi hatayla karşılaştım.tanımlaıdğım indexlerin birinde hata yapmışım.index düzenledikten sonra yavaşlayan tablomda sanki 1000 kayıt varmış gibi hızlı ve rahat çalışıyor.yinede server tarafında yapılacak bişey varsa bilmek isterim.mesela vt nin yüklü olduğu serverda gereksiz işlemleri durdurmak.firebird yapılacak ayarlar vb.
17 dakikada açılacak VT'nin özellikleri:rsimsek yazdı:Böyle 17 dk. da açan bir VT yi görmek, incelemek isterdimHakan Can yazdı:...
Karşılaştığım en büyük sorunlardan bir tanesi belki de aşılması en zor olanı da VT belirli bir boyuta geldikten sonra VT'ye ilk bağlanmanın bile çok uzun sürmesi idi ki bu 17 dakika gibi insanı çileden çıkartacak bir süreydi. Test ettiğim bilgisayarlar da iyi bilgisayarlardı.
.....
5 yıldan fazla süreleri hesaplamanın hiç bir mantığı yok. Çünkü sene değil altı ayda teknoloji değişiyor, gelişiyor. O Yüzden onca uzun vadelerde atomik yapıya mı kuark yapıya mı gelinir bilemeyiz... Belki de hiç bilemiyeceğizHakan Can yazdı:...
En güzeli 1 yıllık, 5 yıllık, 10 yıllık, 20 yıllık ve son olarak da 50 yıllık veri girerek test yapmanız olacaktır. Yaptığınız tasarımın (hem VT tarafında hem de Client tarafında) doğruluğu tam olarak 50 yıllık testte çıkacaktır.
...
1200-1250 civarı tablo. 300-400 tanesi birbiriyle ilişkili hele 5-10 tanesi nerdeyse bu 300-400 tablonun hepsi ile ilişkili (direk veya dolaylı).
Günde 1-5 milyon kadar kayıt giriliyor (program tarafından bilhassa raporlama amaçlı tablolara) ve neredeyse o kadar da kayıt siliniyor.
VT'nin boyutu 1-10 GB arasında değişebiliyor. Tabi gün geçtikçe artıyor.
Bazı tabloların kayıt sayıları milyonlara ulaştığı ve kayıt silip kaydetme hadisesi arttıktan bir müddet sonra bu problem ortaya çıkıyor. Tabi backup-restore yapmayı tavsiye edeceksiniz. Bir noktadan sonra backup restore 1 saati geçiyor ve yine bir noktadan sonra backup-restore da para etmiyor.
50 yıllık teste gelince aslında bence bu bile az. Zira hiçbir yazılımcı yaptığı ticari entegre programını sadece bakkallar kullansın diye hayal ederek yapmaz. Ben şahsen böyle bir programı yaparken Kozyatağı Carrefour'da da kullanılabileceğini düşünerek yaparım. Tabi Kozyatağı Carrefour demek sıradan yüz tane market bin tane bakkal demek. Ama benim o kadar büyük hayallerim yok diyorsanız ona birşey diyemem.
Teknolojik gelişmeler tabiki yazılımcıların lehine oluyor gibi ancak örneğin VT geliştiğinde VT'yi üst versiyona yükseltmek bazen aleyhte sorunlar doğurabiliyor. Tabi asıl önemlisi işi şansa yani teknolojik gelişmelerin insafına bırakmak ne kadar doğru bir yaklaşım onu da sorgulamak gerekiyor.
Neyse fazla uzatmayayım. Bunlar benim şahsi görüşlerim (kendi yaşadığım tecrübeler sonucu oluşan).
İyi çalışmalar.
Selamlar,
firebird.conf dosyasında önemli (aslında hepsi birbirinden önemli) ince ayar noktaları var.
Firebird'ün kurulu olduğu dizinde bir adet firebird.conf isimli bir text dosya mevcut. Bunu herhangi bir Text editor ile açın ve en alt satırına,
ProcessPriorityLevel = 1
yazın. Bu sayede Firebird, işlemlerde bulunduğu makinanın kaynaklarını sonuna kadar kullanacaktır. CPU Priority'i yüksek düzeye çıkartmış olursunuz ki, bu da sizin Firebird'ün çalışırken sistemi sonuna kadar kullanmasına yarar. Bir çok database serverda bu Priority High durumdadır. FB'de ise kullanıcıya bırakılmıştır. Eğer makinanızda başka bir şey çalışmıyorsa (yani SERVER makina) FB serverlığı yapıyorsa tavsiye ederim. Özellikle tavsiye ederim.
Bir diğer ekleyebileceğiniz satır, Memory kullanımınızla alakalı olacaktır. Yani Eğer makinanızda uygun Bellek varsa, Page sayısını ayarlayarak, performansınızı arttırabilirsiniz. Bunun için ise, yine firebird.conf dosyasına aşağıdaki satırı eklemelisiniz.
DefaultDbCachePages=nnnnnn
Dikkat burada nnnnnn yazan yere sizin Server'da FB'nin kullanması için ayıracağınız bellek miktarıyla doğru orantılı bir sayı gelecektir. Örnek olarak, PageSize'ınız 8192 Byte ise, ve 128MB bir alanın FB tarafından (Cache'lenmesi için) kullanılmasını isterseniz, 128 * 1024 * 1024 / 8192 = 16384 yazmalısınız, yani,
DefaultDbCachePages=16384
Bu satır ile FB'ye Cacheleme alanı olarak 128 MB Bellek kullanmasını söylemiş olursunuz ki, Performansı arttıran önemli kriterlerden biridir. Eğer 512 MB Bellek ayırmak isterseniz, o zaman da,
512 * 1024 * 1024 / 8192 = 65536'yı buluruz. Bunun gibi sizin makinanızın belleğine göre ayarlama yapabilirsiniz.
Ayrıca,
SortMemBlockSize ve SortMemUpperLimit ile Indexlemelerde (veya index işlemleri yaparken) ne kadarlık bir bellek alanının kullanılmasına izin verdiğiniz ayarlardır ki, bunlarda da yapacağınız değişikliklerle performansınızı arttırabilirsiniz. Ancak DefaultDBCachePages ve CPU Priority size çok önemli performans artışları sağlayacaktır.
Denenmiştir ve çok olumlu sonuçlar alınmıştır. Ancak dediğim gibi bunu yaparken hesaplamalrınızı doğru yapmalısınız. Eğer 512 MB makinada 512 MB Cache pages verirseniz, Windows otomatik olarak SWAP dosyalara abanacaktır ve siz performans beklerken, yerlerde sürünen bir database'iniz olur. Dikkatli yapın.
Bu ayarların aktif hale geçirilmesi için ise, FB servisini Stop/Start yapmalısınız. Her değişiklikten sonra Stop/Start ile bu değişiklikler aktif hale gelecektir.
Kolay Gelsin
firebird.conf dosyasında önemli (aslında hepsi birbirinden önemli) ince ayar noktaları var.
Firebird'ün kurulu olduğu dizinde bir adet firebird.conf isimli bir text dosya mevcut. Bunu herhangi bir Text editor ile açın ve en alt satırına,
ProcessPriorityLevel = 1
yazın. Bu sayede Firebird, işlemlerde bulunduğu makinanın kaynaklarını sonuna kadar kullanacaktır. CPU Priority'i yüksek düzeye çıkartmış olursunuz ki, bu da sizin Firebird'ün çalışırken sistemi sonuna kadar kullanmasına yarar. Bir çok database serverda bu Priority High durumdadır. FB'de ise kullanıcıya bırakılmıştır. Eğer makinanızda başka bir şey çalışmıyorsa (yani SERVER makina) FB serverlığı yapıyorsa tavsiye ederim. Özellikle tavsiye ederim.
Bir diğer ekleyebileceğiniz satır, Memory kullanımınızla alakalı olacaktır. Yani Eğer makinanızda uygun Bellek varsa, Page sayısını ayarlayarak, performansınızı arttırabilirsiniz. Bunun için ise, yine firebird.conf dosyasına aşağıdaki satırı eklemelisiniz.
DefaultDbCachePages=nnnnnn
Dikkat burada nnnnnn yazan yere sizin Server'da FB'nin kullanması için ayıracağınız bellek miktarıyla doğru orantılı bir sayı gelecektir. Örnek olarak, PageSize'ınız 8192 Byte ise, ve 128MB bir alanın FB tarafından (Cache'lenmesi için) kullanılmasını isterseniz, 128 * 1024 * 1024 / 8192 = 16384 yazmalısınız, yani,
DefaultDbCachePages=16384
Bu satır ile FB'ye Cacheleme alanı olarak 128 MB Bellek kullanmasını söylemiş olursunuz ki, Performansı arttıran önemli kriterlerden biridir. Eğer 512 MB Bellek ayırmak isterseniz, o zaman da,
512 * 1024 * 1024 / 8192 = 65536'yı buluruz. Bunun gibi sizin makinanızın belleğine göre ayarlama yapabilirsiniz.
Ayrıca,
SortMemBlockSize ve SortMemUpperLimit ile Indexlemelerde (veya index işlemleri yaparken) ne kadarlık bir bellek alanının kullanılmasına izin verdiğiniz ayarlardır ki, bunlarda da yapacağınız değişikliklerle performansınızı arttırabilirsiniz. Ancak DefaultDBCachePages ve CPU Priority size çok önemli performans artışları sağlayacaktır.
Denenmiştir ve çok olumlu sonuçlar alınmıştır. Ancak dediğim gibi bunu yaparken hesaplamalrınızı doğru yapmalısınız. Eğer 512 MB makinada 512 MB Cache pages verirseniz, Windows otomatik olarak SWAP dosyalara abanacaktır ve siz performans beklerken, yerlerde sürünen bir database'iniz olur. Dikkatli yapın.
Bu ayarların aktif hale geçirilmesi için ise, FB servisini Stop/Start yapmalısınız. Her değişiklikten sonra Stop/Start ile bu değişiklikler aktif hale gelecektir.
Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/