Firebird Donanım Rehberi

by Alexey Kovyazin, son güncelleme: 30 Kasım 2015

Firebird teknik destek gruplarında sık sık şu soruyu görebilirsiniz: “Firebird DBMS için donanım tercihi nedir?”. Bu konu kalıcı olarak popülerdir çünkü donanım gereksinimleri görevlere göre değişir ve donanımın kendisi zamanla değişir.

Bu kılavuzu, Firebird veritabanları için gerçekten etkili donanım seçmek isteyen herkese gerekli bilgiyi sağlamak amacıyla yazmaya karar verdik. Bunu yapmak için Firebird’ün, işletim sisteminin ve tabii ki donanımın nasıl çalıştığına dair bazı temel ayrıntıları öğrenmeniz gerekecek.

Bir Miktar Teori

Firebird veritabanınız için hangi donanımın uygun olacağını bulmak için Firebird’ün bileşenlerini nasıl kullandığını anlamamız gerekir: CPU, RAM, HDD/SSD ve bu bileşenlerin işletim sistemiyle (örneğin dosya önbelleğiyle) nasıl etkileşime girdiğini.

Firebird Sunucu Fonksiyonel Modülleri

Öncelikle, Şekil 1 yardımıyla Firebird fonksiyonel modüllerine bakacağız:

Şekil 1. Firebird modülleri

Firebird aşağıdaki ana fonksiyonel modülleri içerir:

Metadata nesneleri: görünümler, tablolar, indeksler, tetikleyiciler, saklı prosedürler ve diğer veritabanı nesneleri. Metadata nesneleri Firebird sürecinin adres alanında bulunur (fbserver, fb_inet_server veya firebird.exe olabilir).
Sayfa tamponları önbelleği, diskten okunan veritabanı sayfalarını içerir ve sunucu sürecinin adres alanında bulunur. Sayfaları önbelleğe alma mekanizması oldukça karmaşıktır, bu yüzden sadece Firebird’ün en sık kullanılan veritabanı sayfalarını önbelleğe aldığını belirteceğiz.
Firebird, tüm eşzamanlı sıralama işlemleri için kullanılan bellek miktarı TempCacheLimit parametresi (firebird.conf) tarafından belirlenen sınıra ulaşana kadar kayıtları bellekte (sunucu sürecinin adres alanında) sıralar. Bu sınır aşıldığında, geçici dosyalar klasöründe (ilgili işletim sistemi bayrağıyla) geçici bir dosya oluşturulur ve sıralama için kullanılır. Sistemde boş RAM varsa, sıralama dosyası işletim sistemi tarafından önbelleğe alınır ve sıralama bellekte gerçekleştirilir.
Global Geçici Tablolar (GTT’ler) işletim sisteminde geçici dosyalar olarak oluşturulur. İşletim sisteminde boş bellek varsa, GTT’lerle yapılan işlemler RAM’de gerçekleştirilir.

Donanımla Temel İşlemler

Firebird fonksiyonel modüllerinin, veritabanlarıyla çalışma sırasında gerçekleştirilen işlemlerde donanım bileşenleriyle nasıl etkileşime girdiğini görelim.

Firebird başlatıldığında, sunucu süreci minimum miktarda RAM kaplar (birkaç megabayt) ve CPU veya RAM ile yoğun işlemler gerçekleştirmez.

Veritabanına bir bağlantı kurulduğunda, sunucu metadata’sını okumaya başlar ve bellekte ilgili nesneleri oluşturur; bu da sürecin, kullanılan tablo, indeks, tetikleyici ve diğer metadata sayısı arttıkça daha fazla kaynak almasına neden olur. Bellek kullanımı artar, ancak bu aşamada CPU pratik olarak kullanılmaz.

İstemci SQL sorgularını (saklı prosedürler dahil) çalıştırmaya başladığında, sunucu donanımı kullanarak ilgili işlemleri gerçekleştirir. Donanımla etkileşimi içeren aşağıdaki temel işlemleri ayırt etmek mümkündür:

veritabanı sayfalarını sabit diskten okuma,
veritabanı sayfalarını sabit diske yazma,
veritabanı sayfalarını önbellekten okuma,
veritabanı sayfalarını önbelleğe yazma,
global geçici tablolardan veri okuma ve yazma,
SQL sorgularını işleme (örneğin, JOIN’ler),
sonuç kümelerindeki kayıtları sıralama.

Bu işlemlerin her biri belirli miktarda sistem kaynağı gerektirir. Aşağıdaki tablo, kaynak tüketimini yoğunluk birimleriyle gösterir (1 en az yoğun, 10 en çok yoğun anlamına gelir):


	Diskten sayfa okuma	Diske sayfa yazma	Sayfa tamponları önbelleğinden sayfa okuma	Sayfa tamponları önbelleğine sayfa yazma	GTT’den okuma	GTT’ye yazma	Kayıtları sıralama	SQL sorgularını işleme
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Disk I/O	10	10	1	1	1	1	1	1

Gördüğünüz gibi, en çok kaynak tüketen işlemler diske erişimi içerenlerdir çünkü diskler, son yıllarda SSD’lerle ilgili ilerlemeye rağmen en yavaş donanım bileşeni olmaya devam etmektedir.

Bu, tamamen donanımla ilgili olan performans optimizasyon yollarından birine yol açar - tüm okuma-yazma işlemlerini RAM’e almak. Ancak sayfa önbelleğini artırma yaklaşımının işe yaramadığını unutmayın. Bu konuyu RAM bölümünde ayrıntılı olarak ele alacağız.

Eşzamanlı Gerçekleştirilen İşlemler

Genellikle, birçok istemciye hizmet verecek bir sunucu için donanım seçmek gerekir, bu yüzden işlemlerin paralelliğinin nasıl uygulandığını anlamak gerçekten önemlidir.

Donanım bileşenleri açısından, CPU’nun, diskin ve RAM’in paralel kullanımından bahsedebiliriz. Modern CPU’lar paralel olarak komut setlerini çalıştırabilen birkaç çekirdeğe sahiptir, bu yüzden DBMS sunucusu işlemleri çekirdekler arasında dağıtır; bu da CPU’nun ne kadar çok çekirdeği varsa, bu sunucuda o kadar çok istemcinin çalışabileceği sonucuna götürür.

Diskler açısından bu o kadar basit değildir. Geleneksel sabit disk sürücüleri (HDD’ler) bilgi okurken, kafayı manyetik malzeme üzerinde sonlu bir hızla fiziksel olarak hareket ettirir. Bir veritabanı oldukça büyük olabilir, yani 3 terabayt boyutunda olabilir ve istemcilerden gelen SQL sorguları diskteki farklı alanlarda bulunan verilere paralel olarak erişirse, diskin kafası diskteki farklı alanlar arasında zıplayarak okuma ve yazma işlemlerini ciddi şekilde yavaşlatır. Bu, disk kuyruğunu önemli ölçüde artırırken diğer kaynaklar (CPU, RAM) boşta kalır. Elbette, disk önbelleği (HDD’nin veya RAID denetleyicisinin önbelleği) bu yavaşlamayı bir dereceye kadar telafi eder, ancak bu yeterli değildir.

Geleneksel HDD’lerin aksine, katı hal sürücüleri (SSD’ler) paralel veri erişimi durumunda performans düşüşüne çok daha az eğilimlidir. Bir SSD’nin avantajı özellikle veri paralel olarak yazıldığında belirgindir - testlerimiz bir SSD’nin bir SATA diskten 7 kat daha hızlı olduğunu göstermektedir (bağlantı!). Ancak, SSD’lerin yavaşlamalardan, erken arızalardan ve veri kaybından kaçınmak için kullanımları sırasında dikkate alınması gereken bazı sorunları vardır (Disk Seçimi bölümüne bakın).

Modern bilgisayarlarda RAM ile işlemler çok hızlı gerçekleştirilir, pratik olarak yalnızca veri yolu bant genişliğiyle sınırlıdır, bu yüzden bu işlemler çok sayıda paralel SQL sorgusu olsa bile darboğaz oluşturmaz.

Veri Akışları

SQL sorgularını çalıştırırken, Firebird çok miktarda veri okur ve yazar, bunları fonksiyonel modüller ve ilgili donanım bileşenleri arasında aktarır. Olası darboğazları belirlemek için veri alışverişinin nasıl yapıldığını anlamamız gerekir. Aşağıdaki Şekil 2 bu konuda bize yardımcı olacaktır:

Şekil 2. RAM ve kalıcı depolama arasındaki veri akışları

Açıkçası, verileri kalıcı depolamadan RAM’e ve geri aktarmak en çok zaman alan işlemdir. Bu, iki veri akışı oluşturur: veritabanı dosyalarından veri sayfalarını okuma/yazma ve sıralama dosyalarını okuma/yazma. Birden fazla sıralama dosyası olabileceğinden ve oldukça büyük olabileceğinden, disklerde oldukça ağır bir yük oluşturabilirler, bu yüzden bu giriş/çıkış akışlarını farklı disklere yönlendirmek tavsiye edilir.

Yedekleme

Firebird size iki yedekleme yöntemi sunar: gbak yardımcı programıyla doğrulanmış yedekleme ve nbackup yardımcı programıyla doğrulanmamış artımlı yedekleme.

Bu yedekleme yöntemlerini birleştirmenizi öneririz: nbackup’ı sık sık (örneğin, her saat, gün ve hafta) çalıştırın ve her gece gbak ile doğrulanmış bir yedek kopya oluşturun.

Hangi yedekleme yöntemini kullanırsanız kullanın, veritabanı dosyası okunur (tamamı veya bir kısmı) ve yedek kopya (tam veya artımlı) yazılır. Yazma işlemleri yedekleme işlemi sırasında sıralı olarak gerçekleştirilir; bu, SATA arayüzlü (HDD SATA) normal ucuz sabit disklerin yedekleme için iyi olacağı anlamına gelir çünkü sıralı olarak oldukça hızlı yazarlar.

Uygun Donanımı Seçme

Artık Firebird’ün donanımla nasıl etkileşime girdiği hakkında fikrimiz olduğuna göre, her bir bileşenin ve özelliklerinin seçimini etkileyen faktörler üzerinde durmalıyız.

Bazen belirli bir veritabanının gerçek istatistikleri donanım bileşenlerinin seçimini güçlü bir şekilde etkiler, bu yüzden bu istatistikleri almak için HQbird’den (IBSurgeon’dan Firebird’ün profesyonel dağıtım paketi) araçlar kullanacağız. HQbird’in deneme sürümünü http://hqbird.com/en/hqbird/ adresinden indirebilirsiniz.

CPU

CPU seçerken aşağıdaki üç şeyi dikkate almalısınız:

Uygulamada hangi sorgular baskındır,
Ortalama ve tepe yüklerde veritabanına aktif bağlantı sayısı,
Firebird sürümü ve mimarisi.

Uygulamada Hangi Sorgular Baskındır?

Firebird her zaman bir sorguyu tek bir çekirdekte çalıştırır, bu yüzden karmaşık ve kötü optimize edilmiş sorgular bir çekirdeği %100’e kadar kullanabilir ve diğer sorguları daha az yüklü çekirdeklere itebilir; çekirdek sayısı ne kadar fazlaysa, tüm CPU’nun kullanılma ve kullanıcıların uygulamada herhangi bir performans düşüşü fark etme olasılığı o kadar düşüktür.

Uygulama ağırlıklı olarak basit kısa SQL sorguları çalıştırıyorsa, tüm sorgular iyi optimize edilmişse ve geçici sorgular (örneğin raporlar için) üretilmiyorsa, CPU performans için bir darboğaz oluşturmaz ve daha az çekirdekli düşük seviyeli bir CPU seçebilirsiniz.

Uygulama bir rapor üreteci veya büyük miktarda veri döndüren çok sayıda yavaş sorgu içeriyorsa, daha fazla çekirdekli bir CPU’ya ihtiyacınız vardır.

Ortalama ve Tepe Yüklerde Veritabanına Aktif Bağlantı Sayısı

Bağlantı sayısı (aktif kullanıcılar) da CPU seçimini etkiler. Ne yazık ki, uygulama geliştiricileri bile belirli bir anda kaç bağlantının, sorgunun ve işlemin aktif olduğu hakkında kesin bir fikre sahip değildir. Bu konuda daha doğru bilgi almak için HQbird’den MON$ Logger aracını kullanmanızı ve çalışırken birkaç anlık görüntü almanızı öneririz; burada kaç bağlantının gerçekten kurulduğunu göreceksiniz.

Şekil 3. MON$ Logger: bağlantı sayısı

Örneğin, burada bağlantı sayısının 296 olduğunu görebilirsiniz. Açıkçası, bu durumda dört çekirdekli bir CPU kullanmak fazla iyimser olurken, 24 çekirdekli bir çözüm oldukça uygun olacaktır. Ayrıca eşzamanlı çalışan sorguların sayısını saymak da tavsiye edilir çünkü bağlantılar herhangi bir SQL sorgusu çalıştırmadan boşta olabilir.

CPU’nuzdaki gerekli çekirdek sayısını kabaca tahmin etmek için 1 çekirdek başına 10 ila 30 bağlantı oranını kullanabilirsiniz. Çoğunlukla karmaşık ve yavaş sorgular içeren bir uygulama için çekirdek başına 10 bağlantı, çoğunlukla basit iyi optimize edilmiş sorgular içeren bir uygulama için çekirdek başına 30 bağlantı.

Firebird Sürümü ve Mimarisi

Firebird sürüm 2.5 kullanıyorsanız, işlemeyi birden fazla çekirdeğe dağıtabilmek için Classic veya SuperClassic mimarisini kullanmanız gerektiğini unutmayın. Sürüm 2.5’te SuperServer mimarisi bir veritabanı için yalnızca bir çekirdek kullanabilir, bu yüzden çok kaynak tüketen sistemlerde kullanılmamalıdır.

Firebird sürüm 3.0’da SuperServer, Classic ve SuperClassic çok çekirdekli CPU’ların özelliklerini kullanır. Firebird 3.0 SuperServer en iyi performansı gösterir.

RAM

RAM seçerken iki şeye dikkat etmelisiniz:

bellek modülü hata düzelten koda sahip olmalıdır (ECC RAM)
RAM miktarı doğru hesaplanmalıdır

ECC RAM

ECC RAM, bellek ile çalışma sırasında meydana gelen hata sayısını önemli ölçüde azaltır ve endüstriyel sistemlerde kullanılması şiddetle tavsiye edilir.

Gerekli RAM Miktarının Hesaplanması

Bellek miktarını hesaplamak için çeşitli Firebird mimarilerinin özelliklerine bakmamız gerekecek. Firebird 2.5 Classic ve Firebird 3.0 Classic, her bağlantıya hizmet etmek için ayrı bir süreç çalıştırır; SuperClassic, her bağlantı için ayrı bir iş parçacığı çalıştırır, ancak pratikte aynı bellek tüketim yapısıyla - her bağlantının kendi bağımsız sayfa önbelleği vardır.

Firebird SuperServer, tüm bağlantılar için tek bir sayfa önbelleği olan tek bir süreç çalıştırır.

Bu nedenle, genel bellek tüketimini etkileyen parametreler şunlardır:

Bağlantı sayısı
Veritabanı sayfa boyutu
Meta veri boyutu (tablo, tetikleyici, saklı yordam vb. sayısıyla orantılıdır; ayarlanamaz; fiziksel kullanıma göre belirlenir)
Classic ve SuperClassic için - bağlantı başına
SuperServer için - açık bir veritabanı örneği başına
Sayfa önbelleği boyutu (veritabanı başlığındaki veya firebird.conf içindeki parametreler veya belirli bir bağlantının özellikleri tarafından belirlenir)
Classic ve SuperClassic için - bağlantı başına
SuperServer için - açık bir veritabanı örneği başına
Sıralama önbelleği boyutu (firebird.conf içindeki parametre tarafından belirlenir). Sıralama için belleğin aynı anda değil, gerektiğinde tahsis edildiğini unutmayın.
Classic için - bağlantı başına
SuperServer ve SuperClassic için - süreç başına (yani tek bir sıralama önbelleği)
Classic/SuperClassic için - kilit tablosu boyutu (genellikle küçüktür, bu yüzden hesaplamamızın dışında bırakacağız).

IBSurgeon şirketi birkaç test gerçekleştirdi ve Firebird sayfa önbelleğindeki sayfa sayısı için bir dizi optimal değer elde etti:

Classic/SuperClassic - 256 ila 2000 sayfa
SuperServer 2.5 - 10000 sayfa
SuperServer 3.0 - 100000 sayfa

Bu testleri temel alarak, 4-6 GB belleğe sahip sunucular için optimize edilmiş Firebird yapılandırma dosyaları oluşturduk. Bunları buradan indirebilirsiniz: /tr/optimized-firebird-configuration/

Gerekli RAM Miktarını Hesaplama Formülleri

Aşağıda, Firebird tarafından gerekecek yaklaşık bellek miktarını tahmin etmek için kullanılan formülleri görebilirsiniz. Gerçek bellek tüketimi farklılık gösterebilir çünkü bu tahmin, meta veriler, dizin bit maskeleri vb. için gereken bellek miktarını hesaba katmaz; bu da bellek tüketimini artırabilir. Ancak, sıralama belleğinin tüm bağlantılarda tam olarak kullanılacağı da varsayılır; bu genellikle böyle değildir.

Veritabanınız zaten kullanımdayken, Firebird sürecinin kullandığı ortalama bellek miktarına (Görev Yöneticisi veya ProcessExplorer yardımıyla) bakabilirsiniz.

Classic için Tahmin:

Bağlantı sayısı * ( (Önbellekteki sayfa sayısı * Sayfa boyutu) + Sıralama önbelleği boyutu )

Classic için örnek: 100 aktif kullanıcı beklediğimizi, veritabanı sayfa boyutunun 8 KB olarak ayarlandığını ve sayfa önbelleğindeki sayfa sayısının 256 olarak ayarlandığını, sıralama önbelleği boyutunun 8 MB’den (Classic ve SuperClassic için varsayılan değer) 64 MB’ye çıkarıldığını varsayalım:

((256.8 KB)+64) = 6600 MB

SuperClassic için Tahmin:

Bağlantı sayısı * (Önbellekteki sayfa sayısı * Sayfa boyutu) + Sıralama önbelleği boyutu

SuperClassic için örnek: 100 kullanıcı, veritabanı sayfa boyutu 8 KB, sayfa önbelleğindeki sayfa sayısı 256, sıralama önbelleği boyutu 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

SuperServer için Tahmin:

(Önbellekteki sayfa sayısı * Sayfa boyutu) + Sıralama önbelleği boyutu

SuperServer (Firebird 2.5) için örnek: 1 veritabanı, 100 kullanıcı, veritabanı sayfa boyutu 8 KB, sayfa önbelleğindeki sayfa sayısı 10000, sıralama önbelleği boyutu 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

SuperServer (Firebird 3.0) için örnek: 1 veritabanı, 100 kullanıcı, veritabanı sayfa boyutu 8 KB, sayfa önbelleğindeki sayfa sayısı 100000, sıralama önbelleği boyutu 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Aşırı Bellek”

Firebird genellikle verimsiz bellek kullanımıyla suçlanır - çalışan sunucu süreci az miktarda RAM tükettiğinde ve belleğin geri kalanı sözde kullanılmadan kaldığında.

Aslında bu doğru değildir. Bu sonuç temel olarak Firebird önbellekleme mekanizmasının nasıl çalıştığının yanlış anlaşılmasında ve işletim sistemi izleme araçlarının kusurluluğunda yatmaktadır.

Her şeyden önce, Firebird’ün işletim sisteminin dosya önbelleğini yoğun bir şekilde kullandığını kesin olarak bilmelisiniz. Bir sayfa Firebird sayfa önbelleğine yüklendiğinde, işletim sistemi dosya önbelleğinden geçer. Firebird bir sayfayı kendi sayfa önbelleğinden boşalttığında, işletim sistemi yeterli boş belleğe sahip olduğu sürece veritabanının bu parçasını RAM’inde tutmaya devam eder.

Şekil 4. Önbellek seviyeleri: Firebird, işletim sistemi ve depolama

Ancak, sadece bakarsanız, işletim sistemi dosya önbelleğine ayrılan belleği kullanılıyor olarak göstermez. Örneğin, Firebird sunucusu çalışırken Görev Yöneticisi tarafından gösterilen tipik bellek dağılımı durumu şöyledir:

Şekil 5. Görev Yöneticisi dosya önbelleği kullanımını göstermez

Sanki 16 GB’ın yalnızca 6,3 GB’ı kullanılıyormuş gibi görünüyor.

Ancak, RAMMap aracını (Microsoft’tan SysInternals) kullanırsanız, her şey çok daha mantıklı görünür:

Şekil 6. RAMMap bellek kullanımı hakkında ayrıntıları gösterir: eşlenen dosyalar önbelleğe alınmış veritabanlarıdır

Veritabanı dosyaları (dbw350.fb252x64.fdb ve dbw250.fb252x64.fdb) işletim sistemi tarafından önbelleğe alınır ve Görev Yöneticisi’nin boş olarak bildirdiği tüm belleği kaplar:

Şekil 7. RAMMap: dosya önbelleği kullanımı hakkında ayrıntılar

Dolayısıyla, işletim sisteminin veritabanını belleğe tamamen yükleyene kadar mevcut tüm belleği veritabanını önbelleğe almak için etkili bir şekilde kullandığı sonucuna varıyoruz.

Disk Alt Sistemi

Disk alt sisteminin doğru yapılandırılması, Firebird için donanım seçiminde ve yapılandırılmasında önemli bir rol oynar çünkü bu adımdaki herhangi bir hata, düzeltilmesi zor büyük arızalara yol açacaktır.

Her Şey İçin Ayrı Diskler

Veritabanı dosyasıyla yapılan işlemler arasında disk giriş/çıkışı için rekabeti azaltmak ve eşzamanlı veritabanı ve yedek kaybı olasılığını azaltmak için üç farklı disk (veya RAID dizisi) bulundurulması önerilir: biri veritabanı için, biri geçici dosyalar için ve biri yedek kopyaların oluşturulması ve saklanması için.

“Ayrı diskler” derken, veri akışlarının farklı giriş/çıkış kanallarından geçmesi gerektiğini kastediyoruz. Bir fiziksel disk üzerinde üç mantıksal disk oluşturursanız, performansta artış olmayacaktır. Ancak, çok kanallı denetleyicilerle donatılmış bir veri depolama aygıtında üç mantıksal disk düzenlerseniz, performans büyük olasılıkla artacaktır çünkü aygıt veri akışlarını denetleyiciler arasında dağıtabilir. Bazen işletim sistemi dosyalarını ve işletim sisteminin takas dosyasını saklamak için ayrı bir disk ayırmanın performansı artırdığı söylenir.

Veritabanı için SSD

SSD, veritabanıyla çalışmak için en iyi seçimdir çünkü paralel giriş/çıkış sırasında büyük ölçeklenme sağlarlar. Artırılmış okuma/yazma döngüsü sayısına sahip kurumsal diskler kullanmanız zorunludur, aksi takdirde SSD arızası nedeniyle veri kaybetme olasılığınız yüksektir.

Bir süre önce, SSD’ler diskte az boş alan kaldığında (%30’dan az) artan aşınmaya eğilimliydi. Basitçe söylemek gerekirse, bir SSD’deki her değişiklik yeni bir boş hücreye yazılır, bu nedenle boş alan eksikliği boş kalan hücrelerin artan aşınmasına ve diskin daha kısa ömrüne yol açtı.

Modern SSD denetleyici üreticileri, bu sorunun statik verileri önleyici olarak taşıyarak çözüldüğünü ve artık hücrelerin aşınmasının az çok dengelendiğini beyan ediyor. Ancak, SSD’lerin kesin teknik özellikleri ve çalışma algoritmaları üreticiler tarafından gizli tutuluyor, bu nedenle yine de SSD’lerde %30 alan boş bırakmanızı, beklenen ömürlerini azaltmanızı ve en az üç yılda bir değiştirmeyi planlamanızı öneriyoruz.

Diyelim ki veritabanınızın boyutu şu anda 100 GB ve ayda 1 GB büyüyor. Bu durumda, minimum boyutta (120 GB) bir SSD satın almamalı, ürün serisindeki bir sonraki cihazı - 250 GB - seçmek daha iyidir. Aynı zamanda, 512 gigabaytlık bir SSD satın almak para israfı olacaktır çünkü diski üç yılda bir değiştirmek tavsiye edilir.

En iyi uygulama, bir SSD’yi yalnızca veritabanıyla çalışmaya adamaktır çünkü herhangi bir giriş/çıkış işlemi disklerin ömrünü azaltır.

Geçici Dosyalar için Disk

Geçici dosyalar yalnızca yeterli RAM olmadığında diskte göründüğünden, en iyi yol elbette bu durumdan tamamen kaçınmaktır. Bir üretim sistemindeki geçici dosyaların sayısını ve boyutunu yalnızca geçici dosyaların bulunduğu klasörü izleyerek değerlendirmek mümkündür. HQbird dağıtım paketindeki FBDataGuard bu tür bir izleme yapar. Disk üzerinde kaç tane geçici sıralama dosyası oluşturulduğunu ve ne zaman oluşturulduğunu öğrendikten sonra, RAM miktarını artırabilecek ve firebird.conf içindeki yapılandırmayı değiştirebileceksiniz.

Her durumda, Firebird geçici dosyaların saklanacağı klasörü belirtmenizi gerektirir. Genellikle varsayılan değiştirilmez, yani işletim sisteminin geçici dosyalar klasörü kullanılır. Boş RAM yeterliyse, bu iyi bir seçimdir.

Ancak, geçici dosyaların disk üzerindeki konumuyla ilgili bir başka önemli konu daha vardır - doğrulanmış bir yedek kopyayı (gbak yardımcı programıyla oluşturulan) geri yüklerken dizinlerin oluşturulmasıdır. Bir dizin oluşturulduğunda, bu dizindeki tüm anahtarları içeren geçici bir dosya da oluşturulur. Veritabanı oldukça büyükse, bazı büyük tablolar için dizinin boyutu da oldukça büyük olabilir. Örneğin, 1 terabaytlık bir veritabanında 3,2 milyar kayıt içeren en büyük tablonun dizini 29 GB’dır, ancak bu dizini oluşturmak 180 GB boş alan gerektirmiştir:

Sistem diskinde boş alan eksikliğini önlemek için, firebird.conf içinde ek ayrılmış alan olarak bir disk daha belirtmek mümkündür:

TempDirectories =C:\temp; H:\Temp

İlk diskte yer yoksa, Firebird geçici dosyalar için ikinci diski kullanmaya devam edecektir ve bu böyle devam eder.

Yedekler için HDD

Yedek kopyaların oluşturulması ve saklanması için SATA veya nSAS arayüzlü normal HDD’ler yeterli olacaktır. Yedek dosyalar için hızlı sıralı yazma ve okuma işlemleri sağlarlar ve boyutlarından tasarruf etmeyecek ve birden fazla yedek kopya tutmayacak kadar ucuzdurlar.

Yedek kopyalar için disklerde her zaman ekstra boş alan bırakılmalıdır: en son yedek kopyanın boyutu + %10. Bu durumda, taze bir yedek kopya oluşturmak, yedekleme işleminin başarıyla tamamlandığından emin olmak (birkaç terabayt boyutundaki bir veritabanı için bu işlem birkaç saat sürebilir) ve ancak bundan sonra önceki yedek kopyayı silmek mümkündür.

Yeni yedek kopya oluşturulmadan önce önceki yedek kopyayı silerseniz, yeni yedek kopyanın oluşturulmaması, eski kopyanın zaten silinmiş olması ve veritabanının örneğin bir disk arızası nedeniyle bozulması olasıdır.

Yukarıda önerilen yedekleme yöntemini kullanıyorsanız (üç seviyeli artımlı yedekleme ve günde bir kez doğrulanmış yedekleme kombinasyonu, yalnızca en son kopyayı saklayarak), yedekleme için minimum alanı hesaplamak için aşağıdaki formülü kullanın:

Veritabanı_boyutu*3+0.2.Veritabanı_boyutu

Yedekleme için gerekli alanın aşağıdaki örnek hesaplamasını ele alalım:

100 GB’lık bir veritabanımız olduğunu ve bunun için üç seviyeli artımlı yedekleme (hafta-gün-saat - her birinden bir kopya) ve günlük doğrulanmış yedeklemenin bir kopyasını sakladığımızı varsayalım. Bu durumda, yedek kopyalar aşağıdaki alanı kaplayacaktır:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (yaklaşık)
Nbackup_level_2.hourly - 200 MB (yaklaşık)
Günlük doğrulanmış yedekleme - 100 GB (yaklaşık)
Ayrıca bir sonraki yedek kopyayı oluşturabilmek için ayrılmış 110 GB’a ihtiyacınız vardır.

Toplam - 316 GB.

! birinci seviye artımlı dosyanın veya daha üstünün boyutu, nbackup’ın son çalıştırıldığı andan itibaren değiştirilen sayfa sayısına bağlıdır. Bu dosyaların boyutu yalnızca deneysel olarak belirlenebilir çünkü veritabanındaki değişiklik miktarı uygulamalara bağlıdır.

Elbette, yedekleme için alan tahmini, veritabanının boyutundaki olası anormal artışı hesaba katmalı ve buna göre boş alan miktarını artırmalıdır; aksi takdirde yedekleme işlemi, alan yetersizliği nedeniyle beklenmedik şekilde kesintiye uğrayabilir.

Doğal olarak, akıllı yedekleme araçları (HQbird’dan FBDataGuard) yedek kopyalar için alan eksikliğini fark edecek ve yöneticiye ilgili mesajı gönderecektir.

Veritabanı için HDD

Bir SSD çok pahalı bir çözüm olabilir veya veritabanı çok büyük olabilir ve daha az maliyetli yöntemler kullanmanız gerekebilir. Bu durumda, SAS arayüzlü bir HDD kullanmalısınız. Bu mümkün değilse, nSAS arayüzlü SATA diskler veya en ucuz seçenek olan normal SATA diskler kullanın.

Sabit disklerin hızını (ve ayrıca güvenilirliğini - aşağıya bakın) artırmak için, bunları RAID10’da birleştirmelisiniz. RAID10, yansıtılmış (RAID1) ve şeritli (RAID0) blokların bir kombinasyonudur. İyi ve doğru yapılandırılmış, büyük önbelleğe sahip bir RAID denetleyicisi, SSD’lere iyi bir alternatiftir.

Güvenilirlik ve RAID

Elbette, disk alt sisteminin güvenilirliğini artırmak için diskleri yukarıda belirtilen tüm varyantlarda RAID’de birleştirmek gerekir (yalnızca geçici dosyalara ayrılmış disk hariç).

• SSD’ler için RAID1 kullandığınızdan emin olun - yani iki yansıtılmış diske aynı anda değişiklikler yazılır, bu da tüm verileri kaybetme olasılığını önemli ölçüde azaltır. SSD’lerden oluşan RAID 10 büyük olasılıkla gereksiz olacaktır çünkü RAID veri yolu verimi sınırlayacaktır. Örneğin, 6 Gbit/s arayüzün verimi saniyede 600 megabayttır ve modern tek SSD’ler zaten bu hıza ulaşmıştır. Böylece, RAID 10 için aynı 600 MB/s sınırını elde ederiz.

Ancak, SSD’leri RAID 10’da birleştirmek için PCI Express 3.0 kullanabilirsiniz çünkü bu veri yolunun verimi zaten saniyede 16 gigabit ve daha yüksektir.

• Yedekleme amacıyla HDD kullanıyorsanız, yedek kopyaların güvenliğini ve kabul edilebilir okuma ve yazma hızını sağlayacak RAID1 yeterlidir.

• Veritabanı için kullanılan HDD’ler, maliyet, güvenilirlik ve performansın optimal kombinasyonunu sağlayan RAID10’da (en az 4 disk) birleştirilmelidir. Bazı kullanıcılar, daha büyük alan için performanstan ödün vererek RAID5 de kullanır.

Firebird için RAID Yapılandırması

Her şeyden önce, RAID’de düzgün şekilde şarj edilmiş bir yedek pil ünitesinin (BBU) bulunduğundan emin olmalısınız. Böyle bir pil ünitesi yoksa, çoğu RAID güvenli yazma moduna geçer (disk önbelleği tamamen devre dışı bırakılır) ve bu, normal bir SATA diskten daha düşük giriş/çıkış hızı sağlar!

Bu durum, pahalı bir sunucu satın alan ve masaüstü bilgisayardan daha yavaş çalıştığını fark eden kullanıcılardan teknik desteğe gelen hayal kırıklığı mesajlarının çoğuna neden olur. Ne yazık ki, bazı satıcılar varsayılan olarak pil üniteleri dahil etmez; bu yüzden kontrol etmeniz ve gerekirse düzeltmeniz gereken ilk şey budur.

Ardından okuma ve yazma önbelleğini yapılandırmalısınız. Genellikle önbellek varsayılan olarak devre dışıdır ve RAID’i oldukça hızlı yapmak istiyorsanız önbelleği etkinleştirmeniz gerekir.

Önbelleği etkinleştirmenin yanı sıra, nasıl çalıştığını kontrol etmelisiniz - write through veya write back olabilir. Önbellekle çalışmanın hızlı yolu write back’tir - bu durumda, tüm değişiklikler önbellek denetleyicisine yazılır ve bir süre sonra doğrudan diske yazılır.

RAID ile birlikte verilen üretici araçlarını pil ünitesini, önbelleği ve modu kontrol etmek için kullanabilirsiniz.

Modern RAID denetleyicileri önbelleği ince ayar da yapabilir - okumayı veya yazmayı kolaylaştırmak için ayarlanabilir. Genellikle okuma ve yazma için %50/%50 olarak bölünür.

Önbelleği tam olarak nasıl yapılandıracağınızı öğrenmek için, gelişmiş HQbird dağıtım paketindeki MON$ Logger aracını da kullanabilirsiniz. Bu araç, okuma ve yazma işlemlerinin birbirine oranını gösterir (sunucuya ilk bağlantı anından itibaren toplanır):

Şekil 8. HQbird MON$Logger: okuma/yazma oranı

Gördüğünüz gibi, bu örnekte okuma işlemleri yazma işlemlerinden çok daha fazladır; bu nedenle RAID denetleyicisini %80 okuma ve %20 yazma işlemi için yapılandırmak mantıklıdır.

SAN ve veritabanları

Entegre depolama sistemleri son zamanlarda popüler hale gelmiştir. Gelişmiş önbellekleme özelliklerine sahip, esnek bir şekilde özelleştirilebilir disk dizilerini (tüm RAID türleri) içerirler. Genellikle SAN’lar, aynı anda birden fazla sunucuya hizmet verebilen ve oldukça hızlı çalışabilen birkaç giriş/çıkış denetleyicisine sahiptir.

Birçok kuruluş SAN satın alır ve Firebird veritabanlarıyla çalışmalarında kullanır. Bir SAN doğru yapılandırılırsa, iyi performans elde etmek mümkündür. SAN kullanıyorsanız aşağıdaki konuları dikkate almalısınız:

Çok kanallı veri alışverişi sağlayan birkaç yüksek performanslı disk denetleyicisi mevcut olmalıdır.
Tasarım gereği sağlanıyorsa, yedek pil üniteleri (BBU) mevcut olmalıdır.
Veritabanı diskleri RAID10’da birleştirilmelidir.
Önbellek etkinleştirilmeli, yazma modu write back’e geçirilmelidir.
SAN’a birden fazla bilgisayar bağlıysa, her birinin kendi denetleyicisi olmalıdır.
En son SAN sürücüleri yüklenmelidir. Daha sonra sağlanan sürücülerin performansta %30 artış sağladığı durumlarla karşılaştık.
Bir SAN üzerinde birden fazla mantıksal disk varsa (veritabanları, yedek kopyalar, işletim sistemi için), bunların farklı giriş/çıkış kanalları vardır. Tüm diskler için tek bir kanal kullanma girişimi daha düşük performansla sonuçlanacaktır.
Benzer şekilde, aynı anda birden fazla sunucu ve veritabanı bir SAN kullanıyorsa, giriş/çıkış denetleyicilerinin artan bant genişliği nedeniyle performans düşebilir.
Birleşik yöntemler sıklıkla kullanılır - işletim sistemi ve geçici dosyalar yerel disklerde saklanırken, veritabanı ve yedek dosyalar bir SAN’da saklanır.

Genellikle SAN’lar, hataya dayanıklı bir küme oluşturmak için “iki sunucu - bir SAN” olarak kullanılır. Böyle bir kümenin, sunuculardan birindeki yalnızca donanım arızalarıyla ilgili sorunları, ikinci sunucuya hemen geçerek çözebileceği belirtilmelidir. Sorun SAN veya veritabanının kendisiyle ilgiliyse, bu çözüm yardımcı olmayacaktır.

Gerçekten hataya dayanıklı bir çözüm oluşturmak için, iki veritabanı örneği arasında veri çoğaltan çözümler kullanmalısınız. Firebird için mevcut daha fazla çözüm hakkında bilgi almak için [email protected] adresinden bize ulaşabilirsiniz.

Kısa Sonuçlar ve Öneriler

Firebird için donanımla ilgili sonuçları ve önerileri özetleyelim.

Çok sayıda kullanıcıya hizmet vermek için çok çekirdekli CPU’lar kullanılmalıdır.
En az RAM miktarı, kullanıcı sayısına ve veritabanı yapılandırmasına göre hesaplanır; fazla RAM miktarı, işletim sistemi tarafından veritabanı dosyasını önbelleğe almak için etkin bir şekilde kullanılacaktır.
Veritabanları, geçici dosyalar ve yedek dosyalar için ayrı diskler kullanın.
Veritabanları için SSD kullanmayı tercih edin.
SSD’lerde en az %30 boş alan ayırın.
Veritabanına bir disk ayırmanız tavsiye edilir.
Kurumsal SSD’ler kullanın (çok sayıda yazma/okuma döngüsüne sahip).
RAID kullandığınızdan emin olun.
SSD için - RAID 1, HDD için - RAID10, yedek HDD için - RAID1. i. SAS, SATA, nSAS
RAID pilinin mevcut ve şarjlı olduğundan emin olun.
Write back moduna geçirildiğinden emin olun.
Bazı RAID denetleyicilerinde önbellek boyutu zaten yapılandırılmıştır, örneğin %75 okuma, %25 yazma veya 50/50 vb. Bu nedenle, RAID parametrelerini kontrol edecek, okuma/yazma oranına bakacak ve RAID ayarlarını değiştirecek MON$Logger yazılımını kurmak gerekir.
SAN kullanmanın artıları ve eksileri vardır. En iyi şekilde yararlanmak için SAN’ı doğru yapılandırmalısınız.
Hataya dayanıklı bir çözüm oluşturmak için, farklı sunucularda çalışan çoğaltmalara sahip çözümler kullanmanız gerekir.

İletişim

IBSurgeon/IBase.ru şirketi, kuruluşlar için gelişmiş bir HQbird dağıtım paketi geliştirmekte, Firebird için kapsamlı teknik destek sağlamakta ve özelleştirilmiş dağıtım paketleri geliştirmenin yanı sıra diğer karmaşık sorunları çözmektedir.

IBSurgeon ayrıca Firebird veritabanı performansını artırmak için Firebird Optimizasyon hizmeti sunmaktadır.

Bize ulaşın: [email protected]