Firebird-prestatievermindering: tests, mythen en de waarheid
Alexey Kovyazin, 16 mei 2014
U kunt dit artikel downloaden in PDF-formaat.
Onlangs hebben we bij IBSurgeon een reeks prestatietests uitgevoerd met Firebird 2.5.2. Firebird 2.5.2 is de meest populaire versie van de Firebird-database, en gebruikers hebben vaak vragen met betrekking tot de prestaties van Firebird.
Een van de belangrijkste zorgen met betrekking tot databaseprestaties is de achteruitgang ervan. Veel gebruikers beweren dat hun databaseapplicaties prestatieproblemen krijgen wanneer een bepaalde drempelwaarde wordt bereikt: dit kan 3 GB, 5 GB, de grootte van het RAM-geheugen, 20 GB, enz. zijn. De meest voorkomende bewering is “databasegrootte is groter dan RAM-grootte”: wanneer de Firebird-databasegrootte de RAM-grootte bereikt, zou deze erg langzaam worden… Is dat waar?
We hebben besloten een reeks tests uit te voeren om te controleren of er sprake is van een dergelijke prestatieachteruitgang die verband houdt met databasegroei. We besloten de levenslange groei van de database te simuleren met dezelfde belasting op dezelfde hardware, en hiervoor hebben we 11 tests uitgevoerd met databases van tussen de 9 GB en 30 GB:
Figuur 1. Databasegroottes voor tests
Testhardware en Firebird-configuratie
De testhardware had de volgende belangrijke kenmerken:
CPU AMD-FX8350, RAM 16 GB, SATA software RAID1 2x4Tb Seagate-schijven, besturingssysteem Windows Server 2008R2 (2008R2 is 64 bit).
Zoals u kunt zien, is dit een low-end hardwareconfiguratie; deze kan op dit moment (mei 2014) worden gekocht voor minder dan USD 1000, en kan worden beschouwd als een typische low-level configuratie - misschien met uitzondering van de grote SATA-schijven, maar volgens het fabrieksrapport is de snelheid van 1 TB en 4 TB SATA-schijven bijna hetzelfde.
Aangezien het doel van de test was om prestatieveranderingen van een typisch systeem te meten, hebben we Firebird (64 bit) met SuperServer-architectuur gebruikt, niet Classic, om de situatie in een klein bedrijf volledig te simuleren - zij gebruiken wat oorspronkelijk jarenlang is geïnstalleerd. Zoals u weet, gebruikt SuperServer slechts 1 CPU-kern, dus waarschijnlijk zou Classic of SuperClassic (die alle CPU-kernen kan gebruiken) betere resultaten kunnen laten zien qua prestaties, maar ons doel was niet prestatieoptimalisatie.
We hebben echter firebird.conf aangepast met de voor de hand liggende wijzigingen die we aanbevelen voor alle Firebird SuperServer-installaties: verhoogde page buffers naar 10000 en tijdelijke ruimte voor sorteren.
Alle testdatabases zijn gemaakt met een paginagrootte van 16384, alleen voor consistentie.
Testen
Laden
Elke test bestond uit 2 stappen: laden en simulatie van 20 terminals die inserts, updates en deletes uitvoeren.
De laadstap wordt uitgevoerd door een loader-applicatie (load.exe), die gegevens in verschillende tabellen invoegt. Zoals u in figuur 2 kunt zien, worden gegevens met verschillende snelheden geladen; dit varieert van ~35 MB/sec tot 1 MB/sec.
Figuur 2. Database laadsnelheid (rode grafiek)
Dit houdt verband met het ontwerp van de loader-applicatie, niet met Firebird: de loader voegt snel 70% van de database in en vult vervolgens langzaam de rest van de gegevens aan, en dit wordt herhaald met databases van alle groottes. Het is belangrijk voor ons dat de loader dezelfde bewerkingen uitvoert, zodat we de gemiddelde snelheid kunnen gebruiken om de laadsnelheid te meten.
Het is belangrijk om te vermelden dat de loader alleen gegevens invoegt, en dat indexen worden aangemaakt nadat het laden is voltooid.
Laten we naar de tabel met resultaten voor de laadstap voor 11 databases tussen 9 en 30 GB kijken:
| # | databasegrootte, GB | laadtijd, sec | SATA laadsnelheid, MB/sec |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Figuur 3 Laadtijd en -snelheid
Of het is beter om dit op de grafiek in figuur 4 te tonen:
Figuur 4. Testresultaten: laadsnelheid.
Zoals u kunt zien, is er een vrij stabiele grafiek, en de gemiddelde snelheid voor het laadproces varieert rond 3,3-3,4 MB/sec. Er zijn ook geen tekenen van afnemende laadsnelheid wanneer de databasegrootte groter wordt dan de RAM-grootte (na database #5, met een grootte van 17,3 GB).
Prestaties
De laadtijden zien er dus veelbelovend uit, maar wat zijn de werkelijke prestatieresultaten?
Voordat we naar de prestatieresultaten gaan, laten we kort het simulatieproces bekijken.
De simulatie draait 20 threads, en elk daarvan voert willekeurig verschillende bedrijfsbewerkingen uit: nieuwe bestelling aanmaken, betaling verwerken, producten in voorraad tellen, bestelbezorging verwerken, enz. (voor details kunt u kijken naar de SQL-teksten van de daadwerkelijke opgeslagen procedures). Zoals u kunt zien, is dit een gebruikelijke set bedrijfsbewerkingen van een abstracte voorraad-/verkoopapplicatie.
De testapplicatie meet het aantal bedrijfsbewerkingen per seconde en rapporteert een gemiddeld aantal. Natuurlijk is dit aantal een kunstmatige parameter, maar het is goed genoeg voor vergelijking.
Prestatietestresultaten:
| # | databasegrootte, GB | prestaties op SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Figuur 5. Tabel met prestatietestresultaten.
Of het is beter om de resultaten in grafische weergave te bekijken:
Figuur 6. Prestatieresultaten grafiek
Zoals u kunt zien, is er een langzame prestatieachteruitgang met de groei van de databasegrootte - hoe groter de database, hoe langzamer deze zal werken (op dezelfde hardware). Er is ook geen grote prestatieval wanneer de databasegrootte groter wordt dan het RAM-geheugen. Databasegroei van 9 GB naar 30 GB leidt tot ongeveer 20% prestatieverlies.
30 GB Firebird-databases zijn tegenwoordig overal aanwezig, en ze groeien en groeien in de loop van de tijd. Maar wat gebeurt er met de databaseprestaties wanneer deze nog groter wordt? We bedoelen - GROTER! Wat gebeurt er met de prestaties wanneer de database ECHT GROOT wordt?
Mr.Big
Om deze vraag te beantwoorden, hebben we besloten om naar het uiterste einde van de testtabel te kijken en een test uit te voeren met een database van 1,7 TB (1813 GB), op dezelfde hardware, met dezelfde instellingen.
Laden
We hebben dus zo’n database gemaakt:
Figuur 7. Databasegrootte - nu met 1813 GB database
Het laden duurde 566448 seconden - 157 uur, 6,55 dagen. Dat is een lange tijd, maar de gemiddelde laadsnelheid was… 3,28 MB/sec!
| # | databasegrootte, GB | laadtijd, sec | SATA laadsnelheid, MB/sec |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Figuur 8. Laadtijd en -snelheid voor 1,7 TB Firebird-database
Op de grafiek ziet het er erg goed uit: het laatste punt (#12). Firebird toont dus zeer goede resultaten van zijn invoegalgoritmen.
Figuur 9 Laadsnelheid - punt #12 is voor 1,7 TB Firebird-database
Prestaties van Mr.Big
Vervolgens hebben we dezelfde prestatietest uitgevoerd - regel 12 is voor de 1,7 TB database.
| # | databasegrootte, GB | prestaties op SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Figuur 10. Prestatietestresultaten - regel 12 is voor 1,7 TB database
En op de grafiek:
Figuur 11. Prestaties, punt #12 is voor 1,7 TB database
Het resultaat bevestigt dat er een langzame en stabiele prestatieachteruitgang is in Firebird - terwijl de databasegrootte 60 keer is gegroeid (van 30 GB naar 1813 GB), was het prestatieverlies 2,4 keer (van 407 naar 169 punten).
Het is geen veelvoorkomende situatie dat een database (op dezelfde low-end hardware) groeit van 30 GB naar 1,7 TB, maar Firebird zal zelfs in deze situatie werken.
Grote database in detail
Om de 1,7 TB database beter te begrijpen, hebben we databasestatistieken voor de Mr.Big-database verzameld en geanalyseerd in IBAnalyst:
Figuur 12 Tabellen van 1,7 TB database in IBAnalyst
Zoals u kunt zien, zijn er 2 grote tabellen - ORDER_LINE (~600 GB) met 6,3 miljard records en STOCK (~680 GB) met 2,1 miljard records.
En voor deze tabellen zijn er 2 indexen met diepte = 4 - dit betekent dat elk verzoek 4 leesbewerkingen van indexpagina’s uitvoert vóór het daadwerkelijk lezen van de gegevens. De ORDER_LINE_PK-index heeft een grootte van 50 GB.
Figuur 13. Indexen van Firebird 1,7 TB database
Ondanks het enorme aantal records zien de databasestatistieken er goed uit, dus het is niet verrassend dat Firebird vrij goede resultaten toont, zelfs voor een grote database op low-end hardware.
Firebird testen met SSD-schijf
Na het voltooien van de reeks Firebird-tests op low-end hardware, hebben we besloten om te controleren wat de resultaten zouden zijn aan de andere kant van de gegevensopslagtechnologie en hebben we een SSD-schijf op dezelfde server geïnstalleerd.
We hebben een SSD-schijf Plextor PX-256M M5 Pro geïnstalleerd en dezelfde reeks tests uitgevoerd (behalve de 1,7 TB database), met dezelfde instellingen. Resultaten zijn toegevoegd aan de grafieken met SATA-apparaten, zie hieronder.
Laden
Zoals u kunt zien, is de laadtijd op SSD hetzelfde als op SATA. Dit is een verwacht resultaat: de snelheid van sequentiële schrijfbewerkingen is bijna hetzelfde op SATA- en SSD-schijven.
Figuur 14. Laden op SSD en SATA
Prestaties
Zie de prestatieresultaten:
Figuur 15. Prestaties op SSD en SATA
Zoals u kunt zien, tonen prestaties met willekeurige IO-bewerkingen ~8x betere resultaten voor SSD-schijven. We wisten uit onze ervaring met klantdatabases dat SSD 30-50% sneller is met real-world applicaties, maar een 8x toename is zeer hoog.
Deze test is echter kunstmatig en speciaal ontworpen om zware OLTP-bewerkingen te simuleren, met veel updates/deletes, maar zonder grote fetches. Een gebruikelijke databaseapplicatie werkt niet altijd in deze modus. Dit verklaart waarom SSD in dit specifieke geval zulke hoge resultaten toont.
Samenvatting
Wat hebben we dus geleerd van deze tests?
Ten eerste - de prestaties van Firebird hebben geen grote dalingen die verband houden met een bepaalde groottebeperking. Op dezelfde hardware zullen de prestaties langzaam afnemen met de groei van de databasegrootte. Een dergelijke prestatieachteruitgang kan worden gecompenseerd met het afstemmen van de Firebird-configuratie of met een slimme hardware-upgrade.
Het is een goed moment om te vermelden dat IBSurgeon een Firebird prestatieoptimalisatieservice aanbiedt - met behulp van experimentele gegevens die we uit tests zoals deze hebben verzameld, kunnen we de prestaties van Firebird- en InterBase-databases aanzienlijk verbeteren.
Ten tweede wisten we dat zelfs zeer grote Firebird-databases (1,7 terabyte) op low-end hardware zullen werken met aanzienlijk, maar acceptabel prestatieverlies.
En ten derde is SSD echt goed voor OLTP-applicaties. Waarschijnlijk is dit de goedkoopste manier om de databaseprestaties op dit moment te verbeteren. Natuurlijk zal het gebruik van SSD geen problemen met slechte queryplannen en ineffectieve indexen oplossen, maar het kan de prestaties in het algemeen verhogen.
Wordt vervolgd: Meer details over een Firebird-database van 1,7 terabyte.