Alexey Kovyazin, 16 maggio 2014

Puoi scaricare questo articolo in formato PDF.

Recentemente in IBSurgeon abbiamo eseguito una serie di test sulle prestazioni con Firebird 2.5.2. Firebird 2.5.2 è la versione più popolare del database Firebird, e i suoi utenti hanno spesso domande relative alle prestazioni di Firebird.

Una delle preoccupazioni più importanti riguardanti le prestazioni del database è il suo degrado. Molti utenti affermano che le loro applicazioni database hanno problemi di prestazioni quando raggiungono un certo valore di soglia: può essere 3Gb, 5Gb, la dimensione della RAM, 20Gb, ecc. L’affermazione più comune è “la dimensione del database è maggiore della dimensione della RAM”: quando la dimensione del database Firebird raggiunge la dimensione della RAM, si dice che diventi molto lento… È vero?

Abbiamo deciso di eseguire una serie di test per verificare se esiste tale degrado delle prestazioni legato alla crescita del database. Abbiamo deciso di simulare la crescita nel tempo del database con lo stesso carico sullo stesso hardware, e per questo abbiamo eseguito 11 test con database di dimensioni comprese tra 9Gb e 30Gb:

Figura 1. Dimensioni dei database per i test

Hardware di test e configurazione Firebird

L’hardware di test aveva le seguenti caratteristiche principali:

CPU AMD-FX8350, RAM 16GB, RAID1 software SATA 2x4Tb dischi Seagate, Sistema Operativo Windows Server 2008R2 (2008R2 è a 64 bit).

Come puoi vedere, è una configurazione hardware di fascia bassa; può essere acquistata per meno di 1000 USD al momento (maggio 2014), e può essere considerata una tipica configurazione di livello basso - forse, eccetto i grandi dischi SATA, ma secondo il rapporto del produttore, la velocità dei dischi SATA da 1Tb e 4Tb è quasi la stessa.

Poiché l’obiettivo del test era misurare i cambiamenti di prestazioni di un sistema tipico, abbiamo usato Firebird (64 bit) con architettura SuperServer, non Classic, per simulare completamente la situazione di una piccola azienda - usano ciò che è stato installato originariamente per anni. Come sai, SuperServer usa solo 1 core della CPU, quindi probabilmente Classic o SuperClassic (che possono usare tutti i core della CPU) potrebbero mostrare risultati migliori in termini di prestazioni, ma il nostro obiettivo non era il tuning delle prestazioni.

Tuttavia, abbiamo configurato firebird.conf con le modifiche ovvie che raccomandiamo per tutte le installazioni Firebird SuperServer: aumento dei page buffers a 10000 e spazio temporaneo per l’ordinamento.

Tutti i database di test sono stati creati con page size 16384, solo per coerenza.

Test

Caricamento

Ogni test conteneva 2 fasi: caricamento e simulazione di 20 terminali che eseguono insert, update e delete.

La fase di caricamento è eseguita da un’applicazione loader (load.exe), che inserisce dati in diverse tabelle. Come puoi vedere nella figura 2, i dati vengono caricati con velocità diverse; varia da ~35Mb/sec a 1mb/sec.

Figura 2. Velocità di caricamento del database (grafico rosso)

Questo è legato al design dell’applicazione loader, non a Firebird: il loader inserisce rapidamente il 70% del database e poi riempie lentamente il resto dei dati, e questo si ripete con database di tutte le dimensioni. È importante per noi che il loader esegua le stesse operazioni, così possiamo usare la sua velocità media per misurare la velocità di caricamento.

È importante dire che il loader inserisce solo dati, e gli indici vengono creati dopo che il caricamento è completo.

Diamo un’occhiata alla tabella con i risultati della fase di caricamento per 11 database tra 9 e 30Gb:

#	dimensione database, gb	tempo di caricamento, sec	velocità di caricamento SATA, 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

Figura 3 Tempo e velocità di caricamento

Oppure, è meglio mostrarlo nel grafico della figura 4:

Figura 4. Risultati dei test: velocità di caricamento.

Come puoi vedere, c’è un grafico abbastanza stabile, e la velocità media del processo di caricamento varia intorno a 3.3-3.4Mb/sec. Non ci sono inoltre segni di diminuzione della velocità di caricamento quando la dimensione del database supera la dimensione della RAM (dopo il database #5, con dimensione 17.3Gb).

Prestazioni

Quindi, i tempi di caricamento sembrano abbastanza promettenti, e i risultati effettivi delle prestazioni?

Prima di passare ai risultati delle prestazioni, rivediamo rapidamente il processo di simulazione.

La simulazione esegue 20 thread, e ciascuno di essi esegue casualmente diverse operazioni di business: creare un nuovo ordine, elaborare un pagamento, contare i prodotti in magazzino, elaborare la consegna di un ordine, ecc. (per i dettagli puoi guardare i testi SQL delle procedure memorizzate effettive). Come puoi vedere, questo è il normale insieme di operazioni di business di un’applicazione astratta di inventario/vendite.

L’applicazione di test misura il numero di operazioni di business al secondo e riporta un numero medio. Naturalmente, questo numero è un parametro artificiale, ma è abbastanza buono per il confronto.

Risultati dei test di prestazioni:

#	dimensione database, gb	prestazioni su 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

Figura 5. Tabella con i risultati dei test di prestazioni.

Oppure, è meglio vedere i risultati nella rappresentazione grafica:

Figura 6. Grafico dei risultati delle prestazioni

Come puoi vedere, c’è un lento degrado delle prestazioni con la crescita della dimensione del database - più grande è il database, più lento funzionerà (sullo stesso hardware). Non c’è inoltre un grande calo delle prestazioni quando la dimensione del database supera la RAM. La crescita del database da 9Gb a 30Gb porta a circa il 20% di perdita di prestazioni.

I database Firebird da 30Gb sono ormai comuni, e crescono e crescono nel tempo. Tuttavia, cosa succederà con le prestazioni del database quando sarà ancora più grande? Intendiamo - PIÙ GRANDE! Cosa succederà con le prestazioni quando il database diventerà DAVVERO GRANDE?

Mr.Big

Per rispondere a questa domanda abbiamo deciso di guardare alla fine della tabella dei test e eseguire un test con un database da 1.7Tb (1813 Gb), sullo stesso hardware, con le stesse impostazioni.

Caricamento

Quindi, abbiamo creato tale database:

Figura 7. Dimensione del database - ora con database da 1813 Gb

Il caricamento ha richiesto 566448 secondi - 157 ore, 6.55 giorni. È molto tempo, ma la velocità media di caricamento era… 3.28Mb/sec!

#	dimensione database, gb	tempo di caricamento, sec	velocità di caricamento SATA, Mb/sec
12	1813,969025	566448	3,279214122

Figura 8. Tempo e velocità di caricamento per database Firebird da 1.7Tb

Nel grafico sembra molto buono: l’ultimo punto (#12). Quindi, Firebird mostra ottimi risultati dei suoi algoritmi di inserimento.

Figura 9 Velocità di caricamento - il punto #12 è per il database Firebird da 1.7Tb

Prestazioni di Mr.Big

Poi abbiamo eseguito lo stesso test di prestazioni - la riga 12 è per il database da 1.7Tb.

#	dimensione database, gb	prestazioni su 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

Figura 10. Risultati dei test di prestazioni - la riga 12 è per il database da 1.7Tb

E nel grafico:


Figura 11. Prestazioni, il punto #12 è per il database da 1.7Tb

Il risultato conferma che c’è un lento e stabile degrado delle prestazioni in Firebird - mentre 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).

Non è una situazione frequente che un database (sullo stesso hardware di fascia bassa) cresca da 30Gb a 1.7Tb, ma Firebird funzionerà anche in questa situazione.

Grande database in dettaglio

Per comprendere meglio il database da 1.7Tb, abbiamo raccolto le statistiche del database per il database Mr.Big e le abbiamo analizzate in IBAnalyst:

Figura 12 Tabelle del database da 1.7Tb in IBAnalyst

Come puoi vedere, ci sono 2 grandi tabelle - ORDER_LINE (~600 Gb) con 6.3 miliardi di record e STOCK (~680 Gb) con 2.1 miliardi di record.

E, per queste tabelle ci sono 2 indici con profondità = 4 - significa che ogni richiesta fa 4 letture delle pagine degli indici prima della lettura effettiva dei dati. L’indice ORDER_LINE_PK ha una dimensione di 50Gb.

Figura 13. Indici del database Firebird da 1.7Tb

Nonostante l’enorme numero di record, le statistiche del database sembrano buone, quindi non sorprende che Firebird mostri risultati abbastanza buoni anche per un grande database su hardware di fascia bassa.

Test di Firebird con disco SSD

Dopo aver completato la serie di test Firebird su hardware di fascia bassa, abbiamo deciso di verificare quali sarebbero stati i risultati sull’altro estremo della tecnologia di archiviazione dati e abbiamo installato un disco SSD sullo stesso server.

Abbiamo installato un disco SSD Plextor PX-256M M5 Pro e eseguito la stessa serie di test (eccetto il database da 1.7Tb), con le stesse impostazioni. I risultati sono stati aggiunti ai grafici con i dispositivi SATA, vedili sotto.

Caricamento

Come puoi vedere, il tempo di caricamento su SSD è lo stesso che su SATA. Questo è un risultato atteso: la velocità delle operazioni di scrittura sequenziale è quasi la stessa su dischi SATA e SSD.

Figura 14. Caricamento su SSD e SATA

Prestazioni

Vedi i risultati delle prestazioni:

Figura 15. Prestazioni su SSD e SATA

Come puoi vedere, le prestazioni con operazioni IO casuali mostrano risultati ~8x migliori per il disco SSD. Sapevamo dalla nostra esperienza con i database dei clienti che l’SSD è più veloce del 30-50% con applicazioni reali, ma un aumento di 8x è molto alto.

Tuttavia, questo test è artificiale e appositamente progettato per simulare operazioni OLTP ad alto carico, con molti update/delete, ma senza grandi fetch. Una normale applicazione database non funziona in questa modalità tutto il tempo. Questo spiega perché l’SSD mostra risultati così alti in questo caso particolare.

Riepilogo

Quindi, cosa abbiamo imparato da questi test?

Prima di tutto - le prestazioni di Firebird non hanno grandi diminuzioni legate a qualche restrizione di dimensione. Sullo stesso hardware le prestazioni diminuiranno lentamente con la crescita della dimensione del database. Tale diminuzione delle prestazioni può essere compensata con la configurazione di Firebird o con un aggiornamento intelligente dell’hardware.

È un buon momento per menzionare che IBSurgeon offre servizio di ottimizzazione delle prestazioni Firebird - usando i dati sperimentali raccolti da test come questo possiamo aumentare significativamente le prestazioni dei database Firebird e InterBase.

Inoltre, sappiamo che anche database Firebird molto grandi (1.7 terabyte) funzioneranno su hardware di fascia bassa con una perdita di prestazioni significativa ma accettabile.

E terzo, l’SSD è davvero buono per le applicazioni OLTP. Probabilmente è il modo più economico per migliorare le prestazioni del database al momento. Naturalmente, l’uso dell’SSD non risolverà i problemi con piani di query scadenti e indici inefficienti, ma può aumentare le prestazioni in generale.

Continua: Maggiori dettagli sul database Firebird da 1,7 Terabyte.