Il benchmark dell'applicazione Sysbench OLTP viene eseguito su un database MySQL che esegue il motore di archiviazione InnoDB. Il compito del motore di archiviazione è gestire l'interfaccia dal database su disco alle applicazioni che leggono e scrivono dati da e verso il motore di archiviazione. Il motore di archiviazione a sua volta gestisce thread e log di I/O e mantiene una cache in memoria per ridurre al minimo l'accesso al disco. La tabella seguente offre una panoramica semplicistica del motore.
Poiché il motore InnoDB mantiene una cache in memoria denominata pool di buffer, le prestazioni saranno direttamente influenzate dal rapporto tra la dimensione del working set e la dimensione del pool di buffer. In altre parole, se il pool di buffer è sufficientemente grande da contenere il working set o il working set è sufficientemente piccolo da rientrare nel pool di buffer, la maggior parte delle operazioni non sarà mai associata a I/O. Tuttavia, se il database è troppo grande per essere contenuto in memoria, le prestazioni di I/O determineranno i tempi di risposta e la velocità effettiva delle transazioni. Stiamo caratterizzando le prestazioni dell'unità in questa situazione in cui il database non può contenere memoria, il che comporta un aumento del traffico IO dal motore di archiviazione InnoDB.
Più thread (il numero dipende dalla configurazione del database per applicazioni ad alte prestazioni e varia da 32 a 128) leggono i dati in modo casuale dall'archivio di backup con una dimensione di blocco di 16 Kbyte. Queste letture sono correlate alle query del database che richiedono dati dall'archivio di backup. Man mano che le letture vengono elaborate, vengono automaticamente memorizzate nella cache nel pool di buffer. Man mano che il pool di buffer si riempie, InnoDB utilizza una policy LRU (Least Recently Used) per eliminare le pagine più vecchie per fare spazio ai dati più recenti.
Le scritture del database vengono prima dirette al log delle transazioni e al pool di buffer. Il log delle transazioni è un buffer ad anello scritto in sequenza che viene aggiornato per ogni transazione di scrittura. A seconda della configurazione di MySQL, questo aggiornamento può portare a un'immediata scrittura su disco oppure può persistere temporaneamente nella RAM come buffer che viene infine scaricato su disco dal file system. La dimensione di questo buffer di registro varia, ma in genere è di circa 256 MB. Le impostazioni consigliate per la conformità ACID richiedono che le scritture del log colpiscano il disco a ogni commit del database. Queste scritture hanno una lunghezza di 4K.
Il log esegue solo scritture “fisiologiche” in cui viene scritto il delta tra i dati precedenti e i nuovi dati. Per i dati originali, InnoDB scrive nel pool di buffer nella RAM, che deve essere anch'esso svuotato in modo asincrono. Il processo di riscrittura dei dati nel file system è configurabile e avviene in background. Anche le scritture sono 16K. Le scritture sono in realtà doppie scritture in cui il motore scrive prima i dati in una posizione intermedia chiamata buffer di doppia scrittura. Il motore quindi copia i dati nella posizione finale nel file system. Ciò è necessario per evitare il problema della “pagina strappata” in cui una pagina di database da 16 KB viene parzialmente scritta su disco a causa di un'interruzione di corrente o di un altro evento catastrofico.
Origini del benchmark Sysbench
Abbiamo introdotto la configurazione di test Sysbench nel nostro laboratorio dopo diverse conversazioni con Micron su come simulano ambienti applicativi MySQL reali per il test e la misurazione degli SSD. Hanno sviluppato una metodologia di test basata su Sysbench dopo aver constatato che i benchmark sintetici per lo storage raramente fornivano una visione completa del comportamento di un'unità sottoposta a un particolare carico di lavoro applicativo. Il test Sysbench consente a Micron di simulare un ambiente che rappresenta nel modo più fedele possibile un carico di lavoro standard per database MySQL, diffuso in applicazioni come Facebook, Craigslist e Booking.com.
Abbiamo lavorato a stretto contatto con Moussa Ba, che ha collaborato alla stesura di questo articolo. Moussa è un ingegnere software del team di sviluppo PCIe di Micron, dove il suo lavoro include l'ottimizzazione di applicazioni e software di sistema per dispositivi IO ad alte prestazioni.
Benchmark OLTP di Sysbench
Sysbench è un benchmark delle prestazioni del sistema che include un profilo di test OLTP (OnLine Transaction Processing). Il test OLTP non è un'approssimazione di un test OLTP, ma è piuttosto un vero benchmark basato su database che conduce query transazionali a un'istanza di MySQL in un ambiente CentOS.
Il primo passo nell'impostazione del benchmark è creare il database stesso, operazione eseguita specificando il numero di tabelle nel database e il numero di righe per tabella. Nel nostro test abbiamo definito 100 tabelle con 10 milioni di righe ciascuna, il che ha dato come risultato un database di 1 miliardo di voci. Questo database era di 260 GB.
Sysbench ha due modalità operative: modalità predefinita che legge e scrive nel database e modalità di sola lettura. La modalità R/W predefinita eseguirà i seguenti tipi di query: 5 query SELECT, 2 query UPDATE, 1 query DELETE e 1 INSERT. Osservando i conteggi IO, il rapporto di lettura/scrittura osservato è di circa il 75% di letture e il 25% di scritture.
Ambiente di test Sysbench
Le soluzioni di storage vengono testate con il benchmark Sysbench OLTP nel laboratorio di test aziendale di StorageReview, utilizzando server standalone. Attualmente utilizziamo server PowerEdge R730 standard di Dell per dimostrare prestazioni realistiche e un solido rapporto prezzo/prestazioni, sostituendo solo l'adattatore di storage o l'interfaccia di rete per connettere il nostro R730 a diversi prodotti di storage. Il PowerEdge R730 ha dimostrato di offrire un'ottima compatibilità con dispositivi di terze parti, il che lo rende una piattaforma ideale per questo ambiente di test eterogeneo. L'R730 sfrutta inoltre la potente architettura Intel di classe Haswell, che ci fornisce la potenza di calcolo necessaria per stressare adeguatamente un'ampia gamma di soluzioni di storage e massimizzarne il potenziale prestazionale.
Ambiente benchmark Sysbench di prima generazione
Lenovo ThinkServer RD630 – Piattaforma di test SATA/SAS/PCIe
- 2594-ABU Modello più venduto
- Doppie CPU Intel E5-2650 (2.0 GHz, 8 core, cache da 20 MB)
- 128 GB di RAM (8 GB x 16 DDR3, 64 GB per CPU)
- 100 GB micron SSD RealSSD P400e (tramite LSI 9207-8i) Unità di avvio
- Archiviazione database precostruita Micron M960 da 500 GB (tramite 9207-8i).
- CentOS 6.3 a 64 bit
- Percona XtraDB 5.5.30-rel30.1
- Tabelle del database: 100
- Dimensione del database: 10,000,000
- Discussioni del database: 32
- Memoria RAM: 24 GB
Ambiente benchmark Sysbench di seconda generazione
Dell PowerEdge R730 – Piattaforma di test SATA/SAS/PCIe
- Doppie CPU Intel E5-2690 v3 (2.6 GHz, 12 core, 30 MB di cache)
- 256 GB di RAM (16 GB x 16 DDR4, 128 GB per CPU)
- SSD di avvio da 100 GB, SSD di archiviazione database da 480 GB
- 2 adattatori Mellanox ConnectX-3 InfiniBand
- 2 x HBA FC a doppia porta Emulex da 16 GB
- 2 x Scheda di rete Emulex 10GbE a doppia porta
- CentOS 6.6 64 bit
- Percona XtraDB 5.5.30-rel30.1
- Tabelle del database: 100
- Dimensione del database: 10,000,000
- Discussioni del database: 32
- Memoria RAM: 24 GB
Cluster Sysbench virtualizzato a 730 nodi Dell PowerEdge R4
- Otto CPU Intel E5-2690 v3 per 249 GHz in cluster (due per nodo, 2.6 GHz, 12 core, 30 MB di cache)
- 1 TB di RAM (256 GB per nodo, 16 GB x 16 DDR4, 128 GB per CPU)
- Avvio scheda SD (Lexar 16 GB)
- 4 adattatori Mellanox ConnectX-3 InfiniBand (vSwitch per vMotion e rete VM)
- 4 x HBA FC a doppia porta Emulex da 16 GB
- 4 x Scheda di rete Emulex 10GbE a doppia porta
- VMware ESXi vSphere 6.0 /Enterprise Plus 8 CPU
L'obiettivo principale di questa piattaforma è evidenziare le prestazioni dello storage aziendale in un ambiente e in un carico di lavoro aziendali reali, invece di fare affidamento su carichi di lavoro sintetici o pseudo-sintetici. I generatori di carichi di lavoro sintetici sono ottimi nel mostrare le prestazioni dei dispositivi di storage con un modello I/O sintetico continuo, ma non prendono in considerazione nessuna delle altre variabili esterne che illuminano il modo in cui funzionano effettivamente i dispositivi negli ambienti di produzione. I generatori di carichi di lavoro sintetici hanno il vantaggio di mostrare ripetutamente un modello I/O pulito, ma non replicheranno mai un vero ambiente di produzione. L'introduzione delle prestazioni delle applicazioni sui prodotti di storage inizia a mostrare quanto bene lo storage interagisce con i suoi driver, il sistema operativo locale, l'applicazione testata, lo stack di rete, la commutazione di rete e i server esterni. Queste sono variabili che un generatore sintetico di carico di lavoro semplicemente non può prendere in considerazione, e sono anche un ordine di grandezza che richiede più risorse e infrastrutture in termini di attrezzature necessarie per eseguire questo particolare benchmark.
Risultati complessivi delle prestazioni di Sysbench
Testiamo un'ampia gamma di soluzioni di storage con il benchmark Sysbench OLTP che soddisfano i requisiti minimi dell'ambiente di test. Per qualificarsi per il test, il dispositivo di storage deve avere una capacità utilizzabile superiore a 260 GB ed essere progettato per funzionare in condizioni aziendali stressanti. I dispositivi di archiviazione collegati localmente come SAS, SATA e SSD PCIe vengono testati su un server bare metal con un'istanza Sysbench. Le piattaforme SAN e iperconvergenti più recenti eseguono 4, 8, 12 o 16 VM contemporaneamente per mostrare quanto bene operano più carichi di lavoro contemporaneamente su ciascuna. Questa metodologia di test aiuta a demistificare i confronti delle prestazioni tra i nuovi sistemi iperconvergenti e gli array di archiviazione SAN tradizionali.
Risultati delle prestazioni Sysbench iperconvergenti/SAN virtualizzati (aggregato di 16 VM)
| Dispositivo | TPS aggregato a 32 thread | Tempo medio di risposta (ms) | Latenza del 99° percentile (ms) |
|---|---|---|---|
| X-IO ISE 860 (4) Dell R730, X-IO ISE 860 AFA (2) Volumi da 10 TB |
6625 | 80 | 418 |
Risultati delle prestazioni Sysbench iperconvergenti/SAN virtualizzati (aggregato di 12 VM)
| Dispositivo | TPS aggregato a 32 thread | Tempo medio di risposta (ms) | Latenza del 99° percentile (ms) |
|---|---|---|---|
| X-IO ISE 860 (4) Dell R730, X-IO ISE 860 AFA (2) Volumi da 10 TB |
7160 | 54 | 177 |
Risultati delle prestazioni Sysbench iperconvergenti/SAN virtualizzati (aggregato di 8 VM)
| Dispositivo | TPS aggregato a 32 thread | Tempo medio di risposta (ms) | Latenza del 99° percentile (ms) |
|---|---|---|---|
| X-IO ISE 860 (4) Dell R730, X-IO ISE 860 AFA (2) Volumi da 10 TB |
6568 | 39 | 83 |
| VMware VSAN (ESXi 6.0) (4) Dell R730xd, 80 HDD da 1.2 TB, 16 SSD da 800 GB |
4259 | 60 | 131 |
Risultati delle prestazioni Sysbench iperconvergenti/SAN virtualizzati (aggregato 4 VM)
| Dispositivo | TPS aggregato a 32 thread | Tempo medio di risposta (ms) | Latenza del 99° percentile (ms) | Latenza di picco (ms) |
|---|---|---|---|---|
| DotHill Ultra48 ibrido (4) Dell R730, DotHill Ultra48 ibrido (2) pool RAID14 da 1 dischi, 40 HDD da 1.8 TB, 8 SSD da 400 GB |
4645 | 28 | 51 | 676 |
| X-IO ISE 860 (4) Dell R730, X-IO ISE 860 AFA (2) Volumi da 10 TB |
4424 | 29 | 57 | 983 |
| VMware VSAN (ESXi 6.0) (4) Dell R730xd, 80 HDD da 1.2 TB, 16 SSD da 800 GB |
2830 | 45 | 94 | 480 |
| Nutanix NX-8150 (ESXi 6.0) (4) NX-8150, 80 HDD da 1 TB, 16 SSD da 800 GB Volume del database del disco virtuale RAID0 x 4 |
2390 | 54 | 173 | 4784 |
| Nutanix NX-8150 (ESXi 6.0) (4) NX-8150, 80 HDD da 1 TB, 16 SSD da 800 GB Distribuzione del database predefinita |
1422 | 90 | 216 | 5508 |
Acceleratore di applicazioni PCIe/Risultati delle prestazioni del Sysbench RAID multi-SSD/HDD
| Dispositivo | TPS medio a 32 thread | Tempo medio di risposta | Latenza del 99° percentile |
|---|---|---|---|
| Huawei ES3000 da 2.4 TB SSD PCIe MLCx1 |
2734.69 | 11.7 | 19.84 |
| Huawei ES3000 da 1.2 TB SSD PCIe MLCx1 |
2615.12 | 12.23 | 21.80 |
| Fusion ioDrive2 Duo da 2.4 TB SSD PCIe MLCx1 |
2521.06 | 12.69 | 23.92 |
| Micron P320h 700 GB SSD PCIe SLCx1 |
2443.56 | 13.09 | 22.45 |
| Micron P420m 1.4 TB SSD PCIe MLCx1 |
2361.29 | 13.55 | 25.84 |
| FusionioDrive2 1.2TB SSD PCIe MLCx1 |
2354.06 | 13.59 | 29.35 |
| Virident FlashMAX II 2.2 TB SSD PCIe MLCx1 |
2278.11 | 14.04 | 26.04 |
| LSI Nytro Warp Drive da 800 GB SSD PCIe MLCx1 |
1977.67 | 16.18 | 39.94 |
| LSI Nytro Warp Drive da 400 GB SSD PCIe MLCx1 |
1903.14 | 16.81 | 39.30 |
Risultati SSD SAS/SATA individuali
| Dispositivo | TPS medio a 32 thread | Tempo medio di risposta | Latenza del 99° percentile |
|---|---|---|---|
| Toshiba HK3R2 960 GB MLC SATAx1 |
1673.23 | 19.12 | 49.65 |
| SanDisk CloudSpeed Eco 960 GB cMLC SATA x 1 |
1556.99 | 20.55 | 49.05 |
| Intel S3700 800 GB eMLC SATAx1 |
1488.71 | 21.49 | 40 |
| Toshiba PX02SM 400 GB eMLC SAS (6Gb/s) x 1 |
1487.03 | 21.52 | 62.02 |
| SmartOptimus 400 GB eMLC SASx1 |
1477.1 | 21.66 | 52.69 |
| OCZ Talos 2C 480 GB MLC SASx1 |
1438.7 | 22.24 | 47.32 |
| OCZ Intrepid 3600 400 GB eMLC SASx1 |
1335.3 | 23.96 | 48.42 |
| OCZ Talos 2R 400GB eMLC SASx1 |
1421.15 | 22.51 | 45.06 |
| SanDisk Extreme 480GB MLC SATAx1 |
1303.48 | 24.55 | 53.56 |
| STEC s842 800 GB eMLC SASx1 |
1293.56 | 24.74 | 67.20 |
| Intel S3500 512 GB eMLC SATAx1 |
1,287.65 | 24.85 | 64.15 |
| Intel S3500 480 GB eMLC SATAx1 |
1241.59 | 25.77 | 54.27 |
| Seagate 600Pro 400GB eMLC SATAx1 |
1198.2 | 26.7 | 62.69 |
| Hitachi SSD400S.B 400 GB SLC SASx1 |
1191.47 | 26.85 | 47.87 |
| OCZ vettoriale 512 GB MLC SATAx1 |
1130.03 | 28.32 | 62.67 |
| SanDisk Extreme II da 480 GB MLC SATAx1 |
981.34 | 32.61 | 102.58 |
| Hitachi SSD400M eMLC SASx1 |
878.9 | 36.41 | 68.03 |
| eSSD Toshiba SLC SASx1 |
758.41 | 42.19 | 140.59 |
| Micron M500 480 GB MLC SATAx1 |
668.6 | 47.86 | 461.80 |




Amazon