Firebird'u Hızlandırmanın 23 Yolu Daha

Alexey Kovyazin, IBSurgeon, [email protected], 08-Oca-2019

Çeviriler: Portekizce

Neden “23 tane daha”?

Bazılarınız Mayıs 2016’da yayımlanan « Firebird’ü Hızlandırmanın 45 Yolu» makalesini hatırlar. Şimdi, çoğunlukla yüksek sayıda bağlantıya (1000+) sahip Firebird veritabanlarının ve sunucularının optimizasyonu ve bakımı deneyimine dayanan bir sonraki ipuçları ve püf noktaları serisini yayımlama zamanı.

1. Windows Server 2016 ve 2019’da Güç Seçeneklerini Yüksek Performans olarak ayarlayın

Varsayılan olarak, Windows Server’da güç planı “Dengeli” olarak ayarlıdır ve bu, veritabanı sunucuları için uygun değildir. Bunu “Yüksek Performans” olarak ayarlayın ve CPU yoğun işlemler için yaklaşık +%20 performans kazanın. Yeniden başlatma veya reboot olmadan, çevrimiçi olarak ayarlanabilir. Aşağıdaki resim, “Yüksek performans” güç planının avantajını gösteren CPU grafiğini göstermektedir:

Windows güç planlarıyla yaptığımız testler hakkında daha fazla ayrıntı burada bulunabilir.

2. Windows’ta Classic için «Masaüstüyle etkileşim kur» seçeneğini etkinleştirin

Windows’ta Firebird’ü Classic mimarisiyle kullanıyorsanız, «Hizmetin masaüstüyle etkileşim kurmasına izin ver» onay kutusunu etkinleştirin. Bu ayar olmadan, «masaüstü yığını» kaynağı Windows tarafından sınırlandırılır ve Firebird 250-300’den fazla bağlantı açamaz (veritabanının meta verilerine ve ilgili bellek tüketimine bağlıdır) - Bellek Yetersiz hatası oluşur.

3. Dikkat: Etki Alanı Denetleyicisi

Etki Alanı Denetleyicisi rolüne sahip Windows’un, Active Directory veritabanının bulunduğu diskte yazma önbelleğini devre dışı bırakması sorunu.

Bu, Firebird’ü çeşitli şekillerde etkiler (ve elbette diğer uygulamaları da) ve Active Directory rolleri olmayan sunuculara göre önemli ölçüde daha kötü performans sergiler.

Lütfen unutmayın ki bu sorun, Windows Small Business Server 2011 gibi popüler Windows sürümlerini ve DC’li diğer sürümleri de etkiler.

4. Linux’ta «maksimum açık dosya» sınırını artırın

Linux’u veritabanı sunucusu olarak kullanıyorsanız, Firebird için sınırları ayarlamayı unutmayın. Firebird sürecinizin (SuperServer veya SuperClassic) sınırlarını aşağıdaki komutla kontrol edin:

cat /proc//limits

ve maksimum açık dosya sayısını içeren satıra dikkat edin.

Firebird bağlantı başına 4 tanıtıcı kullanabilir ve eğer şöyle bir şeyiniz varsa:

Max open files 4096 4096 files

bu, Firebird süreci tarafından sunulan toplam bağlantı sayısının yaklaşık 1000 ile sınırlandırılacağı anlamına gelir.

Lütfen unutmayın - sunucuda 4 veritabanınız varsa, her veritabanı için bağlantı sayılır.

Daha fazlasını ayarlayın - 65535 öneriyorum.

Firebird sürecini yeniden başlattıktan sonra tekrar kontrol etmeyi unutmayın: uygulandı mı, uygulanmadı mı.

Classic mimarisi için, «firebird» kullanıcısı için sınırları kontrol etmek ve artırmak gerekir.

5. Modern Linux kullanın

Evet, bu tavsiyenin önemsiz olduğunu anlıyorum, ancak CentOS 6’dan 7’ye, Ubuntu 12’den 16’ya geçişten sonra (aynı donanımda!) birçok kez iyi performans iyileşmesi gördüm, bu yüzden artık 250-300’den fazla bağlantıya sahip veritabanı sunucuları için olmazsa olmaz bir öneridir. Modern Linux, daha ileri optimizasyon adımlarından önce bir ön koşuldur.

Önerilen Linux sürümleri: CentOS 7.x ve Ubuntu 16, 18.

6. Windows’ta dosya önbelleği için RAM’in %40’ını ayırın

İşletim Sistemi Bellek Yöneticisi’nin bellek tahsisiyle ilgili etkileri vardır ve varsayılan olarak Windows, dosya önbelleği için RAM’in %40’ını gerektirir.

Ne yazık ki, yetersiz araç olan Windows Görev Yöneticisi, dosya önbelleği için kullanılan belleği «boş» olarak gösterir ve bazı yöneticiler Firebird’ün tüm bu boş belleği tüketmesini sağlamaya çalışır, bu yüzden firebird.conf’taki DefaultDBCachePage parametresini çok yüksek değerlere ayarlarlar ve bu genellikle takasa (swapping) yol açar.

Windows’ta gerçek bellek kullanımını görmek için her zaman RAMMap aracını kullanın.

Windows Server (Firebird sunucusu olarak kullanılmaya ayrılmış) için ampirik kural şudur: Firebird belleği (Working Set) toplam RAM’in %40’ından az olmalıdır. Tüm süreçler için working set’lerin toplam boyutu %50’den fazlaysa, Windows tarafından takas başlatılabilir.

Lütfen unutmayın: burada “ayırmak” yalnızca “Firebird’de çok fazla sayfa arabelleği ayarlamayın” anlamına gelmez, aynı zamanda önemli olarak diğer yazılımların bellek kullanımını da kısıtlayın. Örneğin, Firebird ile aynı sunucuda MS Exchange veya MSSQL’iniz varsa, bunların bellek iştahlarını kısıtladığınızdan emin olun.

Ayrıntıları bilmek istiyorsanız, Firebird’de bellek yönetimine adanmış bir webinar kaydettim:

• Bölüm 1. https://www.youtube.com/watch?v=ZBmLgbYt4aM
• Bölüm 2, https://www.youtube.com/watch?v=-1.DF2FnU-A

7. Linux’ta dosya önbelleği için RAM’in %30’unu ayırın

Linux, dosya önbelleğiyle Windows’tan farklı şekilde çalışır ve genel olarak, dosya önbelleği için kullanılan RAM miktarı, fark edilir bir Firebird performans düşüşü olmadan Windows’takinden önemli ölçüde daha az olabilir. Ancak, yüksek sayıda bağlantıya sahip sistemin yüksek performansını garanti etmek için, özellikle Classic ve SuperClassic’te, RAM’in %30’unu dosya önbelleği için ayırmak iyi bir fikir olacaktır.

8. Linux’ta irqbalance kullanın

irqblalnce genellikle Firebird performansını ve yüksek sayıda çekirdeğe sahip sunucularda CPU yük dengelemesini iyileştirir.

9. Sanal Makineler için - Bellek Aşırı Taahhüdüne (Memory Overcommit) dikkat edin

Sanal Makine, ana makinede fiziksel olarak var olandan daha fazla belleğe sahip olacak şekilde yapılandırılabilir - Bellek Aşırı Taahhüdü olarak bilinen bir özellikle (ad farklı sanallaştırma sistemlerinde farklı olabilir). Bu, bellek tüketiminde bir zirve olması durumunda (veritabanı sunucusuna sahip VM’de veya komşu VM’de) takasın başlayabileceği ve bunun önemli gecikmelere yol açacağı anlamına gelir. Veritabanı sunucusu için tasarlanmış yüksek performanslı bir VM için tüm bellek statik olmalıdır.

10. Sanal Makineler için - VM sınırlarını kontrol edin

Genellikle VM’ler varsayılan CPU ve IO sınırlarıyla oluşturulur ve bunlar 50 IOPS ve %10 CPU gibi çok düşük olabilir. Sunucu VM ayarlarınızı kontrol edin ve tüm sınırları kaldırın - yüksek performanslı bir veritabanı sunucusu mümkün olan tüm CPU, bant genişliği ve IO’ya sahip olmalıdır.

11. Firebird geçici dosyalarını temizleyin

Firebird çeşitli işlemler için birçok geçici dosya oluşturur: sıralama, BLOB işleme, izleme. Bu dosyalar şu konumlarda saklanır: Windows’ta C:\ProgramData\firebird, Linux’ta / tmp / firebird

Normalde bu dosyalar otomatik olarak temizlenmelidir, ancak bazen bu gerçekleşmez (örneğin, sunucu yeniden başlatılması durumunda).

Bu klasörleri periyodik olarak kontrol edin ve eski dosyaları temizleyin - birçok GB eski fb_NNN dosyası olabilir ve bunları temizlemek sistem sürücüsünde yer açacaktır.

12. Büyük Firebird önbelleğiyle dosya önbelleğini etkinleştirmeyi unutmayın

Bildiğiniz gibi, Firebird önbelleği (aynı zamanda «sayfa arabellekleri» olarak da adlandırılır) firebird.conf/databases.conf’taki DefaultDBCachePages parametresiyle veya doğrudan veritabanının başlığında belirtilir.

Firebird 3 SuperServer’da bu önbelleğin boyutu çok yüksek ayarlanabilir, ancak başka bir parametreyi hatırlamak önemlidir: FileSystemCacheThreshold.

FileSystemCacheThreshold, DefaultDBCachePages veya sayfa arabelleklerinden küçükse, işletim sisteminin dosya önbelleği kullanılmayacak ve bu da performans sorunlarına yol açabilir.

Vakaların %99’unda dosya önbelleğinin etkin olması daha iyidir.

Bunu sağlamak için, parametreleri her zaman aşağıdaki kurala göre ayarlayın:

• DefaultDBCachePages = X
• FileSystemCacheThreshold = X+ N, N>1

Dosya önbelleğini devre dışı bırakmanın performansı iyileştirdiği nadir durumlar vardır - böyle bir örneğiniz varsa, lütfen benimle iletişime geçin - [email protected]!

13. Güvenlik veritabanını hızlandırın

Firebird veritabanına yapılan her bağlantı, güvenlik veritabanına (Firebird 3 durumunda security3.fdb) bağlantı kurar ve birkaç okuma ve yazma gerçekleştirir (işlem sayfaları, başlık sayfası). Sık bağlantılarınız varsa, güvenlik veritabanınızın performansı bir sorun haline gelebilir.

En azından aşağıdakileri yapabilirsiniz:

• securityN.fdb için sayfa arabelleklerini artırın (ampirik optimum 256 arabellektir)
• security3.fdb’yi hızlı sürücüye taşıyın (Firebird 3’te standart bir özelliktir, 2.5’te yeniden kurulum gerektirir)

Ardından, güvenlik veritabanı için Forced Writes’ı OFF olarak ayarlayabilirsiniz - bu durumda bozulma olasılığının düşük olması bir sorun değildir.

En radikal yol, güvenlik veritabanını salt okunur yapmaktır - bu, ona yapılan tüm yazmaları ortadan kaldıracaktır.

Güvenlik veritabanındaki kullanıcıları sık sık değiştirmiyorsanız, bu en iyi çözümdür.

14. Firebird 3’te SuperClassic’i deneyin

Firebird 3’te SuperServer mimarisi nihai performans çözümü olarak yoğun şekilde tanıtıldı, ancak SuperClassic ile daha iyi performans gösteren bazı yük türleri vardır (ancak Classic değil - her zaman SuperServer/SuperClassic’ten daha yavaş çalışır).

Bu deneyi güvenli bir şekilde nasıl gerçekleştirebilirsiniz? Aşağıdaki adımları izleyin:

SuperClassic’i denemek için

1. firebird.conf’ta ayarlayın
2. ServerMode=SuperClassic
3. DefaultDbCachePages=1024
4. gfix -buff 0
5. Firebird’ü yeniden başlatın

SuperServer’a geri dönmek için

1. firebird.conf’ta ayarlayın
2. ServerMode=SuperServer
3. DefaultDbCachePages=N # N*sayfa boyutu*veritabanı_sayısı < RAM’in %25’i
4. FileSystemCacheThreshold = N+1
5. gfix -buff 0
6. Firebird’ü yeniden başlatın

Lütfen deneyin sonuçları hakkında bana ([email protected]) yazın, sonuçları görmekle ilgileniyorum.

15. Büyük veritabanı mı? Sayfa boyutunu artırın

Varsayılan olarak, Firebird veritabanları aşağıdaki sayfa boyutlarına sahiptir:

• 2.5 - 4096 bayt
• 3.0 - 8192 bayt

Ancak, maksimum sayfa boyutu 16K’dır (4.0’da - 32K).

100Gb’den büyük veritabanları için vakaların %95’inde, aşağıdakiler için mevcut en yüksek sayfa boyutuna sahip olmak daha iyidir:

• İndekslerin derinliğini azaltmak. Derinliği 3 veya daha az olan indekslere sahip olmak önerilir. Derinliği 4 ve 5 olan indeksler çok daha yavaş olacaktır
• RAM kullanımını artırmak. Firebird önbelleği sayfalar halinde belirtilir, 8K sayfa boyutuyla 1000 sayfa 8Mb gerçek bellek olacak ve 16K ile - 16Mb.
• Sistem sayfalarının sayısını azaltmak. Bu, büyük tabloların kayıtlarına erişimi hızlandıracak (daha az işaretçi-işaretçi-veri sayfası atlaması) ve büyük SQL sorgularının hazırlanmasına yardımcı olacaktır. Veritabanının sayfa boyutunu artırmak için, veritabanı gbak aracıyla yedeklenmeli ve ardından -page parametresiyle geri yüklenmelidir ( gbak -c -page 16384).

Lütfen unutmayın: birçok küçük blob içeren bir veritabanınız varsa, sayfa boyutunu artırmak parçalanmayı azaltabilir veya parçalanmayı artırabilir ve performansı artırıp artırmayacağını tahmin etmek zordur.

16. no_reserve bayrağını kullanmayın

no_reserve bayrağı, Firebird’ün UPDATE veya DELETE sonrasında oluşan olası kayıt sürümleri için veri sayfalarında boş alanı (%30) ayırmamasını sağlar. Bu bayrak, verilerin daha kompakt bir şekilde saklanmasına izin verir (ve veritabanının boyutu da daha küçüktür), ancak UPDATE/DELETE durumunda tüm değişiklikler yeni veri sayfasına gider. Sonuç olarak, no_reserve bayrağına sahip veritabanında UPDATE/DELETE işlemleri daha yavaştır.

Bu nedenle, veritabanınız salt okunur değilse, no_reserve bayrağını kaldırmanızı öneririm.

Ayarlanıp ayarlanmadığını nasıl kontrol edersiniz - çıktısındaki Attributes satırına bakın

gstat -h database

Nasıl devre dışı bırakılır:

gfix -use reserve database

Bu komuttan sonra, yeni veri sayfaları ayrılmış alanla oluşturulacaktır.

Ancak, tam etkiyi elde etmek için, bir veritabanını gbak ile yedeklemek ve ardından geri yüklemek gerekir, bu durumda tüm veri sayfaları ayrılmış alanla olacaktır.

Lütfen unutmayın: no_reserve bayrağı kaldırıldıktan ve yedekleme/geri yükleme yapıldıktan sonra veritabanı boyutu büyüyecektir.

17. Firebird kilit tablosu için yüksek başlangıç boyutu ayarlayın

Kilit tablosu, Firebird’ün iç motor nesnelerine erişimi senkronize etmek için kullanılan mekanizmasıdır.

Firebird kilit tablosu otomatik olarak büyüyebilir, ancak bu büyüme yavaş bir işlemdir ve mikro donmalara yol açabilir. Kilit tablosu yalnızca başlangıç boyutundan itibaren büyüyebilir (bu boyut firebird.conf içinde ayarlanır).

Kilit tablosunun birden fazla kez büyümesini önlemek için iyi bir fikir, çalışma döneminin (gün, hafta vb.) sonunda kilit tablosunun boyutunu izlemek ve ardından bunu firebird.conf içinde başlangıç boyutu olarak ayarlamaktır.

LockMemSize=99999999

Bilginiz için: ~1000 kullanıcılı yüksek yük altındaki sistemlerde LockMemSize genellikle 200Mb’ın altındadır.

18. Veritabanına bağlantı sayısını saymak için fb_lock_print kullanın

Veritabanı bağlantı sayısını almak, veritabanı geliştiricileri için sık karşılaşılan bir görevdir: örneğin lisanslama amacıyla gerekli olabilir.

Geliştiriciler bu değeri almak için sıklıkla SELECT count(*) FROM MON$ATTACHMENTS sorgusunu kullanır, ancak bu en uygun yol değildir: MON$ tablolarına sık yapılan sorgular veritabanı için bir yük olabilir, bu nedenle alternatifi kullanmak daha iyidir:

Şunu çalıştırın

fb_lock_print -d database_name | alias

ve Owners değerini kontrol edin - bu, veritabanına mevcut bağlantı sayısını gösterecektir.

19. Gereksiz LEFT JOIN’lardan kaçının

Sıklıkla şu yapıya sahip sorgular görüyorum:

T1 LEFT JOIN T2 ON (…) WHERE T2.Field_condition

Esasen T2 üzerindeki koşul, LEFT JOIN T2 çıktısından NULL’ları hariç tutar, bu nedenle LEFT JOIN’i INNER JOIN olarak değiştirmek mümkündür - bu sorgunun sonucunu etkilemez.

INNER JOIN, Firebird optimizer’ına daha fazla özgürlük tanır ve Firebird’ün modern sürümlerinde LEFT’e göre çok daha iyi optimize edilir.

Özellikle aşağıdaki durumlarda anlamlıdır:

• WHERE yan tümcesinde T1 için koşul yok
• T2 küçük bir tablodur

20. Gereksiz kayıt sayımından kaçının

Karmaşık veritabanı sorgularında ve saklı yordamlarda bir başka yaygın hata, kaydın varlığını kontrol etmek için yalnızca select count() kullanmaktır.

Aşağıdaki sorgu, condition1’e göre tüm kayıtları okuyacaktır:

(select count(*)…. where condition11) >0

Bunun yerine bu yapıyı kullanmak daha iyidir

Exists(select first 1 id where condition1)

Eğer condition1 birden fazla kayıt döndürürse, önerilen seçenek çok daha hızlı olacaktır, çünkü tüm kayıtları okumaz, ilk getirilen kayıttan sonra durur.

21. Saklı yordamlarda gereksiz sıralamadan kaçının

Saklı yordam içindeki sorgu sonuçlarının sıralanması iş mantığıyla gerekçelendirilmelidir.

Örneğin, aşağıdaki saklı yordam örneğinde, ORDER BY yan tümcesi iş mantığı açısından gereksizdir, ancak gereksiz bir sıralama işlemi ekler.

create or alter procedure NEW_PROCEDURE
returns (
    SUMX double precision)
as
declare variable _amount double precision;
begin
for select T1.amount from Table1 t1 where ....
    order by id
    into :_amount
    do
    begin
     sumx=sumx+_amount
    end;
  suspend;
end

PSQL kodunuzu benzer durumlar için kontrol edin ve gereksiz ORDER BY’ı (ayrıca distinct ve UNION’ı) kaldırın.

22. Sorguları gereksiz yere hazırlanmış durumda tutmayın

Sıklıkla her bağlantıda 500-1000 hazırlanmış ifade görürüz (bu MON$ sorgularıyla kontrol edilebilir).

Bunların büyük çoğunluğu yalnızca bir kez çalışır ve sonra sadece RAM’de oturur, Firebird’ün çalışma kümesini büyütür ve MON$ sorgularını yavaşlatır.

Öneri, SQL sorgularını hazırlanmış durumda yalnızca birçok kez başlatılmaları amaçlanıyorsa veya hazırlama süreleri uzunsa (çok sayıda join içeren ve devasa tablolara erişen çok büyük sorgular için böyle olabilir) tutmaktır.

23. Büyük sıralama içeren sorguları her zaman kapatın

Sıralama içeren SQL sorgusu (ORDER BY, GROUP BY, UNION, distinct) kapatılana kadar Firebird, sıralanmış kayıtları bellekte tutar. Sıralama için ayrılan belleğin boyutu firebird.conf içindeki TempCacheLimit parametresiyle ayarlanır, varsayılan olarak 64Mb’dir.

TempCacheLimit artırılsa bile, çok sayıda sıralanmış kayıt içeren uzun süreli sorgular sonunda ayrılan miktarın tamamını tüketecek ve sonuç olarak sıralama geçici dosyalara (yani diske) gidecektir. Bunun sonucunda önemli yavaşlamalara yol açabilir.

Öneri, bu tür tüm sorguları zamanında kapatmaktır.

Sorularınız mı var?

Herhangi bir sorunuz için benimle iletişime geçmekten çekinmeyin: [email protected]!