Firebird Hardware Guide

door Alexey Kovyazin, laatst bijgewerkt: 30 november 2015

Je ziet vaak de volgende vraag in Firebird technische supportgroepen: “Wat is de hardware van keuze voor het Firebird DBMS?”. Dit onderwerp blijft permanent populair omdat hardwarevereisten verschillen per taak en hardware zelf in de loop van de tijd verandert.

We hebben besloten om deze handleiding te schrijven om de nodige kennis te bieden aan iedereen die echt effectieve hardware voor hun Firebird-database wil kiezen. Om dit te doen, moet je enkele basisdetails leren over hoe Firebird, het besturingssysteem en natuurlijk hardware functioneren.

Een beetje theorie

Om erachter te komen welke hardware het beste bij je Firebird-database past, moeten we begrijpen hoe Firebird zijn componenten gebruikt: CPU, RAM, HDD/SSD en hoe deze componenten interageren met het besturingssysteem (bijvoorbeeld met de bestandscache).

Functionele modules van de Firebird-server

Allereerst zullen we kijken naar de functionele modules van Firebird met behulp van Figuur 1:

Figuur 1. Firebird-modules

Firebird bevat de volgende belangrijkste functionele modules:

1. Metadata-objecten: views, tabellen, indexen, triggers, opgeslagen procedures en andere database-objecten. Metadata-objecten bevinden zich in de adresruimte van het Firebird-proces (dit kan fbserver, fb_inet_server of firebird.exe zijn).

2. De cache van page buffers bevat databasepagina’s die van de schijf zijn gelezen en bevindt zich in de adresruimte van het serverproces. Het mechanisme van het cachen van pagina’s is vrij ingewikkeld, dus we zullen alleen stellen dat Firebird de meest gebruikte databasepagina’s cached.

3. Firebird sorteert records in het geheugen (in de adresruimte van het serverproces) totdat de hoeveelheid geheugen die voor alle gelijktijdige sorteerbewerkingen wordt gebruikt de limiet bereikt die is ingesteld door de parameter TempCacheLimit (firebird.conf). Zodra deze limiet wordt overschreden, wordt een tijdelijk bestand (met de bijbehorende vlag van het besturingssysteem) aangemaakt in de map met tijdelijke bestanden en wordt dit gebruikt voor het sorteren. Als er vrije RAM in het systeem is, wordt het sorteerbestand door het besturingssysteem gecached en wordt het sorteren in het geheugen uitgevoerd.

4. Global Temporary Tables (GTT’s) worden aangemaakt als tijdelijke bestanden in het besturingssysteem. Als het besturingssysteem vrij geheugen heeft, worden bewerkingen met GTT’s in RAM uitgevoerd.

Basisbewerkingen met hardware

Laten we eens kijken hoe de functionele modules van Firebird interageren met hardwarecomponenten tijdens bewerkingen die worden uitgevoerd in de loop van het werken met databases.

Zodra Firebird is gestart, neemt het serverproces de minimale hoeveelheid RAM in beslag (enkele megabytes) en voert het geen intensieve bewerkingen uit met de CPU of RAM.

Wanneer een verbinding met de database tot stand wordt gebracht, begint de server de metadata te lezen en de bijbehorende objecten in het geheugen te creëren, wat ertoe leidt dat het proces meer bronnen gebruikt naarmate er meer tabellen, indexen, triggers en andere metadata worden gebruikt. Het geheugengebruik neemt toe, maar de CPU wordt in dit stadium praktisch niet gebruikt.

Wanneer de client SQL-query’s (inclusief opgeslagen procedures) gaat uitvoeren, voert de server de bijbehorende bewerkingen uit met behulp van hardware. Het is mogelijk om de volgende basisbewerkingen te onderscheiden die interactie met hardware omvatten:

• het lezen van databasepagina’s van de harde schijf,
• het schrijven van databasepagina’s naar de harde schijf,
• het lezen van databasepagina’s uit de cache,
• het schrijven van databasepagina’s naar de cache,
• het lezen van gegevens uit en het schrijven van gegevens naar globale tijdelijke tabellen,
• het verwerken van SQL-query’s (bijvoorbeeld JOIN’s),
• het sorteren van records in resultsets.

Elk van deze bewerkingen vereist een bepaalde hoeveelheid systeembronnen. De onderstaande tabel toont het resourceverbruik in intense eenheden (1 betekent minst intens, 10 betekent meest intens):

	Een pagina van de schijf lezen	Een pagina naar de schijf schrijven	Een pagina uit de page buffers cache lezen	Een pagina naar de page buffers cache schrijven	Lezen uit een GTT	Schrijven naar een GTT	Records sorteren	SQL-query’s verwerken
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Schijf-I/O	10	10	1	1	1	1	1	1

Zoals je kunt zien, zijn de meest resource-intensieve bewerkingen die welke toegang tot de schijf omvatten, omdat schijven het langzaamste hardwareonderdeel blijven, ondanks de vooruitgang in de afgelopen jaren met betrekking tot SSD’s.

Dit leidt tot een van de manieren om de prestaties te optimaliseren die volledig hardwaregerelateerd is: neem alle lees-schrijfbewerkingen naar RAM. Maar let op: de aanpak van het vergroten van de page cache werkt niet. We zullen dit probleem in detail behandelen in het gedeelte over RAM.

Gelijktijdig uitgevoerde bewerkingen

Meestal is het nodig om hardware te kiezen voor een server die veel clients zal bedienen, dus het is echt belangrijk om te begrijpen hoe de paralleliteit van bewerkingen wordt geïmplementeerd.

Vanuit het oogpunt van hardwarecomponenten kunnen we praten over het parallelle gebruik van de CPU, de schijf en RAM. Moderne CPU’s hebben verschillende kernen die sets van instructies parallel kunnen uitvoeren, dus de DBMS-server verdeelt bewerkingen over de kernen, wat betekent dat hoe meer kernen de CPU heeft, hoe meer clients op deze server kunnen werken.

Vanuit het oogpunt van schijven is het niet zo eenvoudig. Wanneer traditionele harde schijven (HDD’s) informatie lezen, bewegen ze fysiek de kop over het magnetische materiaal met een bepaalde eindsnelheid. Een database kan behoorlijk groot zijn, bijvoorbeeld 3 terabyte, en als SQL-query’s van clients parallel toegang krijgen tot gegevens die zich in verschillende gebieden van de schijf bevinden, zal de kop van de schijf tussen verschillende gebieden op de schijf springen, waardoor de lees- en schrijfbewerkingen ernstig worden vertraagd. Dit zal de schijfwachtrij aanzienlijk vergroten terwijl de rest van de bronnen (CPU, RAM) inactief is. Natuurlijk compenseert de schijfcache (de cache van de HDD of van de RAID-controller) deze vertraging tot op zekere hoogte, maar het is niet genoeg.

In tegenstelling tot traditionele HDD’s zijn solid-state drives (SSD’s) veel minder gevoelig voor prestatievermindering bij parallelle toegang tot gegevens. Het voordeel van een SSD is vooral duidelijk wanneer je gegevens parallel schrijft - onze tests tonen aan dat een SSD 7 keer sneller is dan een SATA-schijf (link!). SSD’s hebben echter enkele problemen waarmee rekening moet worden gehouden tijdens het gebruik (zie Schijven selecteren) om vertragingen, vroegtijdige defecten en gegevensverlies te voorkomen.

Bewerkingen met RAM worden zeer snel uitgevoerd op moderne computers, ze worden praktisch alleen beperkt door de bandbreedte van de databus, dus deze bewerkingen vormen geen bottleneck, zelfs niet als er veel parallelle SQL-query’s zijn.

Gegevensstromen

Tijdens het uitvoeren van SQL-query’s leest en schrijft Firebird veel gegevens, brengt het over tussen functionele modules en bijbehorende hardwarecomponenten. Om mogelijke bottlenecks te identificeren, moeten we begrijpen hoe de gegevensuitwisseling wordt uitgevoerd. Figuur 2 hieronder zal ons daarbij helpen:

Figuur 2. Gegevensstromen tussen RAM en permanente opslag

Het is duidelijk dat het overbrengen van gegevens van permanente opslag naar RAM en terug de meest tijdrovende bewerking is. Het creëert twee gegevensstromen: het lezen/schrijven van gegevenspagina’s uit databasebestanden en het lezen/schrijven van sorteerbestanden. Omdat er meerdere sorteerbestanden kunnen zijn en ze behoorlijk groot kunnen zijn, kunnen ze een behoorlijke belasting op de schijven veroorzaken, dus het is raadzaam om deze invoer/uitvoerstromen naar verschillende schijven te leiden.

Back-up

Firebird biedt twee back-upmethoden: geverifieerde back-up met behulp van het hulpprogramma gbak en niet-geverifieerde incrementele back-up met behulp van het hulpprogramma nbackup.

We raden aan om deze back-upmethoden te combineren: voer nbackup vaak uit (bijvoorbeeld elk uur, elke dag en elke week) en maak elke nacht een geverifieerde back-upkopie met behulp van gbak.

Welke back-upmethode je ook gebruikt, het databasebestand wordt gelezen (geheel of gedeeltelijk) en de back-upkopie (volledig of incrementeel) wordt geschreven. Schrijfbewerkingen worden tijdens het back-upproces sequentieel uitgevoerd, wat betekent dat reguliere goedkope harde schijven met de SATA-interface (HDD SATA) goed zullen zijn voor back-up, omdat ze sequentieel vrij snel schrijven.

Het selecteren van de geschikte hardware

Nu we een idee hebben hoe Firebird interageert met hardware, moeten we stilstaan bij de factoren die de keuze van elk afzonderlijk onderdeel en zijn specificaties beïnvloeden.

Soms beïnvloeden de werkelijke statistieken van een bepaalde database sterk de keuze van hardwarecomponenten, dus we zullen tools van HQbird (het professionele distributiepakket van Firebird van IBSurgeon) gebruiken om deze statistieken te verkrijgen. Je kunt de proefversie van HQbird downloaden op http://hqbird.com/en/hqbird/.

CPU

Bij het kiezen van de CPU moet je rekening houden met de volgende drie dingen:

1. Welke query’s overheersen in de applicatie,
2. Het aantal actieve verbindingen met de database gemiddeld en onder piekbelasting,
3. Firebird-versie en -architectuur.

Welke query’s overheersen in de applicatie?

Firebird voert altijd één query uit op één kern, dus complexe en slecht geoptimaliseerde query’s kunnen één kern tot 100% gebruiken, waardoor andere query’s naar minder belaste kernen worden geduwd, en hoe meer kernen er zijn, hoe lager de kans dat de hele CPU wordt gebruikt en dat gebruikers prestatievermindering in de applicatie opmerken.

Als de applicatie voornamelijk eenvoudige korte SQL-query’s uitvoert, alle query’s goed zijn geoptimaliseerd en er geen ad hoc query’s worden gegenereerd (bijvoorbeeld voor rapporten), zal de CPU geen bottleneck vormen voor de prestaties en kun je een goedkope CPU met minder kernen kiezen.

Als de applicatie een rapportgenerator bevat of veel langzame query’s die een grote hoeveelheid gegevens retourneren, heb je een CPU met meer kernen nodig.

Het aantal actieve verbindingen met de database gemiddeld en onder piekbelasting

Het aantal verbindingen (actieve gebruikers) beïnvloedt ook de keuze van de CPU. Helaas hebben zelfs applicatieontwikkelaars geen idee hoeveel verbindingen, query’s en transacties op een bepaald moment actief zijn. Om nauwkeurigere informatie hierover te krijgen, raden we aan om de MON$ Logger-tool van HQbird te gebruiken en een paar snapshots te maken terwijl deze draait, waarop je kunt zien hoeveel verbindingen daadwerkelijk zijn opgezet.

Figuur 3. MON$ Logger: aantal verbindingen

Hier kun je bijvoorbeeld zien dat het aantal verbindingen 296 is. Het is duidelijk te optimistisch om in dit geval een quad-core CPU te gebruiken, terwijl een 24-core oplossing prima zal zijn. Het is ook raadzaam om het aantal gelijktijdig draaiende query’s te tellen, omdat verbindingen inactief kunnen zijn zonder actieve SQL-query’s.

Je kunt de verhouding van 10 tot 30 verbindingen per 1 kern gebruiken om het benodigde aantal kernen in je CPU grofweg te schatten. 10 verbindingen per kern voor een applicatie met voornamelijk ingewikkelde en langzame query’s, 30 verbindingen per kern voor een applicatie met voornamelijk eenvoudige goed geoptimaliseerde query’s.

Firebird-versie en -architectuur

Als je Firebird versie 2.5 gebruikt, let er dan op dat je de Classic- of SuperClassic-architectuur moet gebruiken om verwerking over meerdere kernen te kunnen verdelen. In versie 2.5 kan de SuperServer-architectuur slechts één kern voor één database gebruiken, dus deze mag niet worden gebruikt in systemen die veel bronnen verbruiken.

In Firebird versie 3.0 gebruiken SuperServer, Classic en SuperClassic de functies van multi-core CPU’s. Firebird 3.0 SuperServer toont de beste prestaties.

RAM

Bij het kiezen van RAM moet je op twee dingen letten:

1. de geheugenmodule moet error-correcting code (ECC RAM) hebben
2. de hoeveelheid RAM moet correct worden berekend

ECC RAM

ECC RAM vermindert aanzienlijk het aantal fouten dat optreedt tijdens het werken met geheugen en het wordt sterk aanbevolen om het te gebruiken in industriële systemen.

Berekening van de Benodigde Hoeveelheid RAM

Om de hoeveelheid geheugen te berekenen, moeten we kijken naar de eigenaardigheden van de verschillende Firebird-architecturen. Firebird 2.5 Classic en Firebird 3.0 Classic draaien een apart proces voor elke verbinding, SuperClassic draait een aparte thread voor elke verbinding, maar praktisch met dezelfde geheugenverbruiksstructuur - elke verbinding heeft zijn eigen onafhankelijke paginacache.

Firebird SuperServer draait één proces met één paginacache voor alle verbindingen.

De volgende parameters beïnvloeden dus het totale geheugenverbruik:

1. Aantal verbindingen
2. Databasepaginagrootte
3. Metadatagrootte (evenredig met het aantal tabellen, triggers, opgeslagen procedures, enz.; niet aanpasbaar; bepaald door fysiek gebruik)
4. Voor Classic en SuperClassic - per verbinding
5. Voor SuperServer - per instantie van een geopende database
6. Paginacachegrootte (bepaald door de parameters in de databasekop of in firebird.conf of in de eigenschappen van een specifieke verbinding)
7. Voor Classic en SuperClassic - per verbinding
8. Voor SuperServer - per instantie van een geopende database
9. Sorteercachegrootte (bepaald door de parameter in firebird.conf). Merk op dat geheugen voor sorteren niet in één keer wordt toegewezen, maar alleen wanneer dat nodig is.
10. Voor Classic - per verbinding
11. Voor SuperServer en SuperClassic - per proces (d.w.z. één sorteercache)
12. Voor Classic/SuperClassic - lock-tabelgrootte (deze is meestal klein, dus we laten deze buiten onze berekening).

Het IBSurgeon-bedrijf heeft een aantal tests uitgevoerd en een reeks optimale waarden verkregen voor het aantal pagina’s in de Firebird-paginacache:

• Classic/SuperClassic - van 256 tot 2000 pagina’s
• SuperServer 2.5 - 10000 pagina’s
• SuperServer 3.0 - 100000 pagina’s

Op basis van deze tests hebben we geoptimaliseerde Firebird-configuratiebestanden gemaakt voor servers met 4-6 GB geheugen. U kunt ze hier downloaden: /nl/optimized-firebird-configuration/

Formules voor het Berekenen van de Benodigde Hoeveelheid RAM

Hieronder ziet u formules die worden gebruikt om de geschatte hoeveelheid geheugen te berekenen die Firebird nodig zal hebben. Het werkelijke geheugenverbruik kan verschillen, aangezien deze schatting geen rekening houdt met de hoeveelheid geheugen die nodig is voor metadata, voor de bitmaskers van indexen, enz., wat het geheugenverbruik kan verhogen. Er wordt echter ook aangenomen dat het sorteergeheugen in alle verbindingen volledig zal worden gebruikt, wat meestal niet het geval is.

Wanneer uw database al in gebruik is, kunt u kijken naar de gemiddelde hoeveelheid geheugen die door het Firebird-proces wordt gebruikt (met behulp van Taakbeheer of Process Explorer).

Schatting voor Classic:

Aantal verbindingen * ( (Aantal pagina’s in cache * Paginagrootte) + Sorteercachegrootte )

Voorbeeld voor Classic: stel dat we 100 actieve gebruikers verwachten, de databasepaginagrootte is ingesteld op 8 KB en het aantal pagina’s in de paginacache is ingesteld op 256, de sorteercachegrootte is verhoogd van 8 MB (de standaardwaarde voor Classic en SuperClassic) naar 64 MB:

100. ((256.8 KB)+64) = 6600 MB

Schatting voor SuperClassic:

Aantal verbindingen * (Aantal pagina’s in cache * Paginagrootte) + Sorteercachegrootte

Voorbeeld voor SuperClassic: 100 gebruikers, de databasepaginagrootte is 8 KB, het aantal pagina’s in de paginacache is 256, de sorteercachegrootte is 1024 MB

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

Schatting voor SuperServer:

(Aantal pagina’s in cache * Paginagrootte) + Sorteercachegrootte

Voorbeeld voor SuperServer (Firebird 2.5): 1 database, 100 gebruikers, de databasepaginagrootte is 8 KB, het aantal pagina’s in de paginacache is 10000, de sorteercachegrootte is 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Voorbeeld voor SuperServer (Firebird 3.0): 1 database, 100 gebruikers, de databasepaginagrootte is 8 KB, het aantal pagina’s in de paginacache is 100000, de sorteercachegrootte is 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Overmatig Geheugen”

Firebird wordt vaak bekritiseerd vanwege ineffectief geheugengebruik - wanneer het draaiende proces van de server een kleine hoeveelheid RAM verbruikt en de rest van het geheugen zogenaamd ongebruikt blijft.

Eigenlijk is dit niet waar. Deze conclusie berust voornamelijk op een misverstand over hoe het Firebird-cachemechanisme werkt en op de onvolkomenheid van de monitoringtools van het besturingssysteem.

Allereerst moet u zich er absoluut van bewust zijn dat Firebird uitgebreid gebruikmaakt van de bestandscache van het besturingssysteem. Wanneer een pagina in de Firebird-paginacache wordt geladen, gaat deze door de bestandscache van het besturingssysteem. Wanneer Firebird een pagina uit zijn paginacache verwijdert, blijft het besturingssysteem dit deel van de database in zijn RAM houden, op voorwaarde dat er voldoende vrij geheugen over is.

Figuur 4. Cacheniveaus: Firebird, besturingssysteem en opslag

Als u er echter alleen naar kijkt, toont het besturingssysteem het geheugen dat aan de bestandscache is toegewezen niet als gebruikt. Hier is bijvoorbeeld de typische situatie van geheugenverdeling wanneer de Firebird-server draait, zoals weergegeven door Taakbeheer:

Figuur 5. Taakbeheer toont het gebruik van de bestandscache niet

Het lijkt alsof er slechts 6,3 GB van de 16 GB wordt gebruikt.

Als u echter de RAMMap-tool gebruikt (van SysInternals door Microsoft), ziet het er allemaal veel logischer uit:

Figuur 6. RAMMap toont details over geheugengebruik: toegewezen bestanden zijn gecachte databases

Databasebestanden (dbw350.fb252x64.fdb en dbw250.fb252x64.fdb) worden door het besturingssysteem gecacht en nemen het hele geheugen in beslag dat door Taakbeheer als vrij wordt aangegeven:

Figuur 7. RAMMap: details over het gebruik van de bestandscache

Hieruit concluderen we dat het besturingssysteem effectief al het beschikbare geheugen gebruikt om de database te cachen, totdat de database volledig in het geheugen is geladen.

Schijfsubsysteem

De juiste configuratie van het schijfsubsysteem speelt een belangrijke rol bij het kiezen en configureren van hardware voor Firebird, omdat fouten in deze stap zullen leiden tot grote storingen die moeilijk te verhelpen zijn.

Aparte Schijven voor Alles

Om concurrentie voor de schijfinput/output tussen bewerkingen met het databasebestand te verminderen en de kans op gelijktijdig verlies van database en back-up te verkleinen, wordt aanbevolen om drie verschillende schijven (of RAID-arrays) te hebben: één voor de database, één voor tijdelijke bestanden en één voor het maken en opslaan van back-upkopieën.

Wanneer we “aparte schijven” zeggen, betekent dit dat datastromen door verschillende input/outputkanalen moeten gaan. Als u drie logische schijven op één fysieke schijf maakt, zal er geen prestatieverbetering zijn. Als u echter drie logische schijven op een gegevensopslagapparaat met multichannelcontrollers inricht, zal de prestatie hoogstwaarschijnlijk toenemen omdat het apparaat datastromen over controllers kan verdelen. Soms wordt gezegd dat het toewijden van een aparte schijf aan het opslaan van besturingssysteembestanden en het wisselbestand van het besturingssysteem de prestaties verhoogt.

SSD voor een Database

SSD is de beste keuze voor het werken met een database omdat ze geweldige schaling garanderen tijdens parallelle input/output. Het is een must om enterprise-schijven te gebruiken met een verhoogd aantal lees-/schrijfcycli, anders is het zeer waarschijnlijk dat u gegevens verliest door een SSD-storing.

Enige tijd geleden waren SSD’s gevoelig voor verhoogde slijtage wanneer er weinig vrije ruimte op de schijf was (minder dan 30%). Simpel gezegd wordt elke wijziging op een SSD naar een nieuwe vrije cel geschreven, dus het gebrek aan vrije ruimte leidde tot verhoogde slijtage van de cellen die vrij bleven en tot een kortere levensduur van de schijf.

Fabrikanten van moderne SSD-controllers verklaren dat dit probleem is opgelost door preventief statische gegevens te verplaatsen en dat de slijtage van cellen nu min of meer gelijkmatig is. De exacte specificaties en operationele algoritmen van SSD’s worden echter geheim gehouden door fabrikanten, dus we raden nog steeds aan om 30% ruimte op SSD’s vrij te laten, evenals om hun verwachte levensduur te verminderen en te plannen om ze minstens eens in de drie jaar te vervangen.

Stel dat de grootte van uw database momenteel 100 GB is en deze groeit met 1 GB per maand. In dit geval moet u geen SSD van minimale grootte (120 GB) kopen, maar is het beter om het volgende apparaat in de productlijn te kiezen - 250 GB. Tegelijkertijd is het kopen van een 512-gigabyte SSD geldverspilling, aangezien het raadzaam is om de schijf over drie jaar te vervangen.

De beste praktijk is om een SSD uitsluitend te besteden aan het werken met de database, aangezien elke input/outputbewerking de levensduur van schijven verkort.

Schijf voor Tijdelijke Bestanden

Aangezien tijdelijke bestanden alleen op de schijf verschijnen wanneer er niet genoeg RAM is, is de beste manier om deze situatie natuurlijk te vermijden. Het is mogelijk om het aantal en de grootte van tijdelijke bestanden in een productiesysteem te evalueren door alleen de map met tijdelijke bestanden te monitoren. FBDataGuard uit het HQbird-distributiepakket doet dat soort monitoring. Zodra u weet hoeveel tijdelijke sorteervoorzieningen er op de schijf worden gemaakt en wanneer ze worden gemaakt, kunt u de hoeveelheid RAM vergroten en de configuratie in firebird.conf wijzigen.

In elk geval vereist Firebird dat u de map opgeeft waar tijdelijke bestanden worden opgeslagen. Meestal wordt de standaardwaarde ongewijzigd gelaten, d.w.z. de map voor tijdelijke bestanden van het besturingssysteem wordt gebruikt. Als er voldoende vrij RAM is, is dit een goede keuze.

Er is echter nog een ander belangrijk probleem met betrekking tot de locatie van tijdelijke bestanden op de schijf - het is het maken van indexen wanneer u een geverifieerde back-upkopie herstelt (gemaakt met het gbak-hulpprogramma). Wanneer een index wordt gemaakt, wordt ook een tijdelijk bestand gemaakt dat alle sleutels van deze index bevat. Als de database vrij groot is, kan de grootte van de index voor een grote tabel ook vrij groot zijn. Bijvoorbeeld, de index van de grootste tabel met 3,2 miljard records in een database van 1 terabyte is 29 GB, maar het kostte 180 GB vrije ruimte om deze index te maken:

Om het gebrek aan vrije ruimte op de systeemschijf te voorkomen, is het mogelijk om nog een schijf op te geven als extra gereserveerde ruimte in firebird.conf:

TempDirectories =C:\temp; H:\Temp

Als er geen ruimte op de eerste schijf is, zal Firebird de tweede schijf blijven gebruiken voor tijdelijke bestanden, enzovoort.

HDD voor Back-ups

Reguliere HDD’s met de SATA- of nSAS-interface zijn prima voor het maken en opslaan van back-upkopieën. Ze garanderen snelle sequentiële schrijf- en leesbewerkingen voor back-upbestanden en zijn goedkoop genoeg om niet op hun grootte te besparen en meerdere back-upkopieën te bewaren.

Schijven voor back-upkopieën moeten altijd extra vrije ruimte hebben: de grootte van de nieuwste back-upkopie + 10%. In dit geval is het mogelijk om een verse back-upkopie te maken, ervoor te zorgen dat het back-upproces succesvol is voltooid (dit proces kan enkele uren duren voor een database met een grootte van enkele terabytes) en pas daarna de vorige back-upkopie te verwijderen.

Als u de vorige back-upkopie verwijdert voordat de nieuwe is gemaakt, is het mogelijk dat er geen nieuwe back-upkopie wordt gemaakt terwijl de oude al is verwijderd en de database beschadigd raakt, bijvoorbeeld door een schijfstoring.

Als u de hierboven aanbevolen back-upmethode gebruikt (de combinatie van incrementele back-up op drie niveaus en geverifieerde back-up eenmaal per dag met slechts één nieuwste kopie), gebruik dan de volgende formule om de minimale ruimte voor back-up te berekenen:

Database_grootte*3+0.2.Database_grootte

Laten we de volgende voorbeeldberekening van de benodigde ruimte voor back-up bekijken:

Stel dat we een database van 100 GB hebben waarvoor we incrementele back-up op drie niveaus opslaan (week-dag-uur - één kopie elk) en één kopie van dagelijkse geverifieerde back-up. In dit geval nemen back-upkopieën de volgende ruimte in beslag:

• Nbackup_level_0.wekelijks - 100 GB
• Nbackup_level_1.dagelijks - 5 GB (ongeveer)
• Nbackup_level_2.uur - 200 MB (ongeveer)
• Dagelijkse geverifieerde back-up - 100 GB (ongeveer)
• Plus u heeft 110 GB gereserveerd nodig om de volgende back-upkopie te kunnen maken.

Totaal - 316 GB.

! de grootte van het eerste niveau incrementele bestand of hoger hangt af van het aantal pagina’s dat is gewijzigd sinds de laatste keer dat nbackup werd uitgevoerd. De grootte van deze bestanden kan alleen experimenteel worden bepaald, aangezien de hoeveelheid wijzigingen in een database afhangt van de applicaties.

Uiteraard moet bij de schatting van de ruimte voor back-ups rekening worden gehouden met een mogelijke abnormale toename van de databasegrootte en moet de hoeveelheid vrije ruimte dienovereenkomstig worden vergroot, anders kan het back-upproces onverwacht worden onderbroken door ruimtegebrek.

Natuurlijk zullen slimme back-up tools (FBDataGuard van HQbird) het ruimtegebrek voor back-upkopieën opmerken en de bijbehorende melding naar de beheerder sturen.

HDD voor een Database

Een SSD kan een te dure oplossing blijken te zijn of de database kan te groot zijn en u zult goedkopere methoden moeten gebruiken. In dat geval moet u een HDD met de SAS-interface gebruiken. Als dat niet mogelijk is, gebruik dan SATA-schijven met de nSAS-interface of de goedkoopste optie - gewone SATA-schijven.

Om de snelheid (en ook de betrouwbaarheid - zie hieronder) van de harde schijven te verhogen, moet u ze combineren in RAID10. RAID10 is een combinatie van gespiegelde (RAID1) en gestreepte (RAID0) blokken. Een goede en goed geconfigureerde RAID-controller met grote cache is een mooi alternatief voor SSD’s.

Betrouwbaarheid en RAID

Het is uiteraard noodzakelijk om de betrouwbaarheid van het schijfsubsysteem te vergroten door schijven in RAID te combineren, in alle hierboven genoemde varianten (behalve voor de schijf die uitsluitend is bestemd voor tijdelijke bestanden).

• Zorg bij SSD’s dat u RAID1 gebruikt - d.w.z. twee gespiegelde schijven waarop wijzigingen gelijktijdig worden geschreven, waardoor de kans om alle gegevens te verliezen aanzienlijk kleiner wordt. RAID 10 bestaande uit SSD’s zal hoogstwaarschijnlijk overbodig zijn, omdat de RAID-bus de doorvoer zal beperken. De 6 Gbit/s-interface heeft bijvoorbeeld een doorvoer van 600 megabytes per seconde, terwijl moderne individuele SSD’s deze snelheid al hebben bereikt. Zo krijgen we dezelfde limiet van 600 MB/s voor RAID 10.

Behalve dat u PCI Express 3.0 kunt gebruiken om SSD’s in RAID 10 te combineren, omdat de doorvoer van deze bus al 16 gigabits per seconde of hoger is.

• Als u HDD’s gebruikt voor back-updoeleinden, is RAID1 voldoende om de veiligheid van back-upkopieën en een acceptabele lees- en schrijfsnelheid te garanderen.

• HDD’s die voor een database worden gebruikt, moeten worden gecombineerd in RAID10 (minimaal 4 schijven) die de optimale combinatie van kosten, betrouwbaarheid en prestaties bieden. Sommige gebruikers gebruiken ook RAID5, waarbij ze prestaties opofferen voor meer ruimte.

RAID-configuratie voor Firebird

Allereerst moet u ervoor zorgen dat er een goed opgeladen back-upbatterij-eenheid (BBU) in de RAID aanwezig is. Als er geen dergelijke batterij-eenheid is, schakelen de meeste RAID-systemen over naar de veilige schrijfmodus (de schijfcache is volledig uitgeschakeld), wat een lagere invoer/uitvoer-snelheid oplevert dan een gewone SATA-schijf!

Dit feit veroorzaakt de meeste gefrustreerde berichten aan technische ondersteuning van gebruikers die een dure server hebben gekocht en ontdekten dat deze langzamer werkt dan een desktopcomputer. Helaas leveren sommige leveranciers geen batterij-eenheden standaard mee, daarom is dit het eerste dat u moet controleren en indien nodig verhelpen.

Vervolgens moet u de lees- en schrijfcache configureren. Vaak is de cache standaard uitgeschakeld en als u RAID redelijk snel wilt maken, moet u de cache inschakelen.

Naast het inschakelen van de cache, moet u controleren hoe deze werkt - het kan write through en write back zijn. De snelle manier om met cache te werken is write back - in dit geval worden wijzigingen naar de cache-controller geschreven en na een tijdje rechtstreeks naar de schijf.

U kunt tools van fabrikanten die bij RAID worden geleverd gebruiken om de batterij-eenheid, cache en modus te controleren.

Moderne RAID-controllers kunnen de cache ook fijn afstellen - deze kan worden aangepast om lezen of schrijven te vergemakkelijken. Meestal wordt deze 50%/50% verdeeld voor lezen en schrijven.

Om te ontdekken hoe u de cache precies moet configureren, kunt u ook de MON$ Logger-tool uit het geavanceerde HQbird-distributiepakket gebruiken. Deze toont de verhouding van lees- en schrijfbewerkingen ten opzichte van elkaar (geaggregeerd vanaf het moment van de eerste verbinding met de server):

Figuur 8. HQbird MON$Logger: lees/schrijf-verhouding

Zoals u kunt zien, zijn er in dit voorbeeld veel meer leesbewerkingen dan schrijfbewerkingen, dus het is zinvol om de RAID-controller te configureren voor 80% leesbewerkingen en 20% schrijfbewerkingen.

SAN en databases

Geïntegreerde opslagsystemen zijn de laatste tijd populair geworden. Ze omvatten een flexibel aanpasbare schijvenarray (alle typen RAID) met geavanceerde caching-functies. Meestal hebben SAN’s meerdere invoer/uitvoer-controllers, waardoor het mogelijk is om meerdere servers tegelijk te bedienen en redelijk snel te werken.

Veel organisaties kopen SAN’s en gebruiken ze bij hun werk met Firebird-databases. Als een SAN correct is geconfigureerd, is het mogelijk om goede prestaties te bereiken. U moet rekening houden met de volgende punten als u SAN gebruikt:

1. Er moeten verschillende krachtige schijfcontrollers beschikbaar zijn die een multi-channel gegevensuitwisseling mogelijk maken.
2. Back-upbatterij-eenheden (BBU) moeten aanwezig zijn als ze volgens het ontwerp zijn voorzien.
3. Databaseschijven moeten worden gecombineerd in RAID10.
4. De cache moet zijn ingeschakeld en de schrijfmodus moet zijn ingesteld op write back.
5. Als er meerdere computers op de SAN zijn aangesloten, moet elk daarvan een eigen controller hebben.
6. De nieuwste SAN-stuurprogramma’s zijn geïnstalleerd. We zijn gevallen tegengekomen waarbij later geleverde stuurprogramma’s een prestatieverbetering van 30% opleverden.
7. Als er meerdere logische schijven op een SAN zijn (voor databases, back-upkopieën, besturingssysteem), hebben deze verschillende invoer/uitvoer-kanalen. Een poging om één kanaal voor alle schijven tegelijk te gebruiken, zal leiden tot lagere prestaties.
8. Evenzo, als meerdere servers en databases tegelijkertijd een SAN gebruiken, kunnen de prestaties lager zijn door de verhoogde bandbreedte van invoer/uitvoer-controllers.
9. Gecombineerde methoden worden vaak gebruikt - waarbij het besturingssysteem en tijdelijke bestanden op lokale schijven worden opgeslagen, terwijl de database en back-upbestanden op een SAN worden opgeslagen.

Vaak worden SAN’s gebruikt als “twee servers - één SAN” om een storingsbestendig cluster te creëren. Opgemerkt moet worden dat een dergelijk cluster alleen problemen kan oplossen die verband houden met hardwarestoringen op een van de servers door onmiddellijk over te schakelen naar de tweede server. Als het probleem verband houdt met de SAN of met de database zelf, zal deze oplossing niet helpen.

Om een werkelijk storingsbestendige oplossing te bouwen, moet u oplossingen gebruiken die gegevens repliceren tussen twee database-instanties. U kunt contact opnemen met [email protected] om meer beschikbare oplossingen voor Firebird te ontdekken.

Korte Conclusies en Aanbevelingen

Laten we conclusies en aanbevelingen voor Firebird met betrekking tot hardware samenvatten.

1. Multi-core CPU’s moeten worden gebruikt om een groot aantal gebruikers te bedienen.
2. De minimale hoeveelheid RAM wordt berekend op basis van het aantal gebruikers en de databaseconfiguratie; de overtollige hoeveelheid RAM zal effectief door het besturingssysteem worden gebruikt om het databasebestand te cachen.
3. Gebruik aparte schijven voor databases, tijdelijke bestanden en back-upbestanden.
4. Gebruik liever SSD’s voor databases.
5. Reserveer minimaal 30% vrije ruimte op SSD’s.
6. Het is raadzaam om een schijf aan de database te wijden.
7. Gebruik enterprise SSD’s (met veel schrijf-/leescycli).
8. Zorg ervoor dat u RAID gebruikt.
9. Voor SSD - RAID 1, voor HDD - RAID10, voor back-up HDD - RAID1. i. SAS, SATA, nSAS
10. Zorg ervoor dat de RAID-batterij aanwezig en opgeladen is.
11. Zorg ervoor dat deze is ingesteld op write back.
12. Sommige RAID-controllers hebben de cachegrootte al geconfigureerd, bijvoorbeeld 75% voor lezen, 25% voor schrijven, of 50/50 enz. Het is dus noodzakelijk om MON$Logger te installeren - de software die RAID-parameters controleert, de lees/schrijf-verhouding bekijkt en de RAID-instellingen wijzigt.
13. Er zijn voor- en nadelen aan het gebruik van SAN’s. Om er het maximale uit te halen, moet u de SAN correct configureren.
14. Om een storingsbestendige oplossing te bouwen, moet u oplossingen gebruiken met replica’s die op verschillende servers draaien.

Contacten

Het bedrijf IBSurgeon/IBase.ru ontwikkelt een geavanceerd HQbird-distributiepakket voor bedrijven, biedt complexe technische ondersteuning voor Firebird en ontwikkelt op maat gemaakte distributiepakketten, evenals het oplossen van andere complexe problemen.

IBSurgeon biedt ook Firebird Optimalisatieservice om de prestaties van Firebird-databases te verbeteren.

Neem contact met ons op: [email protected]