Afstemmen van een 1,7 Terabyte Firebird SQL-database
Alexey Kovyazin, 14 juli 2014
Zoals u zich herinnert uit onze vorige artikelen, hebben we mythen onderzocht over Firebird prestatievermindering ( /nl/articles/firebird-performance-degradation-tests-myths-and-truth/), waarbij we verschillende databases hebben aangemaakt van 9Gb tot 30Gb, en ook een zeer grote Firebird database (1,7 terabyte) hebben getest (/nl/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Alle tests zijn uitgevoerd op dezelfde hardware, een vrij budgetvriendelijke configuratie: CPU AMD-FX8350, RAM 16GB, SATA software RAID1 2x4Tb HDD Seagate schijven, besturingssysteem Windows Server 2008R2 (2008R2 is 64 bit), en met dezelfde Firebird configuratie: Firebird 2.5.2 64-bit, SuperServer, met verhoogde page buffers en TempCacheSize. U kunt dit SuperServer configuratiebestand gratis downloaden van deze locatie: /nl/optimized-firebird-configuration/
Als resultaat hadden we het volgende beeld van databaseprestaties:
Figuur 1. Prestatievermindering van 9Gb tot 30Gb, en 1,7Tb
Punt #11 is een prestatiewaarde voor de 30Gb database en #12 voor de 1,7 Terabyte database - de databasegrootte is 60 keer toegenomen (van 30Gb naar 1813Gb), het prestatieverlies was 2,4 keer (van 407 naar 169 punten).
Dus de vraag is: kunnen we Firebird prestaties verbeteren op dezelfde hardware met configuratietuning?
En het antwoord is: ja!
FirebirdSQL een boost geven
Zoals u zich herinnert, hebben we in deze test 20 gelijktijdige verbindingen uitgevoerd die intensieve INSERTs en, minder intensieve, UPDATEs uitvoeren.
Alle SELECTs zijn kort en goed gedefinieerd, met effectieve SQL-uitvoeringsplannen, dus dit is een typische OLTP-toepassing (online transactieverwerking). Voor dergelijke toepassingen is parallelle verwerking het meest kritisch voor prestaties. Firebird SuperServer 2.5.2 is niet goed geschikt voor multi-threading verwerking - het gebruikt effectief slechts 1 kern per database, en dit feit maakt SuperServer geen goede keuze voor OLTP-toepassingen.
Dus moeten we de Firebird-architectuur wijzigen naar Classic of SuperClassic, die multi-threading verwerking ondersteunen en meerdere CPU-kernen benutten (er zijn 8 kernen in de CPU AMD-FX8350).
Vervolgens is enige tuning nodig, aangezien de standaardconfiguratie voor Firebird niet optimaal is voor ons testsysteem.
Tuningparameters in firebird.conf
Page cache
Om de OLTP-prestaties te verbeteren, hebben we besloten om Classic- en SuperClassic-architecturen te proberen. Een van de belangrijkste parameters voor Classic en SuperClassic is het aantal page buffers in de cache. In tegenstelling tot SuperServer, wijzen Classic en SuperClassic page cache per verbinding toe.
Voor meer details over Firebird-architecturen in 2.5 kunt u deze tabel bekijken: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Er is een eenvoudige formule om het page cache geheugengebruik voor verschillende Firebird-architecturen te berekenen:
-
- SuperServer - enkele page cache per database. Standaard page cache grootte is 2048 pagina’s, algemene aanbeveling is 10000 buffers. In ons geval was de cache 16k (paginaformaat) x 10000 ~= 160Mb. Dit is voor alle verbindingen.
-
- Classic en SuperClassic - de engine wijst page cache toe voor elke verbinding. Standaardgrootte is 75 pagina’s, dus 16Kb (paginaformaat) x 75 = ~= 1,17 Mb, voor elke verbinding.
Het is duidelijk dat de page cache grootte moet worden verhoogd, aangezien 75 pagina’s per verbinding te laag is. We zullen hieronder de resultaten tonen van verschillende waarden voor de page cache grootte.
LockHashSlots
Intern gebruikt de Firebird-engine een locktabel om vergrendelingen aan te vragen en te verkrijgen voor interne objecten in de database, en voor Classic en SuperClassic is er de parameter LockHashSlots (standaardwaarde is 1009). Deze moet worden verhoogd onder hoge belasting, om hashketens in de locktabel te verminderen. Nou, “hoge belasting” lijkt elke realistische multi-user toepassing te zijn, dus we hebben deze ingesteld op 30011 (voor alle tests).
LockMemSize
De parameter LockMemSize wordt gebruikt om de initiële locktabelgrootte in te stellen (standaardwaarde is 1048576). De engine kan de tabelgrootte op verzoek vergroten. Het vergroten van de locktabel is echter duur in termen van CPU en andere bronnen, omdat dit via geheugenhertoewijzing wordt uitgevoerd. Dus hebben we deze ingesteld op 7Mb, om wat tijd en CPU-bronnen te besparen.
Testruns
We hebben verschillende testruns uitgevoerd met verschillende waarden voor de page cache, met de volgende resultaten:
| Page buffers | Classic, testpunten | SuperClassic, testpunten |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Tabel 1. Testruns voor Classic en SuperClassic
Zoals u kunt zien, zijn Classic en SuperClassic veel effectiever dan Firebird SuperServer voor deze taak: testresultaten verbeterden van 169 punten naar 300-400, dit ligt dicht bij de resultaten die we hadden voor de 30Gb database!
Het is beter om de resultaten te bekijken in de volgende grafiek:
Figuur 2. Testresultaten voor 1,7 Terabyte database
U kunt zien dat de beste prestaties (zowel bij Classic als SuperClassic) werden behaald bij 1500 pagina’s per verbinding, dus de page cache grootte per verbinding was:
1500x16k ~= 23,4Mb
Met 2000 pagina’s per verbinding namen de prestaties aanzienlijk af. Het lijkt erop dat ergens rond 1500-2000 pagina’s het voordeel van caching lager werd dan de overhead veroorzaakt door locktabel-interacties tussen processen om pagina’s in caches van elk serverproces te synchroniseren. Het is duidelijk dat dit bij een hoger aantal verbindingen eerder zal gebeuren, daarom worden Classic/SuperClassic-servers meestal geconfigureerd met waarden zoals 256-512 pagina’s.
Er is ook een daling van Classic-prestaties rond 768-1000 page caches - we weten niet zeker waarom dit is gebeurd.
Samenvatting
Onze experimenten bevestigen dat Firebird-prestaties kunnen worden verhoogd met de juiste keuze van Firebird-architectuur (SuperServer, Classic of SuperClassic) en met een passende tuning van verschillende belangrijke parameters voor de specifieke architectuur.
Als resultaat kan een enorme 1,7 Tb Firebird SQL database werken op low-end hardware met voldoende prestaties. Als praktische output van deze tests hebben we verschillende configuratiebestanden gemaakt voor alle Firebird-versies en alle architecturen. Natuurlijk zijn ze niet afgestemd op de specifieke toepassing en/of hardware, maar ze zijn beter dan de standaardconfiguratiebestanden, die zijn gemaakt voor zeer bescheiden belasting.
Volledige set geoptimaliseerde Firebird-configuratiebestanden: /nl/optimized-firebird-configuration/
Stel gerust vragen: [email protected]
Wat nu?
We werken aan een uitgebreide test die Firebird 2.5 en Firebird 3.0 prestaties zal vergelijken, met realistische simulatie van belasting en een groot aantal verbindingen. Blijf op de hoogte!