23 Firebird'ı 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ınlanan « Firebird’ü Hızlandırmanın 45 Yolu» makalesini hatırlıyordur. Ş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 ipucu ve püf noktaları serisini yayınlamanın zamanı geldi.

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

Varsayılan olarak, Windows Server’da veritabanı sunucuları için uygun olmayan “Dengeli” bir güç planı ayarlıdır. Bunu “Yüksek Performans” olarak ayarlayın ve CPU yoğun işlemler için yaklaşık +20% performans kazanın. Bu, yeniden başlatma veya yeniden başlatma 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 ilgili testlerimiz hakkında daha fazla ayrıntı burada bulunabilir.

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

Windows’ta Classic mimarisiyle Firebird kullanıyorsanız, «Hizmetin masaüstü ile etkileşime girmesine 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ı olarak) - Bellek Yetersiz hatası oluşur.

3. Dikkat: Etki Alanı Denetleyicisi

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

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

Bu sorunun Windows Small Business Server 2011 gibi popüler Windows sürümlerini ve DC’li diğer sürümleri etkilediğini lütfen unutmayın.

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 limitleri ayarlamayı unutmayın. Firebird işleminiz (SuperServer veya SuperClassic) için limitleri aşağıdaki komutla kontrol edin:

cat /proc//limits

ve maksimum açık dosya sayısı satırına dikkat edin.

Firebird bağlantı başına 4 taneye kadar tanıtıcı kullanabilir ve şöyle bir şey görürseniz:

Max open files 4096 4096 files

bu, Firebird işlemi tarafından sunulan toplam bağlantı sayısının 1000 civarında sınırlandırılacağı anlamına gelir.

Sunucuda 4 veritabanı varsa, her veritabanı için bağlantının sayıldığını lütfen unutmayın.

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

Firebird işlemini yeniden başlattıktan sonra tekrar kontrol etmeyi unutmayın: uygulandı mı, uygulanmadı mı?

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

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!) iyi performans iyileştirmelerini birçok kez gördüm, bu yüzden şimdi 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

OS Bellek Yöneticisi’nin bellek ayırma konusunda etkileri vardır ve varsayılan olarak Windows, dosya önbelleği için RAM’in %40’ını gerektirir.

Ne yazık ki, Windows Görev Yöneticisi aracı 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 dosyasında DefaultDBCachePage parametresini çok yüksek değerlere ayarlarlar ve bu genellikle takaslamaya (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 için ampirik kural (Firebird sunucusu olarak kullanılmak üzere ayrılmış) şudur: Firebird belleği (Çalışma Kümesi), toplam RAM’in %40’ından az olmalıdır. Tüm işlemler için çalışma kümelerinin toplam boyutu %50’den fazlaysa, Windows tarafından takas başlatılabilir.

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

Ayrıntıları bilmek istiyorsanız, Firebird’de bellek yönetimine ayrılmış web seminerini 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ı bir şekilde çalışır ve genel olarak, dosya önbelleği için kullanılan RAM miktarı, Firebird performansında gözle görülür bir düşüş olmadan Windows’takinden önemli ölçüde daha az olabilir. Ancak, özellikle Classic ve SuperClassic’te yüksek sayıda bağlantıya sahip sistemin yüksek performansını garanti etmek için, dosya önbelleği için RAM’in %30’unu ayırmak iyi bir fikir olacaktır.

8. Linux’ta irqbalance kullanın

irqbalance, yüksek sayıda çekirdeğe sahip sunucularda Firebird performansını ve CPU yükü dengelemesini sıklıkla 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üketiminin zirve yaptığı durumda (veritabanı sunucusu olan 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 tasarlanan yüksek performanslı VM için tüm bellek statik olmalıdır.

10. Sanal Makineler için - VM limitlerini kontrol edin

Genellikle VM’ler, 50 IOPS ve %10 CPU gibi çok düşük olabilen varsayılan CPU ve IO limitleriyle oluşturulur. Sunucu VM ayarlarınızı kontrol edin ve tüm limitleri kaldırın - yüksek performanslı 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 olmaz (örneğin, sunucu yeniden başlatılması durumunda).

Bu klasörleri periyodik olarak kontrol edin ve eski dosyaları temizleyin - fb_NNN adlı çok sayıda GB eski dosya 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 («sayfa arabellekleri» olarak da adlandırılır) firebird.conf/databases.conf dosyasındaki 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ılmaz 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ı artırdığı 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 işlemi 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 Zorunlu Yazmaları (Forced Writes) KAPALI olarak ayarlayabilirsiniz - bu durumda küçük bozulma olasılığı 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ında 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 bir ş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ştirirsiniz? Aşağıdaki adımları izleyin:

SuperClassic’i denemek için

1. firebird.conf dosyasında 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 dosyasında 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ını 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 en yüksek mevcut sayfa boyutuna sahip olmak daha iyidir:

• Dizinlerin derinliğini azaltın. Derinliği 3’e eşit veya daha az olan dizinlere sahip olmanız önerilir. Derinliği 4 ve 5 olan dizinler çok daha yavaş olacaktır
• RAM kullanımını artırın. Firebird önbelleği sayfalar halinde belirtilir, 8K sayfa boyutuna sahip 1000 sayfa 8Mb gerçek bellek olacaktır ve 16K ile - 16Mb.
• Sistem sayfalarının sayısını azaltın. Bu, büyük tabloların kayıtlarına erişimi hızlandıracaktır (daha az işaretçi-işaretçi-veri sayfası atlaması) ve büyük SQL sorgularının hazırlanmasına yardımcı olur. 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 artırabilir ve performansı artıracak mı yoksa azaltacak mı tahmin etmek zordur.

16. no_reserve bayrağını kullanmayın

no_reserve bayrağı, Firebird’ün UPDATE veya DELETE’ten sonra oluşabilecek 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ğı olan 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.

Ayarlı olup olmadığı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, veritabanını gbak ile yedeklemek ve ardından geri yüklemek gerekir, bu durumda tüm veri sayfaları ayrılmış alana sahip olacaktır.

Lütfen unutmayın: no_reserve bayrağını kaldırdıktan ve yedekleme/geri yükleme sonrasında veritabanı boyutu büyüyecektir.

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

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

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

Lock table’ın birden fazla büyüme turunu önlemek için, çalışma döneminin (gün, hafta vb.) sonunda lock table boyutunu izlemek ve ardından bunu firebird.conf içinde başlangıç boyutu olarak ayarlamak iyi bir fikir olacaktır.

LockMemSize=99999999

Bilginize: ~1000 kullanıcılı yüksek yüklü sistemlerde LockMemSize genellikle 200Mb’nin altındadır.

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

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

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

Çalıştırın

fb_lock_print -d database_name | alias

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

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

Sık sık ş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 yüzden LEFT JOIN’i INNER JOIN olarak değiştirmek mümkündür - bu, sorgunun sonucunu etkilemeyecektir.

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

Özellikle şu durumlarda anlamlıdır:

• WHERE yan tümcesinde T1 için koşul yoksa
• T2 küçük bir tabloy ise

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

Karmaşık veritabanı sorgularında ve saklı prosedürlerde yapılan bir diğer yaygın hata, kaydın varlığını kontrol etmek için 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 şu 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ı prosedürlerde gereksiz sıralamadan kaçının

Saklı prosedür içindeki sorgu sonuçlarının sıralanması, iş mantığı ile gerekçelendirilmelidir.

Örneğin, aşağıdaki saklı prosedür örneğinde, ORDER BY yan tümcesi iş mantığı açısından işe yaramaz, 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) ifadelerini kaldırın.

22. Sorguları gereksiz yere hazır durumda tutmayın

Genellikle her bağlantıda 500-1000 hazır ifade görüyoruz (bu, MON$ sorgularıyla kontrol edilebilir).

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

Öneri, SQL sorgularını yalnızca birçok kez başlatılması amaçlanıyorsa veya hazırlanma süreleri uzunsa (çok sayıda join ve büyük tablolara erişimi olan çok büyük sorgular için olabilir) hazır durumda tutmaktır.

23. Büyük sıralamalı sorguları her zaman kapatın

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

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

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

Sorularınız mı var?

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