Alexey Kovyazin, 14-luglio-2014

Come ricorderete dai nostri articoli precedenti, abbiamo indagato sui miti riguardanti il degrado delle prestazioni di Firebird ( /it/articles/firebird-performance-degradation-tests-myths-and-truth/), dove abbiamo creato diversi database da 9Gb a 30Gb, e abbiamo anche testato un database Firebird molto grande (1,7 terabyte) (/it/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

Tutti i test sono stati eseguiti sullo stesso hardware, che è una configurazione di fascia bassa: CPU AMD-FX8350, RAM 16GB, RAID1 software SATA 2x4Tb HDD Seagate, sistema operativo Windows Server 2008R2 (2008R2 è a 64 bit), e con la stessa configurazione di Firebird: Firebird 2.5.2 a 64 bit, SuperServer, con buffer di pagina e TempCacheSize aumentati. Potete scaricare gratuitamente questo file di configurazione SuperServer da questa posizione: /it/optimized-firebird-configuration/

Come risultato, abbiamo ottenuto il seguente quadro delle prestazioni del database:

![Prestazioni Firebird 1813Gb (1.7Tb)](/images/performance/perf7_performance_with 1800Gb_Firebird_database.png)

Figura 1. Degrado delle prestazioni da 9Gb a 30Gb e 1,7Tb

Il punto #11 è il punteggio di prestazione per il database da 30Gb e #12 per il database da 1,7 Terabyte - la dimensione del database è cresciuta 60 volte (da 30Gb a 1813Gb), la perdita di prestazioni è stata di 2,4 volte (da 407 a 169 punti).

Quindi, la domanda è: possiamo migliorare le prestazioni di Firebird sullo stesso hardware con la regolazione della configurazione?

E la risposta è: sì!

Potenziare FirebirdSQL

Come ricorderete, in questo test abbiamo eseguito 20 connessioni simultanee che eseguono INSERT intensivi e, meno intensivi, UPDATE.

Tutte le SELECT sono brevi e ben definite, con piani di esecuzione SQL efficaci, quindi questa è una tipica applicazione OLTP (elaborazione transazionale online). Per tali applicazioni, la cosa più critica per le prestazioni è l’elaborazione parallela. Firebird SuperServer 2.5.2 non è adatto per l’elaborazione multi-thread - utilizza efficacemente solo 1 core per database, e questo fatto rende SuperServer non una scelta molto buona per applicazioni OLTP.

Quindi, dobbiamo cambiare l’architettura di Firebird in Classic o SuperClassic, che supportano l’elaborazione multi-thread e utilizzano più core della CPU (ci sono 8 core nella CPU AMD-FX8350).

Poi, è necessaria una certa regolazione, poiché la configurazione predefinita di Firebird non è ottimale per il nostro sistema di test.

Parametri di regolazione in firebird.conf

Cache di pagina

Quindi, per migliorare le prestazioni OLTP abbiamo deciso di provare le architetture Classic e SuperClassic. Uno dei parametri chiave per Classic e SuperClassic è il numero di buffer di pagina nella cache. A differenza di SuperServer, Classic e SuperClassic allocano la cache di pagina per connessione.

Per maggiori dettagli sulle architetture di Firebird nella 2.5 potete consultare questa tabella: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

C’è una formula semplice per calcolare l’uso di memoria della cache di pagina per le diverse architetture di Firebird:

1. SuperServer - cache di pagina singola per database. La dimensione predefinita della cache di pagina è 2048 pagine, la raccomandazione comune è 10000 buffer. Nel nostro caso la cache era 16k (dimensione pagina) x 10000 ~= 160Mb. È per tutte le connessioni.
1. Classic e SuperClassic - il motore alloca la cache di pagina per ogni connessione. La dimensione predefinita è 75 pagine, quindi 16Kb (dimensione pagina) x 75 = ~= 1,17 Mb, per ogni connessione.

Ovviamente, la dimensione della cache di pagina dovrebbe essere aumentata, poiché 75 pagine per connessione sono troppo poche. Mostreremo di seguito i risultati di diversi valori per la dimensione della cache di pagina.

LockHashSlots

Internamente il motore Firebird usa una tabella di lock per richiedere e acquisire lock sugli oggetti interni del database, e per Classic e SuperClassic esiste il parametro LockHashSlots (valore predefinito 1009). Dovrebbe essere aumentato sotto carico elevato, per diminuire le catene hash nella tabella di lock. Beh, “carico elevato” sembra essere qualsiasi applicazione multiutente reale, quindi lo abbiamo impostato a 30011 (per tutti i test).

LockMemSize

Il parametro LockMemSize è usato per impostare la dimensione iniziale della tabella di lock (valore predefinito 1048576). Il motore può aumentare la dimensione della tabella su richiesta. Tuttavia, l’aumento della tabella di lock è costoso in termini di CPU e altre risorse, poiché viene eseguito tramite rimappatura della memoria. Quindi lo abbiamo impostato a 7Mb, per risparmiare tempo e risorse CPU.

Esecuzioni dei test

Abbiamo eseguito diverse prove con vari valori della cache di pagina, con i seguenti risultati:

Buffer di pagina	Classic, punti test	SuperClassic, punti test
256	299	372
512	371	359
768	362	386
1024	312	387
1500	390	392
2048	285	284

Tabella 1. Esecuzioni dei test per Classic e SuperClassic

Come potete vedere, Classic e SuperClassic sono molto più efficaci di Firebird SuperServer per questo compito: i risultati dei test sono migliorati da 169 punti a 300-400, questo è vicino ai risultati che avevamo per il database da 30Gb!

È meglio vedere i risultati nel seguente grafico:

Prestazioni Firebird 1813Gb (1.7Tb)

Figura 2. Risultati dei test per database da 1,7 Terabyte

Potete vedere che le migliori prestazioni (sia in Classic che in SuperClassic) sono state con 1500 pagine per connessione, quindi la dimensione della cache di pagina per connessione era:

1500x16k ~= 23,4Mb

Con 2000 pagine per connessione le prestazioni sono diminuite significativamente. Sembra che da qualche parte tra 1500-2000 pagine il vantaggio della cache sia diventato inferiore all’overhead causato dalle interazioni della tabella di lock tra i processi per sincronizzare le pagine nelle cache di ogni processo server. Ovviamente, per un numero maggiore di connessioni questo accadrà prima, ed è per questo che i server Classic/SuperClassic sono solitamente configurati con numeri come 256-512 pagine.

C’è anche un calo delle prestazioni di Classic intorno a 768-1000 pagine di cache - non siamo sicuri del perché sia accaduto.

Riepilogo

I nostri esperimenti confermano che le prestazioni di Firebird possono essere aumentate con la corretta selezione dell’architettura di Firebird (SuperServer, Classic o SuperClassic) e con una regolazione appropriata di diversi parametri importanti per l’architettura specifica.

Come risultato, un enorme database Firebird SQL da 1,7 Tb può funzionare su hardware di fascia bassa con prestazioni abbastanza buone. Come output pratico di questi test, abbiamo creato diversi file di configurazione per tutte le versioni di Firebird per tutte le architetture. Naturalmente, non sono regolati per l’applicazione specifica e/o l’hardware, ma sono migliori dei file di configurazione predefiniti, che sono fatti per un carico molto modesto.

Set completo di file di configurazione ottimizzati per Firebird: /it/optimized-firebird-configuration/

Sentitevi liberi di fare qualsiasi domanda: [email protected]

Cosa succede dopo?

Stiamo lavorando a un test completo che confronterà le prestazioni di Firebird 2.5 e Firebird 3.0, con simulazione realistica del carico e un numero enorme di connessioni. Rimanete sintonizzati!