Firebird config ayarları

[Terminator]

## E.g.:
# TempDirectories = c:\temp
# or
# TempDirectories = c:\temp;d:\temp
# or
# TempDirectories = c:\temp 100000000;d:\temp 500000000;e:\temp
#
# Type: string (special format)
#
#TempDirectories =

işte ilk performans bileşenlerinden biri.
varsayılanda sistem TMP TEMP dizini kullanılır.
mesla C:\WINDOWS\TEMP dizininde sürekli random isimli dosyalar yaratılıp siliniyorsa bilin ki FB sortlamak için diski kullanıyor, bu işlem için tanımlı RAM yeterli gelmiyor. ayrıca db niz de C: diskinde ise veya aynı fiziksel diskte ise way halinize..
performans için neler yapılabilir, bu açıklamadan sonra arif olan anlar.

@Terminator kardeş burada şöyle bir ariflik yapmak isterim hasbel kader Perfomansın ilk basamağı; işletim sistemi ile veritabanının aynı diskte olmaması, disklerin de ayrı ayrı kanallarda olması (IDE ise İşletim sistemi Birincil-Primary, VT İkincil-Secondary kanallarında). Sayfa boyu / PageSize ile ilgili daha önce de yazdığım şöyle bir tekniği de hatırlatmak isterim; işletim sistemleri de fiziksel diske ulaşırken diskten bilgileri malum bit bit yada bayt bayt okumaz. Bunun bir ölçüsü var. Windows ve Linux işletim sistemlerinde bu 512 bayt lık birimler halindedir. Dolaysıyla sizin bir bayt lık dosyanız da disk üzerinde en az 512 bayt yer kaplar (küme / cluster boyu kadar). Fakat büyük dosyalarda bu olay okuma perfomansını azaltacağından bu 512 nin katları küme / cluster olarak bir araya gelerek bir seferde okunacak birimi oluşturur. Bu da 512 den 64 K ya kadar 512 nin katları şeklinde değişir (512, 1024, 2048, 4096, 8192, 16384, 32768, 65536). Küme boyu arttıkça perfomans artar, yer israfı artar. Tersi durumda da yer israfı azalır perfomans da azalır. Şimdi burada önemli olan işletim sisteminin küme yapısı ile veritabanı sayfa boyunun uyumlu / senkron olmasıdır Eksik veya yanlışım varsa düzeltelim

Recep bey,
olay kısmen anlattığınız gibi, ama daha komplike.
sen eğer 4K lık sayfalar kullandığın bir sistemi 512 bytelık blokları olan bir ortamda tutuyorsan yanmışın demektir. Netekim şirketteki yüzeysel linux hayranlarına bile bunu yeni açıklamak zorunda kaldım.. yani neden FB yavaş çalışıyor linuxda..
kafanda her türlü olasılığı değerlendiren senaryolar üret ve simule et.
yani aynı sisteme 512 byte yazanlar, 4k yazanlar 1 k yazanların olduğu..
ne olur sence?
biri hanyada biri konyada olan 8 adet sektörün ordan burdan devşirilip bir araya getirilip FB ye teslim edilmesi demektir bu.
512byte olan bir diskte 4k lık bir blogun hiçbir sektoru yanyana olmaz yeni bile formatlanmış olsa. birkaç saat sonra arapsaçına döner.
ayı şey tersi için de farklı sorunlar yaratır.
OS un, donanımın, derleyici ve araçların çalışma detaylarını bilmeyerek iyi bir sistem geliştirilemez. sadece kanserojen, kaotik, ucube ürünler olur.
Oracle gibi tüm sistemi sömüren rami tüketen sistemler bu tip dertleri belki daha geç yansıtır.
konuyu, zagorun açtığı diğer soru topicinde açıklamaya çalıştım.
İyi çalışmalar.

[rsimsek]

Ben de zaten ikinci diskteki tercihimi işletim sistemi tarafından daha az parçalanma / fragmante olması için, hem de küme / cluster larla VT bloklarının uyumlu olması gerektiğinden bahsetmiştim. Yine de VT motorunun bu sayfa yapılarını / PageSize ve blokları nasıl organize ettiğini bilmeden tercihi tam tespit etmek zordur Perfomans için fiziksel tarafta ikinci disk yanında IDE, SATA ve SCSII tercihlerini, hatta RAID düşünmek, mantıksal tarafta da OS ile VT ilişkisini iyi kurgulamak gerekir diye düşünüyorum

[Terminator]

FB diğer VT sistemleri kendi dosya sayfalarını, işletim sisteminin clusterlarını takip ettiği gibi eder.
Mantıksal olarak neler yaptığı farklı olabilir ama fiziksel olarak durmadan bazı sayfaları okur bazılarını da yazar.
İdeali en az okuma yazmayı yapması, en az dosyayı kullanmasıdır.
Yani sınırlı sistem kaynaklarını tıkamadan kullanmalıdır.
Mekanik disk sistemleri, RAM-CPU yani northbridge grubundan binlerce kat yavaş çalışır. Böyle olunca, sınırlı performanstaki bir disk mekaniğine daha fazla iş yüklemek, daha farklı işleri paralel yaptırmaya çalışmak ağır yüktür, tıkanıklığa neden olur.
Çözüm, mekanik sistemin sayısını artırıp yükleri dağıtmaktır.
Yani bir diskte rahat rahat OS çalışmalı kendi logları, pagingi vs için.
Bir başka diskte sadece aktif DB dosyası olmalı.
Bir başka diskte DB serverin ihitiyacı olan geçici dosyalar işlem görmeli.
Tabi bu disklerin tümü en hızlısından olursa iyi olur.
Yani 15000 rpm UW360 SCSI ve yüksek cache. ya da SATA2 vs.
bu arada hypertransport gibi tekolojiler de bu hıza büyük katkı sağlar.
Sistemde tıkanıklık yaratan cihaz veya proses bulunmamalıdır.
düşünün, arızalı bir kart var ve sürekli IRQ üreterek sistemi gizlice oyalıyor... ya da bir tane openGL ekran koruyusu yüklenmiş, sistem onun görüntüsünü hazırlıycam çizicem derken esas işine zaman ayıramıyor.
ya da aptalca bir antivürus kurulmuş sisteme DB dosyası değiştikçe virus taraması yapmaya kalkıyor. ya da system recovery GDB dosyasını (windowsun kullandığı bir system soyadı olduğu için) sürekli yedeklemeye çalışıyor...
vs vs..
yani performansın sihirli tek bir formülü yok, sistem bir bütündür.
böbreklerinizle koşmazsınız ama böbrek acısı çeken bir insanın atlet gibi
koşmasını bekleyemezsiniz. hatta oldugu yerde bile kıvranabilir.
ya da babannenize nike da giydirseniz hızlı yürüyemez. karl lewise de takunya giydirseniz hiç koşamaz. vs vs..

[rsimsek]

Detay arttıkça masraf da artıyor ya Ciddi anlamda bir yük altındaki sunucu için tabi ki bunlara dikkat etmek lazım. Kullanılan sunucu PC tabanlı da olsa sunucu tabanlı da olsa yanlış mimarinin sorumlusu olarak VT yi görmemek, fiziksel ve mantıksal gereklilikleri eksiksiz yerine getirmek gerekir

[Terminator]

Unutmamanız gereken gerçeklerden biri:
yanlış ayar, bir yerden hız kazandıracak gibi görünse de yanlış hesap ve bilinçsiz kullanım yüzünden tam tersi sonuç da üretebilir.
yani yapacağınız bir RAM kullanım artırımı OS VM pagingi de artırabileceği için daha kötü performans bile alabilirsiniz. her zaman dediğim gibi,
bilgisayar-digital teknoloji sizin rastgele ve bilinçsizce kurcalamanızla
optimize edilecek birşey değildir. Önce öğrenin, kabiliyet kazanını. inanın öğrenince en ufak bir ayar için bile günlerce düşünüp hesap yapmayı başladığınızı göreceksiniz. Önemli olan, para eden şey, vida sıkmak değil, hangi vidayı ne zaman ne kadar sıkacağını bilmektir. bunu iyi bilmek için de en az o vidayı tasarlayıp oraya koyanlar kadar iyi bilmelisiniz sistemi.


# ----------------------------
# In-memory sorting module
#
# The amount of memory allocated for each sort block.
#
# Type: integer
#
#SortMemBlockSize = 1048576


Performans ayarıdır.
order by group by gibi doğal kayıt ve index sırası dışında bir sıra ile
kayıt istediğinizde vs, bunu yapabilmenin tek yolu geçici bir alana atıp sıralamaktır. bunun için bellek ayırmadıysanız, TEMP dizininde geçici isimle bir dosya yaratarak yapacaktır, yazacak ve okuyacaktır, transactionınız kapatıldıgında siler bir sorun yoksa.
işte bu değer, sort işlemi için her istekte allocate edilecek RAM blok değeridir. varsayılan 1MB normaldir, çook büyük data ve sistemler kullanıp özel sıralamalı sonuçlar üretiyorsanız büyütün yoksa 48 umara ayakkabı giymeniz size hız kazandırmaz. küçük küçük kayıtlarla, dinamik bir kullanım tarzınız varsa küçültme durumu da faydalı olabilir.

#
# The maximum amount of memory to be allocated by the in-memory
# sorting module.
#
# For Classic servers, this setting is defaulted to 8 MB.
# Although it can be increased, the value applies to each client
# connection/server instance and thus consumes a lot of memory.
#
# Type: integer
#
#SortMemUpperLimit = 67108864

Sort bloklarının toplam kapasitesini verir.
yani varsayılandaki ayarlarla 67 tane 1 MB RAM kullanılabilir. yetmezse
disk dosyası kullanacaktır. Çok fazla kullanıcınız ve RAMiniz varsa ve
çok fazla sortlanan-query kullanıyorlarsa artırmak performans demek.
mesela OLAP, data mining tarzı uygulamalarda sortlama çok olacaktır.
çok fazla tablodan sorgulamalarda da genelde sortlu sonuç istenir

# ----------------------------
# Backward-compatible parameter ordering as it was in FB v1/IB
#
# Type: boolean
#
#OldParameterOrdering = 0

Bunu kullanmanıza gerek yok, yapılan bir geliştirmeyi iptal edip, eski uygulama exelerini değiştirmeden kullanmaya devam ettirmek isteyenler için bir imkan.

[Terminator]

Arkadaşlar,
bir süre forumu takip edemiycem.
Görüşürüz.