FireBird 2.0 Alpha Notları

[Kuri_YJ]

Aynı anda mesajları göndermişiz,

Bahsettiğin rakamlar küçük sayılmaz ama ilginç olan şu, 18 MB'yi geçmemiş, aşılabiliyor diyorsun ama bence 18 MB anlık bir şey olabilir ve Windows kaynaklı olabilir diye düşünüyorum.

5 Milyon kayıtlık bir Query'den sonuç dönüyor ve hiç bufferlamıyor (cache etmiyor alet) Yani Memory'de cache etmiyor.

Yazdığın kodu yollar mısın ben bir deneyeyim 100 connectiondan daha fazla kurayım kendi 5 mio'luk table'ıma query'ler göndereyim.

MSN'in açık ise ordan gönderebilir misin.

Sağolasın

[fduman]

Oo sen de yollamışsın. Ulaştım hocam. Nerdeyse 19MB. Olay şu FB Engine aldığı belleği işi biter bitmez anında geri veriyor. Çok şahane. Bayıldım bu database e. (Zaten bayılıyordum )

Aslında performance counter ile düşük interval li bir bellek izlemesi yapayım. Sonuçlar daha net belli olur.

Abi 100 kullanıcıda bana mısın demiyor yaw. Başka VT olsa bu fetch'lerde 4GB ram yetmiyor diye bağırırdı.

[fduman]

Kuri_TLJ. Yazılımı bitirdim. Ancak evde geliştirdiğim için kodları evde unuttum Yarın sana ulaştırırım.

Bu arada FB'e IBX componentleri ile Thread yaratmada karşılaştığım sorunun çözümü ile ilgili bir makaleyi siteye ekliyorum. Benden sonrakiler aynı hataya düşmesin.

Kolay gelsin.

[Kuri_YJ]

Selamlar,

Peki denemelerinde Memory hiç 50 - 60 MB'lara vurdu mu?

Kolay Gelsin

[fduman]

150 eşzamanlı connection ile ufak bir VT de 28 MB a ulaştım. Belki sen denediğinde daha da yükseltebilirsin.

Yanlız 150 thread'den fazlası bir PIII 850'yi çok kastırıyor. Connection açma ve commit kastıran şeyler. Programın başında threadler yaratılırken ve sonunda threadler sonlandırılırken 100 thread için 1-2 dakika kadar bir bekleme süresi olabiliyor.

[Kuri_YJ]

Selamlar,

Ben Ms-SQL Serverda yaptığım denemelerde alet ne kadar varsa alıp götürüyordu, ancak yeni yapılan bir değişiklik var sanırım (MS-SQL Server Enterprise Edition'da) Alet tutuyor 80-90 MB'a yayılıyor daha sonra memory'de daha fazla yer kaplamıyor amaaaa arka tarafta kullanılan belleğe bakıyorus 3 GB bellek Serverda kaplanmış ama MS-SQL Server kendisi 80-90 kullanıyorum diyor (örtbas etmişler ) Hhehehehehehe...


Firebird'de tutsa ve belleği biraz sömürse iyi olmaz mı? Belki bu 28 MB threadler için filan oluşmuş bi halt olabilir, yani bilemiyorum alet GB'lık veri tabanını yönetirken 16 civarında dolaşıyor sorun da çıkarmıyor.

Allah Allaaah, FB'yi yapanlar OZ Büyücüsü mü? MS'inkiler ne yapıyorlar, Kingston ile anlaşmaları mı var bu yazılımcılarının?

Ben hala FB'nin Veri tabanını yönetirken 16 MB'ın üzerini kullanmadığını düşünüyor ve diretiyorum. En fazla yani 16 MB'ın üzerine çıkmasına sebep kendine bağlı kullanıcıları yönetirken ihtiyaç duyduğu connectionlar sebebi ile kullanılıyordur. Yani yine de VT'yi yönetirken alet 16 MB'ın üzerini kullanmıyor !....

Ama senin göndereceğin kodları ben de deneyeceğim ve abartacağım büyük ihtimalle. Birkaç kullanıcıdan 1000 kadar connection açmayı düğünüyorum (yani en az 1000-2000 civarı bir connection ile random Query'ler çektireceğim Kayıt sayısıda muhtemel 16,000,000 civarı olacak.

Hadi bakalım ne olacak

[fduman]

Haklısın Kingston ve Intel ile anlaşmaları var herhalde

Neden daha fazla RAM kullanmasını istediğini anlayamıyorum. Demek ki bir formül bulmuşlar ve bu işi en az RAM ihtiyacı ile halletmişler. Üstelik GB VT'de hiçbir sorunu da yok diyorsun. İstediğin performansı yakalayamıyor musun? SQL Server ile karşılaştırdığında daha fazla sorgulama süresi var? Yavaş mı kalıyor?

Yani merak ettiğim bu isteğin neden kaynaklanıyor? Fazladan RAM'in var da harcamak mı istiyorsun?

[Kuri_YJ]

Derdim aslında şu,

FB RAM kullanımını minimize ederek performans sağlıyor, MS-SQL Server kaçak dövüşüp, RAM'i kullanıyor, yani yaptığı iş eğer bellekte ise yanıtı verirken bir öncekine göre daha hızlı yanıt veriyor.

Yani, MS-SQL Serverda bir tane Query yazın ve getirme süresine bakın, sonra ard arda o query'i defalarca çağırın, sürenin giderek kısaldığını göreceksiniz. Yani alet, DATA'yı belleğine bindiriyor, hiç disk işlemi yapmadan belleğinde hallediyor, ama karmaşık Query'ler (yani her defasında farklı Tablolardan Farklı DB'lerden query'ler yolladığınızda belleğine yükleyemediği için performansı bozuluyor.)

Şimdi FB'de aynı taktiği biraz uygulasa fena olmaz, zaten hızlı bir veri tabanı, ama bir de bu taktiği kullanarak hızını katlasa fena olmaz mı sizce?

Ne dersin CoderLord?

[fduman]

Hmm. Cache'lesin diyorsun. Bana zaten yapıyormuş gibi gelmişti. Aynı Query'yi FB'de üst üste çağırdığımda ilkine nazaran daha hızlı getirmiş gibiydi. Bana mı öyle geldi?

Eğer böyle bir özelliği yoksa ki emin değilim olup olmadığı konusunda, haklısın, eklenmesi kesinlikle çok faydalı olur.

Aslında yapılması kolay değil gibi. Transaction değişikliklerine göre yeniden sorgu yapıp yapmamaya karar vermesi lazım. Yani mesela cache'ler ama sen result'ı değiştirecek bir update yaparsın. Bu değişikliğe göre yeniden sorgu yapması lazım falan... Ya hakikaten bunu yapıp yapmadığını nereden anlarız? Geliştiricilerine sorsak?

[Kuri_YJ]

Zaten benim derdim de orda FB'nin Cache'lemesi ancak ve ancak İşletim sisteminin Disk okumasındaki cache'lemesi ile sınırlı.

Yani İşletim Sistemi okunan sector'leri belleğinde Cache'lediği için FB diskten okuma yapacağı zaman (ki aslen diskten okumaya çalışıyor) İşletim sistemi uyanıklık edip bunu bellekten yanıtlıyor.

Benim dediğim bu Sector'leri cache'leyen işletim sistemine ek olarak, FB'de diske sorup sormayacağına, belleğindeki Cache edilmiş Sayfalara bakıp karar verirse, İşletim sistemi arasında geçen bekleme süreleri de minimize edilir.

Böylece büyük DB'lerde gerçek anlamda performans artışı sağlanabilir diye düşünüyorum.

Tabi hala benim bu düşüncel tez olmaktan öte değil ama bu kullanılan bir yöntem. Ben de bu sebeple FB geliştirmenlerine Feature Request olarak geçtim.

Bilmem anlatabildim mi?

Kolay Gelsin

[onaydin]

Merhaba
Adnan bey windows un görev yöneticisindeki fbserver.exe nin bellek kullanımı (umarım doğru yere bakıyorumdur)
bir kullanıcı, basit bir query ve yaklaşık 10 bin satır için, indexlenmemiş 4-5 alan order by içine katıldığında 26mb olarak gözüküyor.
Başka denemelerimde 70 mb ı da gördüm.

[Kuri_YJ]

Selamlar,

Windows sürümü kaç, FB sürümü ne, işletim sistemi yapılandırması nasıl?

Ben 16,000,000 kayıtlık bir tabloda daha 16 MB'ın üzerine çıkamadım, ne indexi var ne de primary key.

Sendeki ayarları ve durumu söylersen ben de bakayım.

Kolay Gelsin

[Kuri_YJ]

Selamlar,

Test bilgilerim şöyle,

Kod: Tümünü seç

RECREATE TABLE TEST_ADNAN
(
  TEST_ID              INTEGER,
  KOD                  VARCHAR(    20) CHARACTER SET WIN1254  COLLATE PXW_TURK,
  ADI                  VARCHAR(    50) CHARACTER SET WIN1254  COLLATE PXW_TURK,
  SOYADI               VARCHAR(    50) CHARACTER SET WIN1254  COLLATE PXW_TURK,
  TELEFON              VARCHAR(    20) CHARACTER SET WIN1254  COLLATE PXW_TURK,
  SAYI1                INTEGER
);

Table'da Random olarak üretilmiş 500,000 Kayıt vardı bu Random 5000,000 Kaydı kendi içine insert ederek 16,000,000 Kayda ulaştırdım.

Yalnız TEST_ID alanı 16,000,000 unique (tekil) 1'den 16,000,000'a kadar birer birer artan sayı şeklinde.

Sorgu cümlesi şu şekilde,

Kod: Tümünü seç

SELECT * FROM TEST_ADNAN WHERE ADI LIKE 'ADL%'

1 dakika 49 saniye sorgulama süresi ve hiç kayıt dönmedi.

Hiç index yok, primary key yok.

Bellek kullanımı 12 MB civarında sabit, CPU Kullanımı %22-30 arasında gidip geldi.

İlginç değil mi?

Kolay Gelsin

[Kuri_YJ]

Selamlar,

Maalesef tezlerim kuvvetle doğrulandı CoderLord'un hazırlamış olduğu test programı ile (Kendisine ayrıca burada teşekkür etmek istiyorum) 1000 Thread ile deneme yaptım, 16,000,000 Kayıtlık bir tabloda indexsiz, primary key'siz bir tabloda sorgulama yaptım.

150 MB bellek kullandı, %50 CPU kullandı.

500 Thread ile 98 MB Bellek Kullandı
100 Thread ile 30 MB Kullandı.

Yani her connectionda biraz daha bellek arttı ama VT boyutunun hiç bir etkisi olmadı !...

FB VT'yi cachelemiyor. Bir deneme daha aklıma geldi. Index oluşturup deneyeceğim.

Not : Bu denemelerin aynısını FB 2.0'da da denedim değişen bir şey olmadı.

[gkimirti]

sp den select yaptıgınızda memorynin cok daha fazla tuketildigini goreceksiniz.
normalde 4 kayıt donduren bir sp yi
( select id from sp_preport(0,null,null,2005,0,0,0) )
kriter olarak kullanınca

( select * from preport r
where r.id in (select id from sp_preport(0,null,null,2005,0,0,0)) )

task manager dan baktıgımda 33 MB kullanıldı gorunuyor.
acaba DBWorkbench ile daha farklı bir sonucmu cıkıyor.
ne kadar Bellek kullanıldıgını nasıl goruyırsunuz?