Firebird Pagesize

[ibrahimcoban]

Merhaba Arkadaşlar !
Bir projemde Firebird kullandım ve çok memnun kaldım.
Pagesize 1024 Kb sanırım default, bunu 4096 ya çıkarmak istiyorum,
var olan database de pagesize nasıl değiştirilir ve performansa katkısı
bulunur mu? İşletim sistemi Win2000 Server ve 1024 Ram

[Kuri_YJ]

Selamlar,

Terminator size daha detaylı bilgi verir büyük ihtimalle ama aydınlatıcı olmasından pagesize olayından bahsedeyim.

Pagesize, kayıtların yazılacağı page'lerin sizelarını belirtir. Pagesize dikkatli kullanılması gereken bir ayardır, yoksa performansınızı düşürebilir.

Örneğin 1 kaydınızın boyutu 950 Byte tutuyor ise sizin page size'ı 1024 tutmanız performansınıza olumlu etkisi olur, ama sizin 1 kaydınızın boyutu 1100 byte ise o zaman 1024 kullanmak, hem fazlalık yer hem bellek kaybına yol açacaktır. Her kayıt için 2 page kullanacaktır (Terminator umarım yanlış yada değişmiş bir bilgi vermiyorumdur) Benim page size ile ilgili okuduklarımdan çıkardıklarımı söylüyorum.

Bu durumda Pagesize'ınızı daha büyük tutmanız daha iyi olur. Ona göre sizin pagesize'ı ayarlamanız gerekmekte.

4096 pagesize FB 2.0'da default geliyor diye biliyorum. Max. 16K'ya kadardı.
Bu söylediklerime göre siz kayıt boyutunuzu hesaplayıp, ona göre pagesize belirlemeniz gerekir. Ayrıca şöyle bir şart yok, sakın yanlış anlaşılmasın, illa ki her kayıt bir page'e gelecek diye bir kural yok.

Aıyorum sizin kayıt boyutunuz 100 Byte, o zaman 1 page kaç kayıt sığarsa o kadar kaydı o page'e saklar. Taşma olursa bir başka page'e geçer.

Bahsettiğim hesaplamalar özellikle kayıt boyutu büyük tablolar için geçerlidir.

Şimdi mevcut DB'nin page size'ını ben şöyle bir yöntem ile değiştiriyorum. Normal backup alıyorum daha sonra Restore ediyorum (DBWorkbench ile) orada bana soruyor pagesize'ı ne olsun diye. Ben de yeni Pagesize'ı verip Restore ediyorum.

Bu yöntem dışında pagesize'ı değiştirmenin başka bir yöntemi var mıdır bilmiyorum. Bilenler anlatırsa biz de öğrenmiş oluruz.

Kolay Gelsin

[fduman]

Pagesize sadece backup restore yöntemi ile değiştirilebiliyor.

[Terminator]

PageSize, veritabanı dosyası işlemlerindeki blok boyudur.
Yani FB, DB dosyasını o blok hacmindeki işlemlerle yönetir,
kısaca paging bellek yönetim sisteminin birimidir pagesize.
Bilgisayarlar paging yöntemiyle çalışır, bu, kareli defterimizin kareleri gibidir. bir kareden daha küçük bölme ya da büyük bölme olmaz, ama birden çok kare tek bir işlem için kullanılabilir. Bu, RAM için de geçerlidir,
DISK için de geçerlidir.
Diskinizi formatladığınızda, boyuyla orantılı olarak bir pagesize belirler windows(bunu daha yeni yeni kararverebilmeye başladı kerata ne hikmetse) eskiden bi ara windows 2000 kurduğumuzda büyük bir diske mesela sapıtıp 512 Byte formatlayabiliyordu. 1 blok, yani cluster yani OS disk page i 1 segment olunca clusterları takip etmeye çalışmaktan imanı gevriyodu. aynı sorun haala var, mesela NTFS e convert ettiğinizde, uyanık MS mühendisleri akıllıca bi yöntemle, her sektör=1 cluster yapıverip, taşıma, düzeltme yapmadan, NTFS e çeviriverir ve olan makinanıza olur.
Bu clusterlar yani blocklar, kayıt alanında tek tek takip edilir, sizin bir dosyanız, kendisini saklamakta olan cluster numaralarıyla takip edilerek okunur, ya da yazılır.
Bu anlattıklarım OS siteminin disk paging yönetimiydi.
Aynı şekilde, VT sistemleri de kendi dosyalarını benzer bir mantıkla yönetirler. Yani db page, OS disk pagelerin daha üst katmanındaki bir mantıksal bellek yönetim katmanıdır.
Bir örnek vereyim, kafanıza yerleşsin:
FB diyelim ki, 35. sayfasına erişmek istedi ve pagesize 4096.
FB OS'a bre gafil, bana dosyamın 4096*34 inden itibaren 4096 byte ver bakayım hadi bakayım koçum deh dee! der.
OS napar?
hay hay ejderham, dur getirem, sen aççık bekle der, bu mekanik disk milletine güven olmaz, sen öteki işlerine bakadur der.
OS gider File tablosundan açık olan o dosyanın clusterlarını taramaya başlar. nasıl tarar? 4096*34. noktasına erişecek şekilde.
ve sonra da bulduğu noktadan 4096 byte okumak için gerekli clusterları öğrenir. disk 4096 formatlıysa tek bir noktaya erişip o clusteri okur ve teslim eder aha al gözün doysun! der.
ama diskin 1024 formatlıysa 4 tane cluster okuması gerektiğini bilir, yani istenen byte sayısını verecek kadar cluster okumak zorunda. yok efendim ben sadece 37 byte okuyayım diye bişey yok. bunu sadece RAW modde fiziksel operasyonarla yapabilirsiniz, bir sistem kullanıyorsanız onun kendi kuralları vardır, gidip segmentin yarısını, clusterin üçte birini okumaz, detaya girmez, girmesi de saçma olur zaten. Bir de DBcachebufferinizin RAMde pagesize boyunda blocklarla çalıştığını bilmeniz lazım.
Şimdi bu anlattıklarım ışığında 4 ihtimalli bir durum var.
1. FBFile pagesize < OS blocksize
2. FBFile pagesize > OS blocksize
3. FBFile pagesize = OS blocksize
4. Ben bunları bilmek zorundamıyım kardeşim dayarım M$SQLimi dersiniz.

Umarım açıklayıcıdır, çalakalem yazdım breh breh breh..

[Terminator]

Ve unuttuğum açıklama,
bir veritabanında bir sürü tablo ve kayıt boyu vardır.
Benim görüşüme göre, pagesize kayıt boyuyla değil, önceki mesajımda açıkladığım gibi çalıştığı ortam, kaynaklar, ihtiyaçlar ve koşullar ile belirlenir. indexlerin, blobların, sistem tablolarının, transaction vs bilgilerin hepsinin aynı sayfaboyu yönetimiyle tek bir birim hacim üzerinden takip edildiğini bilmek gerekir.
Bütün bu anlattıklarıma rağmen, ee iyi de abi, sayfaboyumuz ne olsun şimdi? diyen varsa bile, benden başka birine desin.

[rsimsek]

Bu söylenenler neticesinde ben de bildiğim ve daha öncede tekrarladıklarımla özetliyeyim bari Veritabanının Sayfa boyu/PageSize i verimli/perfomanslı bir sistem için İşletim sisteminin küme/cluster boyutu ile uyumlu olmalı. Şu an için bu küme boyu 512 bayt tan 64K ya kadar olabilmektedir. Küçük olması diski en verimli kullanmak anlamındadır. Yer ısrafı en azdır. Büyük olması da perfomans en yüksektir. Çünkü bir seferde okumayla küme boyutundaki dosyayı bir seferde okuması demektir. yoksa 512 bayt lık kümeli bir OS de bu 128 (128x512 bayt = 64K) kere diskten okumak anlamındadır. Netice itibariyle NTFS varsayılan küme/cluster boyutu 4K (8 x 512 bayt) dir. VT sayfa boyununda 4K (4096 bayt) seçilmesi en uygunudur.. Ekstra durumlar sözkonusu ise işletim sistemi küme boyutu da değiştirilebilir. Fakat burada VT nin perfomansı bir anlamdan OS nin perfomansı ile de doğrudan ilişkilidir

Bunların dışında VT perfomansı için VT nin ayrı kanala bağlı bir diskte, en azından dağıtık/fragmante yapıya sebep olmamak için ayrı bir bölüm/partition da olması tavsiyedir

[musti]

yani recep abi sumudur.

Windows 2003 kurdugumuz bir serverde hdd ikiye bolum d: ye firebird kuralim.
page zaten default 4096 tanımlı

[aslangeri]

s.a.
hddyi ikiye bölmekten ziyade ikinci bir hdd kastediliyor olması lazım.
kolay gelsin.

[Terminator]

Faal bir harddiski faal 2 veya daha fazla parçalara bölmek çok saçma bir işlemdir profesyonelce bir uygulama için.
Harddiski ne zaman birden fazla bölebilirsiniz? sadece 1 partisyonu aktif olacaksa, diğer partisyonlar nadiren kullanılan arşivsel amaçlı pasif depo niteliğinde olacaksa uygundur. Yoksa, harddiskin kafası bi o bölgeye bi bu bölgeye erişmekten, siz de bitirsin diye beklemekten helak olursunuz.
Daha önce de dediğim gibi, hardisklerin handikapı, erişime harcanan zamandır. kafanın belli bir tracke konumlanıp istenen sektörleri okuması ortalama 10 ms gibi bir gecikmeye neden olur. Oysa, 7200 devirle dönen bir diskte, aynı trackten bütün sektörleri okumak milisaniye bile sürmez.
1000/7200 milisaniye sürer. yani clusterları büyük vermenizin fiziksel okuma hızını düşüren bi yanı yoktur. ama bir clusterin bir sektörü giderse bütün clusterin okunamayacağını anlamışsınızdır.
büyük blok vermek sadece, dosya sonlarında atıl kalacak (clustersayısı*clusterboyu-dosyanınboyu) gibi bir alan kaybı söz konusudur ki, bu da devede kulak gibidir. diskler çok ucuzdur ve kapasiteleri çok yüksek, disklerden en yüksek beklenti ise hızdır.
hiçbir dosyanın clusterları sıralı okunacak kadar düzenli yerleşmez disk üzerinde. clusterin biri hanyada biri konyda geri kalanlar madakaskar ya da honolulu kıyılarında bile olabilir. Tape ünitelerinin hızlı(!) olma nedeni dosyaları sıralı bir düzende banda manyetik olarak kaydetmeleridir.
harddisk ise, doğrudan erişim imkanı verebilmek için, yüzeyindeki manyetik çizgileri küçük küçük birim parçacıklara ayırır, bunlara numara verir ve bu numaralar, boş veya falanca dosyanın bilmemkaçıncı clusterı şeklinde dosya takip bölgesinde tutulur. siz harddiski ufacık clusterla formatlarsanız, clusterlar pointerlerinin sayısı da o kadar artacaktır, diskten dosyayı ayıklayıp size vermesi, bir sini pirinç ayıklamaya benzeyecektir.
oysa büyük bloklarla bu, bir sini baklavanın güzel kısımlarını seçip yemek kadar kolay olacaktır.
büyük blokların da başka dezavantajları var tabiki bazı durumlar için.
hızlı format dediğimiz şey, bu cluster tablosunun boşa alınması işlemidir.
low level formatda ise, kafa bütün sektörleri tek tek işleme sokarak emin olur ve cluster tablosunu ona göre kesin bir şekilde düzenler.
disklerin ne şekilde çalıştığını incelemek istiyorsanız, bunun için
disketleri kullanabilirsiniz, onlar minyatür harddiskler.
bir diskete aynı anda 2-3 programla değişik yerlerine erişin görün.
aynı işlemler harddisk için de geçerli, üstelik harddiski sizin farkında olmadığınız amaçlarla işletim sistemi ve diğer background uygulamalar da kullanıyor ve sizinle eş zamanla paylaşıyor sürekli, sadee disketten yüzlerce kere daha hızlı o kadar.

[musti]

a.s.
O zaman iki hdd takacaz ve birinci windows yuklu olan 2.hdd ise database.fdb olan olacak.

Firebird 1.hdd mi yoksa database nin oldugunu 2.hdd yi mi kurmak mı mantıklı sizce. yada dogrusu nedir.

Sagolun yine cok guzel seyler ogrendik. Sayenizde.

[rsimsek]

Çok fazla erişim ve sorgu işlemleri gerektirmeyen basit yapıdaki VT leri işletim sisteminin bulunduğu kısıma dahi koymak mümkündür. Fakat orta ve üzeri bir yapı için uygun özellikte ikinci bir diski ikinci kanala takıp VT yi onun üzerine koymak gerekli. Normal kullanımda işletim sisteminin bulunduğu bölüm/partition a koymaktansa hem dağıtık/fragmante ye karşı hem işletim sisteminin çökmelerine karşı ikinci kesime koymak en basit tedbir olarak kullanılabilir. Burada @Terminator un endişelerine katılıyorum. Fakat imkânlar çerçevesinde en uygunu bu. Yoksa bu program sizin bilgisayarınızda çalışmaz ikinci bir disk gerekli dememiz biraz işin durumuna göre zor olabilir. Hatta dizüstülerde bu imkânsıza yakın. Tabi ki bu gerçekten bir Veri Tabanı sunucusu olacaksa tespitlerden taviz vermek uygun değil. Ayrıca OS nin kurulu olduğu ( C: ) bölümünden hemen sonra olması perfomans açısından bir sonraki bölüme göre daha iyi olacaktır. Malum diskte perfomans en dıştaki silindirlerde daha fazladır. İlk bölüm/partititon da en dıştadır. Sonraki onun hemen peşinden gelmektedir. Burada verilen (C: D: E: vb.) harfler sizi yanıltabilir. Çünkü FAT/FAT32 yapısında disk üzerinde bir bölüm varsa işletim sistemin otomatikmen buna C: diyecektir. Dolaysıyla bunun C: olması en dışta olması anlamını taşımaz. Burada dikkatli olmakta fayda var. Yine VT kurulacak bölümün FAT32 formatlı olması disk erişimini artıracaktır. FAT32 dosya yapısı NTFS ye göre pek fazla güvenli değildir. Buna da dikkat etmek gerekir!

FireBird kurulumunun çalıştıktan sonra sürekli kendi dosyalarına erişim yapmıyacağından, yapacak olduğu erişimleri de tamponlayacağından (ki zaten topu topu 3-5 mb. ) farklı bir yerde kurulmasını gerekli görmüyorum

[Terminator]

Hızlandırıcam diye kalkıp diski FAT32 formatlayıp kullanmak isteyeceklerin
FAT32 nin hangi durumlarda neden ve ne oranda hızlı olduğunu da biliyor olması ve FAT32 nin limitlerini ve risklerini kabullenmesi lazım.
Ayrıca, bugünün disklerindeki LBA gibi özelliklere de dikkat etmek gerek.
Mantıksal düzeyde DB sini optimize edip performans sağlayamamış insanlar, sistem düzeyinde denemelerde daha çok rezil olur.

[rsimsek]

Son durum sistem yöneticisinin kararıdır. Bunları bilmesi tabi ki beklenir. Ayrıca PATA, SATA veya SCSI disk mi kullanacak? RADI mi yapacak buna projenin boyutu ve erişim trafiğini gözönünde bulundurarark çözecektir. Bu arada VT yi en iyi şekilde optimize ettiğini varsayıp, fiziksel ortamın iyileştirilmesini tartışıyoruz Belki bunlar VT sayfa boyutu/pagesize dan önce düşünülmesi ve bilinmesi gerekli noktalardır

[Terminator]

>oysa büyük partisyonla bu, bir sini baklavanın...
bunu ben mi yazmışım dalgınlıkla yoksa biri benim yazımı düzelttiğini sanarak editledi mi???

[Terminator]

Son durum sistem yöneticisinin kararıdır. Bunları bilmesi tabi ki beklenir. Ayrıca PATA, SATA veya SCSI disk mi kullanacak? RADI mi yapacak buna projenin boyutu ve erişim trafiğini gözönünde bulundurarark çözecektir. Bu arada VT yi en iyi şekilde optimize ettiğini varsayıp, fiziksel ortamın iyileştirilmesini tartışıyoruz Belki bunlar VT sayfa boyutu/pagesize dan önce düşünülmesi ve bilinmesi gerekli noktalardır

Sistem yöneticisiii?
Bürokratik bir ortamda çalışıyorsun sanırım, hiyerarşi yapmışınız...
Ben program yazmıyorum, DB uzmanıyım dediğimde bilgisayarcılara bile ne işler yaptığımı açıklamak zorunda kaldığım bir ülkede, sistem yönetici sanırım daha anlamlı bir ifade. içinde yönetici geçtiği için karşındaki adamda bir irkilme ve ürkme yaratır, salakça sormaz büyük ihtimalle.
o zaman biz bu işleri, o sistem yöneticisi beylere bırakalım(her kimse bu adamlar) da firebird konuşalım. artık FB yi ilgilendirmeyen konulara girmeme kuralı koydum kendime. Eğitimli bir programcının zaten çok iyi biliyor olması gereken bu konuları konuşmak baydı beni. önceki topiclerde pagesize=disk cluster size dememin yetmesi lazımdı.