Database, Flash Storage: non sempre maggiori performance (it)

Este post también está disponible en Español

È difficile trovare un articolo dove si dica: “l’uso della tecnologia flash in ambienti di database relazionali potrebbe non avere alcun beneficio dal punto di vista delle prestazioni”. È comune concentrarsi sulle tecnologie All Flash (AFA) perché queste forniscono ambienti più efficienti: facilità d’uso, riduzione dei dati grazie a meccanismi di compressione e / o deduplicazione e minori costi di manutenzione. Tuttavia, quasi sempre, il principale “driver” nell’adozione di una tecnologia flash è ottenere significativi aumenti di performance.

In questo post vedremo come questo ultimo presupposto potrebbe non essere sempre vero. Utilizzando Oracle come esempio di database relazionale, discuteremo alcuni concetti relativi al “tuning” tramite AWR con l’obiettivo di ottenere la conoscenza di base che ci permetta di determinare quando un DB può, oppure non può, ottenere vantaggi in termini di prestazioni su una piattaforma AFA.

AWR 101 per uno specialista storage

Il report Oracle Automatic Workload Repository (AWR) fornisce una panoramica delle prestazioni del database in un determinato momento, creando “snapshot” o campioni di dati di prestazioni, ad intervalli di tempo che possono essere definiti (default 1 ora). AWR utilizza un “time modeling” per memorizzare queste statistiche.  Prima di iniziare vogliamo introdurre un paio di concetti utili per capire meglio alcuni ragionamenti presenti nel documento: “DB Time” & “wall-clock-time”.

Elapsed time: è il tempo trascorso; misurato come numero di minuti dallo snapshot iniziale a quello finale.

Elapsed time = DB time + Idle time: l’elapsed time include il DB Time o tempo trascorso nel quale il database sta eseguendo istruzioni SQL per una sessione + l’Idle Time che è il tempo di inattività o tempo in cui il database è attivo ma non ci sono applicazioni connesse oppure tutte le sessioni connesse sono inattive.

DB Time = DB CPU + Wait Time. Il DB Time comprende il DB CPU + il Wait time. Il DB CPU è il “wall-clock-time” che attesta che un processo di un’istanza Oracle si trovi nella CPU.

Il “wall-clock-time” fa riferimento al tempo effettivo necessario ad un host per completare un determinato compito. È la somma di tre termini, tempo di CPU, tempo di I/O più il ritardo di comunicazione sul canale (ad esempio, se i dati sono suddivisi tra più piattaforme). A differenza del tempo di CPU, che misura solo il tempo durante il quale il processore sta lavorando attivamente su un certo compito, il “wall-clock-time” misura il tempo totale per il completamento del processo.
La differenza tra i due consiste nel tempo trascorso a causa di ritardi programmati o in attesa di risorse che devono diventare disponibili, nel nostro caso, la componente storage.

db-and-flash-performance-awr101
db-and-flash-performance-awr101

Il wall-clock-time fa riferimento al tempo effettivo necessario per completare una determinata attività.  Il wait time è l’opposto di DB CPU. Qualsiasi evento che faccia in modo che un processo SQL attivo non sia nella CPU è un evento di attesa (wait). Oracle categorizza in modo molto chiaro gli eventi di wait in classi di eventi. In particolare, per l’analisi delle prestazioni e dei suoi impatti a livello del sistema storage, le classi di eventi che interessano sono: user I/O e commit. User I/O wait è il tempo in cui i processi di una sessione sono bloccati mentre aspettano che le operazioni di I/O vengano completate. Chiaramente, valori elevati in questa classe di wait impattano le prestazioni generali dell’applicazione. La tecnologia Flash è in grado di diminuire tali valori di attesa aumentando così le prestazioni. Al contrario, con valori di user I/O wait bassi o moderati, il solo utilizzo di dischi flash non fornirà apprezzabili vantaggi prestazionali.

Per uno specialista storage è utile iniziare l’analisi dell’AWR dalla sezione o tabella Top 5 Timed Foreground Events. In questa tabella, Oracle visualizza gli eventi in classi. La somma (espressa in %time) delle classi user I/O + commit rappresenta il tempo totale in cui i processi sono in attesa di una risposta dal sistema di archiviazione.

Ad esempio, nella tabella seguente possiamo vedere che sul tempo totale (% DB time), solo per circa il 33% di questo tempo i processi sono in DB CPU, cioè il DB sta sviluppando lavoro. In questo esempio, per il tempo rimanente, il DB è in attesa del sistema di archiviazione (classi User I/O e Commit). Un AWR di questo tipo è una chiara indicazione che questo ambiente otterrà benefici di performance adottando una tecnologia All Flash.

db-and-flash-performance-timed-foreground-events
db-and-flash-performance-timed-foreground-events
Non tutti i workload beneficiano di un sistema AFA.

Ricordate che tutto ciò che impedisce ad un processo SQL attivo di “rimanere” nella CPU è un evento di attesa. L’obiettivo è fare in modo che la differenza tra DB CPU e DB Time sia la minore possibile. Quando il DB Time = DB CPU, l’unico modo per aumentare le prestazioni consiste nell’utilizzare CPU più veloci.

Si potrebbe pensare che tramite il monitoraggio dell’uso delle CPU a livello server si avrebbe un’indicazione di “quanto bene” stia funzionando il DB, tuttavia questa analisi presa singolarmente può portare a conclusioni errate. Si consideri il seguente esempio: l’applicazione presenta tempi di risposta elevati e per questa ragione si è pensato ad un aggiornamento tecnologico di tipo AFA per migliorarne le prestazioni. L’obiettivo è quello di ottenere il minor tempo di risposta possibile.

Come procedura per definire l’aggiornamento tecnologico, utilizziamo il ragionamento “Il carico di lavoro definisce l’architettura”, in linea con la metodologia dei FlashSessment. vedere: Architetture di storage e carichi di lavoro

db-and-flash-performance-workload-characterization
db-and-flash-performance-workload-characterization

Attraverso il FlashSessment sappiamo che l’applicazione in oggetto è un’applicazione Oracle e tramite gli AWR notiamo che si tratta di un carico di lavoro che trascorre molto del suo tempo nella CPU.

db-and-flash-performance-load-profile
db-and-flash-performance-load-profile

La differenza tra DB Time / DB CPU è molto, molto piccola. Ciò significa che l’applicazione viene già eseguita il più rapidamente possibile per quanto è concesso alle CPU dell’host.

Con il monitoraggio delle CPU dell’host si spera di scoprire che questa applicazione sia di tipo CPU bound, (utilizza tutte le risorse disponibili dell’host (CPU) e non è in grado di ulteriori incrementi nelle performance). Tuttavia, in questo caso, le CPU del server non sono al 100% di utilizzo. Cosa vuol dire? A questo punto è utile introdurre due nuovi concetti che per comprendere una situazione di questo tipo.

Host CPU bound vs DB saturated workload

Normalmente negli attuali sistemi multi-CPU e multi-core è pratica comune assegnare un certo numero di core ad una applicazione.  In questo modo parte della capacità di elaborazione del server è dedicata al DB e parte ad altri processi non correlati al DB. In questi casi, quando osserviamo il livello di utilizzo delle CPU del server, è probabile che il sistema non sia in una situazione di Host CPU bound (100% di utilizzo) e quindi, questo ci porta a pensare che il problema di non ottenere buone prestazioni sia dovuto ad “altre cause”. Queste altre cause vengono quasi sempre attribuite al sistema di “storage”

db-and-flash-performance-db-cpu-concepts
db-and-flash-performance-db-cpu-concepts

Un esempio ci permetterà di capire il concetto di DB saturated workload. Nella figura seguente, sempre proveniente da AWR, possiamo notare il numero di core dedicato all’applicazione.

db-and-flash-performance-host-environment
db-and-flash-performance-host-environment

Questa applicazione utilizza 6 socket, con un numero di 39 core per un totale di 312 CPU thread su un server Solaris M6. Questi server hanno 12 core con 8 thread / 6 socket e ciò risulta in un totale di 576 thread. Di questi thread, 312 sono dedicati al DB mentre i 264 thread restanti vengono utilizzati per eseguire altre operazioni. Se questi 264 thread vengono usati per fare un lavoro intensivo è molto probabile che anche i 312 thread (quelli dedicati al DB) siano anche loro sovraccaricati il che rende le CPU meno efficaci per eseguire il carico di lavoro dell’applicazione.

Per questa applicazione, non ci sono eventi di tipo I/O (User I/O, ultima colonna), che possano indicare problemi lato “dischi”.

db-and-flash-performance-10-foreground-events
db-and-flash-performance-10-foreground-events

Come conclusione di questo esempio possiamo dire che l’applicazione non è CPU saturated (il server dispone di risorse), ma il carico di lavoro è DB workload saturated  (le risorse disponibili per il DB sono sature), un’importante distinzione che a volte passa inosservata.

Senza modifiche aggiuntive che aiutino il parallelismo (DOP PQO) oppure tramite un tuning al codice SQL per utilizzare meno CPU, o senza dedicare più thread, il sistema (applicativo) ha attualmente le migliori prestazioni possibili consentite dall’ambiente.

db-and-flash-performance-flash-assessments
db-and-flash-performance-flash-assessments

In questo ultimo esempio, senza uno studio preliminare sul comportamento effettivo dell’applicazione, un aggiornamento tecnologico avrebbe portato all’acquisto di un sistema AFA, probabilmente con caratteristiche di capacità (spazio) simili all’attuale sistema di storage, ma, date le peculiarità del carico di lavoro in studio, avrebbe prodotto guadagni di performance trascurabili.

Per concludere

Un data center moderno sfrutta la tecnologia flash nella maggior parte delle architetture possibili. La tecnologia Flash viene normalmente associata ad un incremento delle performance a livello applicativo e quindi all’incremento di lavoro che è possibile svolgere in una determinata unità di tempo.

L’aumento delle prestazioni è sicuramente l’aspetto più evidente della tecnologia flash e per questo motivo si tende a pensare che la sua adozione comporti sempre un aumento “automatico” in termini di performance. Tuttavia, se si considera solo questo aspetto, è importante notare che NON tutti i carichi di lavoro possono trarre beneficio da una soluzione AFA.

Caratterizzare l’architettura flash che meglio si adatta all’ambiente e i benefici di performance che questa può portare, soprattutto in ambienti complessi, non è un compito facile. Per questo motivo, Dell EMC ha progettato un processo, un “assessment”, vedere: Assessment dell’infrastruttura IT che, in forma semplice, ci permette di identificare l’architettura storage che meglio si adatta alle esigenze di business in esame fornendo allo stesso tempo informazioni sui vantaggi che la soluzione proposta avrà rispetto a quella corrente.

db-and-flash-performance-big-picture
db-and-flash-performance-big-picture

 


Per maggiori informazioni:

Sistemi di Storage Dell EMC All-Flash

#IWork4Dell

Este post también está disponible en: Español (Spagnolo)