Contacten
IBSurgeon
Deze pagina is automatisch vertaald. Lees het Engelse origineel. English

IBSurgeon-bibliotheek

23 extra manieren om Firebird te versnellen

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

Vertalingen: Portugees

Waarom “23 meer”?

Sommigen van jullie herinneren zich het artikel « 45 manieren om Firebird te versnellen», dat in mei 2016 werd gepubliceerd. Nu is het tijd om de volgende reeks tips en trucs te publiceren, voornamelijk gebaseerd op de ervaring met het optimaliseren en onderhouden van Firebird-databases en -servers met een hoog aantal verbindingen (1000+).

1. Stel energiebeheer in op Hoge prestaties in Windows Server 2016 en 2019

Standaard heeft Windows Server een energiebeheerschema ingesteld op “Balanced” (Gebalanceerd), wat niet geschikt is voor databaseservers. Stel dit in op “High Performance” (Hoge prestaties) en win ongeveer +20% aan prestaties voor CPU-intensieve bewerkingen. Dit kan online worden ingesteld, zonder herstart of reboot. De afbeelding hieronder toont de CPU-grafiek, die het voordeel van het energiebeheerschema “Hoge prestaties” demonstreert:

Meer details over onze tests met Windows-energiebeheerschema’s vindt u hier.

2. Schakel «Interactie met het bureaublad» in voor Classic op Windows

Als u Firebird met Classic-architectuur op Windows gebruikt, schakel dan het vinkje «Allow service to interact with desktop» (Service toestaan om met het bureaublad te communiceren) in. Zonder deze instelling wordt de resource «desktop heap» (bureaubladheap) door Windows beperkt, en kan Firebird niet meer dan 250-300 verbindingen openen (afhankelijk van de metadata van de database en het bijbehorende geheugengebruik) - er treedt dan een Out Of Memory-fout op.

3. Let op: Domeincontroller

Het probleem dat Windows met de rol Domeincontroller de write cache op de schijf met de Active Directory-database uitschakelt.

Dit heeft op verschillende manieren invloed op Firebird (en natuurlijk ook op andere applicaties), en het presteert aanzienlijk slechter dan op servers zonder Active Directory-rollen.

Houd er rekening mee dat dit probleem invloed heeft op populaire Windows-versies zoals Windows Small Business Server 2011, en ook op andere versies met DC.

4. Verhoog de limiet «max open files» op Linux

Als u Linux als databaseserver gebruikt, vergeet dan niet de limieten voor Firebird aan te passen. Controleer de limieten voor uw Firebird-proces (SuperServer of SuperClassic) met de volgende opdracht:

Code 
cat /proc//limits

en let op de regel met het maximale aantal open bestanden.

Firebird kan tot 4 handles per verbinding gebruiken, en als u iets als dit ziet:

Code 
Max open files 4096 4096 files

betekent dit dat het totale aantal verbindingen dat door het Firebird-proces wordt bediend, beperkt zal zijn tot ongeveer 1000.

Houd er rekening mee: als u 4 databases op de server heeft, wordt de verbinding voor elke database geteld.

Stel meer in - ik raad 65535 aan.

Vergeet niet om na het herstarten van het Firebird-proces opnieuw te controleren of het is toegepast of niet.

Voor Classic-architectuur is het noodzakelijk om de limieten voor de gebruiker «firebird» te controleren en te verhogen.

5. Gebruik modern Linux

Ja, ik begrijp dat dit advies triviaal is, maar ik heb vele malen een goede prestatieverbetering gezien na de migratie van CentOS 6 naar 7, Ubuntu 12 naar 16 (op dezelfde hardware!), dus nu is het een absolute aanbeveling voor databaseservers met meer dan 250-300 verbindingen. Modern Linux is een voorwaarde voordat verdere optimalisatiestappen worden uitgevoerd.

Aanbevolen Linux-versies: CentOS 7.x en Ubuntu 16, 18.

6. Reserveer 40% RAM voor bestandscache op Windows

De OS Memory Manager heeft implicaties voor de geheugentoewijzing, en standaard vereist Windows 40% van het RAM voor bestandscache.

Helaas toont het arme hulpmiddel Windows Taakbeheer geheugen dat voor bestandscache wordt gebruikt als «vrij», en sommige beheerders proberen Firebird al dit vrije geheugen te laten verbruiken, dus stellen ze de parameter DefaultDBCachePage in firebird.conf in op zeer hoge waarden, wat meestal leidt tot swapping.

Gebruik altijd het hulpmiddel RAMMap om het werkelijke geheugengebruik op Windows te zien.

De empirische regel voor Windows Server (speciaal bestemd voor gebruik als Firebird-server) is de volgende: Firebird-geheugen (Working Set) moet minder dan 40% van het totale RAM zijn. Als de totale grootte van de werksets voor alle processen meer dan 50% is, kan swapping door Windows worden gestart.

Houd er rekening mee: “reserveren” betekent hier niet alleen “stel niet te veel page buffers in Firebird in”, maar ook, belangrijk, beperk het geheugengebruik van andere software. Als u bijvoorbeeld MS Exchange of MSSQL op dezelfde server als Firebird heeft, zorg er dan voor dat u hun geheugenverbruik beperkt.

Als u geïnteresseerd bent in details, ik heb een webinar opgenomen over geheugenbeheer in Firebird:

7. Reserveer 30% RAM voor bestandscache op Linux

Linux werkt op een andere manier met bestandscache dan Windows, en over het algemeen kan de hoeveelheid RAM die voor bestandscache wordt gebruikt aanzienlijk minder zijn dan op Windows, zonder merkbare prestatievermindering van Firebird. Om echter hoge prestaties van het systeem met een hoog aantal verbindingen te garanderen, vooral op Classic en SuperClassic, is het een goed idee om 30% RAM voor bestandscache te reserveren.

8. Gebruik irqbalance op Linux

irqbalance verbetert vaak de Firebird-prestaties en de CPU-loadbalancing op servers met een hoog aantal cores.

9. Voor virtuele machines - let op Memory Overcommit

Een virtuele machine kan worden geconfigureerd met meer geheugen dan fysiek op de hostmachine bestaat - met een functie die bekend staat als Memory Overcommit (de naam kan verschillen op verschillende virtualisatiesystemen). Dit betekent dat in het geval van een piek in het geheugengebruik (op de VM met de databaseserver of op de naburige VM) swapping kan starten, wat tot aanzienlijke vertragingen zal leiden. Voor een high-performance VM bedoeld voor een databaseserver, moet al het geheugen statisch zijn.

10. Voor virtuele machines - controleer VM-limieten

Vaak worden VM’s gemaakt met standaard CPU- en IO-limieten, die zeer laag kunnen zijn, zoals 50 IOPS en 10% CPU. Controleer de instellingen van uw server-VM en verwijder alle limieten - een high-performance databaseserver moet alle mogelijke CPU, bandbreedte en IO hebben.

11. Ruim Firebird-tijdelijke bestanden op

Firebird maakt veel tijdelijke bestanden aan voor verschillende bewerkingen: sorteren, BLOB-verwerking, tracing. Deze bestanden worden opgeslagen op de volgende locaties: op Windows C:\ProgramData\firebird, op Linux / tmp / firebird

Normaal gesproken zouden deze bestanden automatisch moeten worden opgeruimd, maar soms gebeurt dit niet (bijvoorbeeld bij een serverherstart).

Controleer deze mappen periodiek en ruim oude bestanden op - er kunnen vele GB’s aan verouderde bestanden fb_NNN zijn, en het opruimen ervan zal ruimte vrijmaken op de systeemschijf.

12. Vergeet niet om bestandscache in te schakelen met grote Firebird-cache

Zoals u weet, wordt de Firebird-cache (ook wel «page buffers» genoemd) gespecificeerd door de parameter DefaultDBCachePages in firebird.conf/databases.conf, of rechtstreeks in de header van de database.

In Firebird 3 SuperServer kan de grootte van deze cache zeer hoog worden ingesteld, maar het is belangrijk om te onthouden dat er nog een andere parameter is: FileSystemCacheThreshold.

Als FileSystemCacheThreshold kleiner is dan DefaultDBCachePages of page buffers, wordt de bestandscache van het besturingssysteem niet gebruikt, wat tot prestatieproblemen kan leiden.

In 99% van de gevallen is het beter om bestandscache ingeschakeld te hebben.

Om dit te garanderen, stelt u parameters altijd in volgens de volgende regel:

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

Er zijn zeldzame gevallen waarin het uitschakelen van bestandscache de prestaties verbetert - als u zo’n voorbeeld heeft, neem dan contact met mij op - [email protected]!

13. Versnel de beveiligingsdatabase

Elke verbinding met de Firebird-database brengt een verbinding tot stand met de beveiligingsdatabase (security3.fdb in het geval van Firebird 3), en voert verschillende lees- en schrijfbewerkingen uit (transactiepagina’s, headerpagina). Als u frequente verbindingen heeft, kan de prestaties van uw beveiligingsdatabase een probleem worden.

Als minimum kunt u het volgende doen:

  • Verhoog page buffers voor securityN.fdb (empirisch optimum is 256 buffers)
  • Verplaats security3.fdb naar een snelle schijf (dit is een standaardfunctie in Firebird 3, in 2.5 vereist dit herinstallatie)

Vervolgens kunt u Forced Writes UIT zetten voor de beveiligingsdatabase - de kleine kans op corruptie is in dit geval geen probleem.

De meest radicale manier is om de beveiligingsdatabase alleen-lezen te maken - dit elimineert alle schrijfbewerkingen erop.

Als u niet vaak gebruikers in de beveiligingsdatabase wijzigt, is dit de beste oplossing.

14. Probeer SuperClassic op Firebird 3

In Firebird 3 werd de SuperServer-architectuur zwaar aangeprezen als de ultieme prestatieoplossing, maar er zijn enkele belastingstypen die betere prestaties demonstreren met SuperClassic (maar niet Classic - dat werkt altijd langzamer dan SuperServer/SuperClassic).

Hoe voert u dit experiment op een veilige manier uit? Volg de onderstaande stappen:

Om SuperClassic te proberen

  1. Stel in firebird.conf in
  2. ServerMode=SuperClassic
  3. DefaultDbCachePages=1024
  4. gfix -buff 0
  5. Herstart Firebird

Om terug te keren naar SuperServer

  1. Stel in firebird.conf in
  2. ServerMode=SuperServer
  3. DefaultDbCachePages=N # N*page size*databases_count < 25% RAM
  4. FileSystemCacheThreshold = N+1
  5. gfix -buff 0
  6. Herstart Firebird

Schrijf mij alstublieft ([email protected]) over de resultaten van het experiment, ik ben geïnteresseerd om de resultaten te zien.

15. Grote database? Vergroot de paginagrootte

Standaard hebben Firebird-databases de volgende paginagroottes:

  • 2.5 - 4096 bytes
  • 3.0 - 8192 bytes

De maximale paginagrootte is echter 16K (in 4.0 - 32K).

Voor databases groter dan 100Gb is het in 95% van de gevallen beter om de hoogst beschikbare paginagrootte te hebben, om:

  • De diepte van indexen te verkleinen. Het wordt aanbevolen om indexen met een diepte van 3 of minder te hebben. Indexen met diepte 4 en 5 zullen veel langzamer zijn
  • Het gebruik van RAM te verhogen. Firebird-cache wordt gespecificeerd in pagina’s, 1000 pagina’s met 8K paginagrootte zal 8Mb aan werkelijk geheugen zijn, en met 16K - 16Mb.
  • Het aantal systeempagina’s te verkleinen. Dit versnelt de toegang tot de records van grote tabellen (minder sprongen pointer-pointer-datapagina), en helpt bij de voorbereiding van grote SQL-query’s. Om de paginagrootte van de database te vergroten, moet de database worden geback-upt met het gbak-hulpmiddel en vervolgens worden hersteld met de parameter -page ( gbak -c -page 16384).

Houd er rekening mee: als u een database met veel kleine blobs heeft, kan het vergroten van de paginagrootte de fragmentatie verminderen of vergroten, en het is moeilijk te voorspellen of het de prestaties zal verhogen of verlagen.

16. Gebruik de no_reserve-vlag niet

De vlag no_reserve zorgt ervoor dat Firebird geen vrije ruimte (30%) op datapagina’s reserveert voor mogelijke recordversies, die optreden na UPDATE of DELETE. Deze vlag zorgt ervoor dat gegevens compacter kunnen worden opgeslagen (en de grootte van de database is ook kleiner), maar in het geval van UPDATE/DELETE gaan alle wijzigingen naar de nieuwe datapagina. Als gevolg hiervan zijn UPDATE/DELETE-bewerkingen langzamer in de database met de no_reserve-vlag.

Dus, als uw database niet alleen-lezen is, raad ik aan om de no_reserve-vlag te verwijderen.

Hoe te controleren of deze is ingesteld of niet - zie de regel Attributes in de uitvoer van

Code 
gstat -h database

Hoe uit te schakelen:

Code 
gfix -use reserve database

Na deze opdracht worden nieuwe datapagina’s met gereserveerde ruimte gemaakt.

Om echter het volledige effect te bereiken, is het noodzakelijk om een database te back-uppen met gbak en vervolgens te herstellen, in dit geval worden alle datapagina’s met gereserveerde ruimte gemaakt.

Houd er rekening mee: de databasegrootte zal groeien na het verwijderen van de no_reserve -vlag en backup/restore.

17. Stel een hoge initiële grootte in voor de Firebird-locktabel

Locktabel is het mechanisme van Firebird dat wordt gebruikt om de toegang tot interne engine-objecten te synchroniseren.

Firebird lock table kan automatisch groeien, maar de toename is een langzame operatie, wat kan leiden tot micro-freezes. Lock table kan alleen groeien, beginnend vanaf de initiële grootte (deze wordt ingesteld in firebird.conf).

Om meerdere rondes van het vergroten van de lock table te voorkomen, is het een goed idee om de grootte van de lock table aan het einde van de werkperiode (dag, week, etc.) te controleren en deze vervolgens als initiële grootte in firebird.conf in te stellen.

LockMemSize=99999999

Ter referentie: LockMemSize op systemen met hoge belasting met ~1000 gebruikers is meestal lager dan 200Mb.

18. Gebruik fb_lock_print om het aantal verbindingen met de database te tellen

Het verkrijgen van het aantal databaseverbindingen is een veelvoorkomende taak voor databaseontwikkelaars: het kan bijvoorbeeld nodig zijn voor licentie doeleinden.

Vaak gebruiken ontwikkelaars de query SELECT count(*) FROM MON$ATTACHMENTS om deze waarde te verkrijgen, maar dit is niet de optimale manier: frequente queries naar MON$ tabellen kunnen een belasting vormen voor de database, dus gebruik beter het alternatief:

Voer uit

fb_lock_print -d database_naam | alias

en controleer de Owners waarde - deze toont het huidige aantal verbindingen met de database.

19. Vermijd onnodige LEFT JOINs

Vaak zie ik queries met een constructie zoals deze:

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

In wezen sluit de voorwaarde op T2 NULLs uit van de uitvoer van LEFT JOIN T2, dus het is mogelijk om LEFT JOIN te wijzigen naar INNER JOIN - dit zal het resultaat van de query niet beïnvloeden.

INNER JOIN geeft meer vrijheid aan de Firebird optimizer, en in de moderne versies van Firebird wordt het veel beter geoptimaliseerd dan LEFT.

Vooral in de volgende gevallen is dit zinvol:

  • Geen voorwaarde voor T1 in de WHERE clausule
  • T2 is een kleine tabel

20. Vermijd onnodig tellen van records

Een andere veelgemaakte fout in complexe databasequeries en opgeslagen procedures is het gebruik van select count() alleen om te controleren of een record bestaat.

De volgende query leest alle records volgens condition1:

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

Gebruik beter deze constructie in plaats daarvan

Code 
Exists(select first 1 id where condition1)

Als condition1 meer dan 1 record retourneert, zal de voorgestelde optie veel sneller zijn, omdat het niet alle records leest, maar stopt na het eerste opgehaalde record.

21. Vermijd onnodig sorteren in opgeslagen procedures

Het ordenen van de queryresultaten binnen de opgeslagen procedure moet gerechtvaardigd zijn door de bedrijfslogica.

In het voorbeeld van de opgeslagen procedure hieronder is bijvoorbeeld de ORDER BY clausule nutteloos vanuit het oogpunt van bedrijfslogica, maar het voegt een onnodige sorteeroperatie toe.

Code 
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

Controleer uw PSQL-code op vergelijkbare situaties en verwijder nutteloze ORDER BY (evenals distinct en UNION).

22. Houd queries niet in de voorbereide staat zonder noodzaak

Vaak zien we 500-1000 voorbereide statements in elke verbinding (dit kan worden gecontroleerd met MON$ queries).

De overgrote meerderheid ervan wordt slechts één keer uitgevoerd, en daarna zitten ze gewoon in het RAM-geheugen, waardoor de working set van Firebird groter wordt en MON$ queries worden vertraagd.

De aanbeveling is om SQL-queries alleen in de voorbereide staat te houden als ze bedoeld zijn om vele malen te worden gestart, of als hun voorbereidingstijd groot is (dit kan het geval zijn voor zeer grote queries met veel joins en toegang tot enorme tabellen).

23. Sluit altijd queries met grote sortering

Zolang een SQL-query met sortering (ORDER BY, GROUP BY, UNION, distinct) niet is gesloten, behoudt Firebird gesorteerde records in het geheugen. De grootte van het geheugen dat is toegewezen voor sortering wordt ingesteld door de parameter TempCacheLimit in firebird.conf, standaard is dit 64Mb.

Zelfs met een verhoogde TempCacheLimit, zullen langlopende queries met een groot aantal gesorteerde records uiteindelijk alle toegewezen hoeveelheid verbruiken, en als gevolg daarvan zal sortering naar tijdelijke bestanden (d.w.z. schijf) gaan. Dit kan leiden tot aanzienlijke traagheid.

De aanbeveling is om al dergelijke queries tijdig te sluiten.

Vragen?

Neem gerust contact met mij op voor vragen: [email protected]!