IT202100007631A1 - Metodo e sistema per mettere a punto un ambiente informatico utilizzando una base di conoscenza - Google Patents

Description

METODO E SISTEMA PER METTERE A PUNTO UN AMBIENTE INFORMATICO UTI-LIZZANDO UNA BASE DI CONOSCENZA

DESCRIZIONE

Campo dell?invenzione

La presente invenzione riguarda un metodo e un sistema per mettere a punto (tuning) parametri regolabili in un ambiente informatico. In particolare, un metodo e un sistema che ? in grado di mettere a punto in modo automatico parametri regolabili che influenzano le prestazioni di un sistema informatico IT in base a una base di conoscenza (knowledge base) di sistemi IT simili.

Tecnica antecedente

Un moderno sistema IT ? composto da diversi livelli, che spaziano da macchine virtuali, middleware (software di intermediazione tra applicazioni), database, sistemi operativi fino alla macchina fisica stessa. Ciascun livello offre un?ampia variet? di parametri configurabili che ne controllano il comportamento. Selezionare la corretta configurazione si dimostra fondamentale per ridurre i costi e aumentare le prestazioni. Trovare manualmente la configurazione ottimale, tuttavia, pu? dimostrarsi un compito arduo, poich? i parametri spesso si comportano in modi controintuitivi e presentano interdipendenze reciproche. Di conseguenza, molti sistemi IT di produzione, una volta distribuiti, vengono eseguiti con impostazioni predefinite, tralasciando miglioramenti significativi in termini di prestazioni o costi.

Il problema di configurazione pu? essere considerato un problema di ottimizzazione, dove si richiede di trovare una configurazione che ottimizzi un determinato indicatore di prestazione.

In questa descrizione, con il termine ?ottimizzazione? si intende il processo che regola un valore di un determinato parametro che consente di ottenere le migliori prestazioni possibili di una grandezza (ad esempio throughput (capacit? di trasferimento) dati, velocit? di accesso ad un?area di memoria, spazio di archiviazione, e cos? via) misurata tramite una metrica appropriata. Non ? possibile affermare a priori se il valore massimo o il valore minimo o un altro valore consentano di raggiungere la prestazione desiderata, perch? questa dipende dalla natura del parametro e dalla grandezza misurata: per questo il processo ? generalmente detto ?ottimizzazione? invece di resa al massimo, resa al minimo e cos? via.

Facendo riferimento a sistemi IT complessi, il problema di ottimizzazione ? piuttosto peculiare, rendendo poco pratico l?utilizzo di soluzioni standardizzate.

In effetti, il primo problema risiede nel numero reale di parametri, il che rende il compito di ottimizzazione estremamente arduo.

Ad esempio, un tipico allestimento di sistema IT potrebbe consistere nel database Cassandra<TM>, in esecuzione su una Macchina Virtuale Java<TM >e il sistema operativo Linux su un?istanza di tipo cloud. Apache Cassandra<TM >4.0 presenta 187 parametri regolabili, OpenJDK 11 presenta 668 parametri regolabili e Linux 5.9.4 presenta pi? di 1143 parametri regolabili.

? noto che le prestazioni di un sistema IT cos? complesso dipendono dai parametri applicati, ma il numero di parametri, la complessit? del modello e lo scenario IT in continua evoluzione rendono impraticabile di creare un modello analitico che descriva le prestazioni in funzione dei parametri applicati. Pertanto, il solito approccio alla messa a punto automatica (autotuning) delle prestazioni consiste nell?applicare al sistema una configurazione effettiva ed eseguire un test delle prestazioni per misurare le prestazioni associate tramite una metrica adeguata.

Le informazioni vengono quindi utilizzate per decidere un?altra configurazione da valutare, procedendo in modo iterativo fino a quando non viene trovata una configurazione sufficientemente buona (ossia, che porta a buone prestazioni).

Tuttavia, questo ? un processo piuttosto costoso. Il modo pi? diretto per eseguire un test delle prestazioni, infatti, richiede di replicare l?intero stack IT ed eseguire l?applicazione per un certo periodo al fine di ottenere in molte condizioni misurazioni accurate.

Pertanto, l?obiettivo principale di un possibile metodo di messa a punto automatica dovrebbe essere quello di selezionare attentamente quali configurazioni valutare, per ridurre il pi? possibile il numero di test delle prestazioni da eseguire.

Per favorire l?adozione di un autotuner (ossia, un dispositivo che esegue un metodo di messa a punto automatica), ? opportuno evitare di replicare l?intero stack IT, in modo da ridurre i costi. Tuttavia, ci? significa che i test delle prestazioni devono essere eseguiti direttamente nell?ambiente di produzione. In questo caso, l?autotuner deve prestare particolare attenzione nell?evitare configurazioni che potrebbero ridurre significativamente le prestazioni del sistema, poich? ci? si tradurrebbe direttamente in una minore qualit? del servizio e, di solito, in una perdita economica.

Come ulteriore questione che contribuisce ad aumentare la complessit? di questo problema di ottimizzazione, va considerato che la configurazione ottimizzata dei parametri varia con il carico di lavoro (workload) a cui ? esposto il sistema IT, e un metodo di ottimizzazione adeguato deve tenerlo in conto. Questa maggiore complessit? ? particolarmente impegnativa quando si eseguono i test delle prestazioni nell?ambiente di produzione, dove si devono evitare a tutti i costi errate configurazioni di parametri variabili (ossia, quelle che portano a scarse prestazioni del sistema IT).

Mettere a punto la configurazione di un sistema IT ? molto complicato: i parametri regolabili interagiscono in modi complessi, essi sono integrati in un enorme spazio di ricerca e il loro effetto dipende dal carico di lavoro a cui ? esposto il sistema.

Per evidenziare l?effetto dei parametri regolabili sulle prestazioni, ? stata eseguita una serie di esperimenti su DBMS (sistemi di gestione database) MongoDB<TM >e Cassandra<TM >utilizzando l?iniettore di carico Yahoo!<? >Cloud Serving Benchmark (YCSB). I valori dei parametri regolabili sono stati modificati durante la misurazione del throughput del DBM.

I risultati sono riportati in Figg. 1A-1C.

In Fig. 1A sono stati utilizzati MongoDB<TM >e due parametri relativi all?archiviazione del kernel Linux: nr_requests e read_ahead_kb. L?impostazione corretta di questi parametri offre un notevole impulso alle prestazioni del DBMS: senza considerare l?intero stack IT, questo miglioramento sarebbe andato perduto.

In Fig. 1B ? stato utilizzato Cassandra<TM>, che ? scritto in Macchina Virtuale Java<TM >che presenta i propri parametri regolabili: nell?esempio, il numero di thread (unit? di processo) concorrenti di Garbage Collection (tecnica di liberazione di aree di memoria non referenziate) (espresso come percentuale dei core disponibili) a fianco del parametro Linux di read-ahead (funzione lettura anticipata) sono stati messi a punti/variati. ? stato rilevato, ad esempio, che il readahead presenta un effetto impressionante sulle prestazioni di Cassandra<TM >e la selezione di un valore non appropriato ne distrugge le prestazioni.

In Fig. 1C sono stati modificati gli stessi due parametri di Fig. 1B, ma utilizzando un carico di lavoro YCSB differente. Pi? precisamente, un pesante carico di lavoro di aggiornamento ? stato modificato in un carico di lavoro di sola lettura. L?effetto dei due parametri ? notevolmente differente nelle due condizioni di carico di lavoro.

? interessante notare che il parametro di read-ahead presenta un effetto differente su differenti DBMS: per MongoDB<TM>, utilizzando il pesante carico di lavoro di aggiornamenti, il valore del read-ahead dovrebbe essere aumentato per ottenere prestazioni migliori. Al contrario, su Cassandra<TM>, con lo stesso identico carico di lavoro, la selezione di un valore elevato di read-ahead in realt? distrugge le prestazioni. Tuttavia, eseguendo Cassandra<TM >con un carico di lavoro di sola lettura, ? necessario tornare a un valore elevato di read-ahead, esattamente come eseguire MongoDB<TM >con un pesante carico di lavoro di aggiornamenti.

Questi esempi motivano l?esigenza di considerare congiuntamente l?intero stack IT e il carico di lavoro corrente durante la messa a punto dei sistemi IT, poich? essi comprendono diversi livelli, ciascuno con i propri parametri regolabili che interagiscono in modi complessi e controintuitivi. Inoltre, caratterizzare solo il carico di lavoro in arrivo non ? sufficiente per comprendere l?effetto dei parametri: deve essere considerato sia il sistema di destinazione che il carico di lavoro.

Dal punto di vista del sistema operativo, ? stato rilevato che MongoDB<TM >con pesanti aggiornamenti e Cassandra<TM >in sola lettura presentano situazioni abbastanza simili. Apparentemente, esiste una sorta di similarit? tra questi sistemi e andrebbe sfruttata per ottenere buoni risultati da un motore di ottimizzazione.

Sono state proposte molte soluzioni per risolvere il problema della messa a punto automatica di configurazione per l?ottimizzazione e possono essere ampiamente suddivise in due categorie: soluzioni che cercano di utilizzare algoritmi/motori di ottimizzazione pi? intelligenti e soluzioni che sfruttano le basi di conoscenza raccolte in precedenza.

L?utilizzo di tecniche di ricerca pi? efficienti aiuta a ridurre il numero di errate configurazioni da testare prima di convergere a quelle corrette. Tuttavia, ci? pu? aiutare solo fino a un certo punto e, inoltre, molti lavori hanno riportato che una ricerca casuale spesso funziona allo stesso livello di tecniche di ricerca pi? sofisticate e, soprattutto, potrebbe essere uno strumento efficace per l?esplorazione di spazi di ricerca pi? ampi. Ci? non dovrebbe sorprendere data la dimensione dello spazio di ricerca.

Al contrario, l?utilizzo dell?altro approccio - che ? l?oggetto della presente descrizione - pu? portare a risultati vantaggiosi.

In effetti, se una determinata applicazione ? gi? stata messa a punto in passato, le informazioni raccolte possono essere sfruttate per evitare errate configurazioni e convergere rapidamente verso l?ottimale.

Tuttavia, tutta la conoscenza diventa obsoleta abbastanza rapidamente, man mano che vengono rilasciate nuove versioni del software, modificando gli effetti dei parametri sullo stack IT. Inoltre, le nuove versioni del software modificano anche i parametri disponibili, aumentando la complessit? del riutilizzo di vecchie basi di conoscenza, che mancano di informazioni sui nuovi parametri. Le soluzioni esistenti richiedono basi di conoscenza raccolte su una replica accurata del sistema IT che ? l?obiettivo della messa a punto. La base di conoscenza, infatti, deve contenere tutti i livelli del sistema di destinazione, e ciascun livello deve essere della stessa identica versione. Inoltre, anche il livello hardware deve essere uguale, poich? macchine differenti potrebbero reagire in modo differente alla stessa configurazione. Tali basi di conoscenza sono, quindi, estremamente dispendiose da raccogliere e devono essere aggiornate di frequente per essere utili.

Come esempio, se si raccoglie una quantit? consistente di conoscenze sulla messa a punto della Macchina Virtuale Java<TM >durante la messa a punto del DBMS Cassandra<TM>, non ? possibile utilizzarle per la messa a punto di un?applicazione Web in esecuzione su Java<TM>.

D?altra parte, come esempio corrispondente, considerando un esperto di analisi delle prestazioni, non ci si aspetta che perda tutta la propria esperienza ogni volta che passa da un progetto all?altro.

Di conseguenza, se ? possibile trovare similarit? tra sistemi differenti, ? probabile che la base di conoscenza venga riutilizzata in modo vantaggioso. Tornando all?esempio delle Figg. 1A-1C, una volta stabilito che il kernel Linux deve essere configurato in modo simile per MongoDB<TM >con pesanti aggiornamenti e Cassandra<TM >in sola lettura, ? possibile riutilizzare su Cassandra<TM >tutta la conoscenza raccolta su MongoDB<TM>.

Inoltre, l?ingente base di conoscenza dovrebbe essere aggiornata periodicamente per riflettere le modifiche non solo nelle versioni del software, ma anche nei componenti hardware. Differenti versioni del software reagiscono in modo differente alle stesse configurazioni e nuove versioni del software e hardware introducono nuovi parametri regolabili. Per tenere conto di questi parametri, sarebbe necessario ricostruire periodicamente la base di conoscenza ex novo.

Il problema della messa a punto automatica di configurazione ? stato gi? affrontato nella tecnica nota. Le soluzioni proposte, tuttavia, offrono solo una soluzione parziale - in quanto si concentrano sulla messa a punto di un sistema IT molto specifico - che pu? non essere facilmente generalizzata, oppure offrono una soluzione subottimale, in quanto mirano a un problema di messa a punto specifico senza sfruttare la conoscenza disponibile.

Ad esempio, US 9.958.931 descrive un metodo di messa a punto automatica per sistemi informatici. Il metodo si basa su un carico di lavoro orientato al sistema, dove il carico di ciascun ?livello di applicazione? ? definito con un carico di lavoro differente, tipico di quel livello di applicazione; il carico di lavoro ? associato a ?bucket? e, per ciascun bucket, un insieme (o sottoinsieme) di parametri ottimali ? stato precedentemente definito nello stesso modo (elenco di schemi di ottimizzazione che sono noti per ottimizzare determinati bucket di carico di lavoro). Un sottoinsieme di parametri ? messo a punto in modo gerarchico (la gerarchia ? definita a priori utilizzando una conoscenza esplicita). Non esiste un suggerimento specifico su un metodo pi? adatto per l?ottimizzazione, mentre viene suggerita una pluralit? di schemi di ottimizzazione, uno dei quali essendo scelto in ciascun bucket.

US 9.958.931 descrive un metodo di messa a punto automatica per il sistema informatico. Il metodo si basa su un carico di lavoro orientato al sistema, dove il carico di ciascun ?livello di applicazione? ? definito con un carico di lavoro differente, tipico di quel livello di applicazione; il carico di lavoro ? associato a bucket e, per ciascun bucket, un insieme (o sottoinsieme) di parametri ottimali ? stato precedentemente definito nello stesso modo (elenco di schemi di ottimizzazione che sono noti per ottimizzare determinati bucket di carico di lavoro). Un sottoinsieme di parametri ? messo a punto in modo gerarchico (la gerarchia ? definita a priori utilizzando una conoscenza esplicita). Non esiste un suggerimento specifico su un metodo pi? adatto per l?ottimizzazione, mentre viene suggerita una pluralit? di schemi di ottimizzazione, uno dei quali essendo scelto in ciascun bucket.

U.S. 9.800.466 descrive una tecnologia per generare e modificare impostazioni di parametri regolabili per uso con un?applicazione distribuita. Viene generalmente descritto l?uso di un modello di apprendimento automatico (machine learning) per ottenere un secondo set di impostazioni di parametri regolabili basato su metriche delle prestazioni e attributi di messa in opera associati a un?applicazione distribuita utilizzando un primo set di impostazioni di parametri regolabili selezionato sulla base di dati storici.

US 20120060146 riguarda un metodo per la messa a punto automatica di un?applicazione software. Il metodo prevede di utilizzare parametri di test e di assegnarli un punteggio in base al valore di registro (log) e all?obiettivo di miglioramento. I risultati del punteggio vengono archiviati e quindi combinati con altri parametri fino a quando non viene soddisfatto un criterio desiderato. Viene anche descritta una forma di esecuzione dove viene fatto uso di un ipotetizzatore configurato per combinare il primo set di parametri con il set di parametri selezionati per produrre un secondo set di parametri basato su un algoritmo genetico.

US 8.954.309 descrive tecniche per sistemi di messa a punto, basate sulla generazione di configurazioni per test efficaci del sistema. ? descritto che le tecniche di apprendimento automatico possono essere utilizzate per creare modelli di sistemi e tali modelli possono essere utilizzati per determinare configurazioni ottimali.

Altri sistemi di messa a punto automatica sono descritti in US 2017200091, US 7.908.119, US 9.143.554 e US 20060047794.

US 20100199267 descrive un sistema dove l?ottimizzazione delle dimensioni di una configurazione di infrastruttura ? ottenuta tramite modelli predittivi.

US 20180349158 descrive tecniche di Ottimizzazione Bayesiana utilizzate in connessione con le prestazioni di una Macchina Virtuale Java.

Infine, US 20200293835 riguarda un metodo di ottimizzazione molto efficiente. Tuttavia, questo documento non descrive una soluzione specifica per sfruttare basi di conoscenza esistenti allo scopo di mettere a punto i parametri.

Il problema di messa a punto automatica delle prestazioni ? stato affrontato anche in numerosi lavori e articoli accademici.

Come esempio, iTuned<TM >(Songyun Duan, Vamsidhar Thummala e Shivnath Babu. ?Tuning database con?guration parameters with ituned? in ?Proceedings of the VLDB Endowment 2.1? (agosto 2009), pp. 1246-1257) funziona creando una superficie di risposta (RSM) delle prestazioni di DBMS utilizzando Processi Gaussiani. Il modello viene quindi utilizzato per selezionare la successiva configurazione da testare. Tuttavia, viene creata una superficie di risposta differente per ciascun carico di lavoro, senza condividere informazioni potenzialmente utili.

Nel loro articolo seminariale (Dana Van Aken et al. ?Automatic database management system tuning through large-scale machine learning?. In ?Proceedings of the ACM SIGMOD International Conference on Management of Data. Vol. Part F1277. New York, New York, USA: Association for Computing Machinery, Maggio 2017, pp. 1009-1024.), Van Aken et al., hanno introdotto il progetto Ottertune: una soluzione di apprendimento automatico al problema di messa a punto di DBMS. Ottertune sfrutta l?esperienza passata e raccoglie nuove informazioni per mettere a punto configurazioni di DBMS: esso utilizza una combinazione di metodi di apprendimento automatico supervisionati e non supervisionati per (1) selezionare i parametri pi? incisivi, (2) associare carichi di lavoro di database mai visti a carichi di lavoro precedenti da cui si pu? trasferire l?esperienza e (3) consigliare le impostazioni dei parametri. L?aspetto chiave di Ottertune ? la sua capacit? di sfruttare l?esperienza passata per accelerare il processo di ricerca su nuovi carichi di lavoro. Tuttavia, per farlo ? necessario disporre di un?ampia raccolta di esperimenti precedenti. Per sfruttare pienamente l?approccio di Ottertune, tutti questi esperimenti dovrebbero contenere tutti i parametri disponibili. Ci? potrebbe essere fattibile se si considera solo il DBMS, ma diventa sempre pi? complesso man mano che vengono considerati pi? livelli dello stack IT, poich? la dimensione dello spazio di ricerca cresce in modo esponenziale. Descrizione sommaria dell?invenzione

Lo scopo della presente invenzione ? quindi quello di fornire una nuova soluzione al problema di messa a punto automatica delle prestazioni che risolva efficacemente i problemi spiegati sopra.

A differenza degli approcci esistenti, scopo dell?invenzione ? quello di fornire un metodo in grado sia di sfruttare basi di conoscenza esistenti sia di funzionare quando tale conoscenza non ? disponibile. L?approccio proposto ? in grado di tenere conto anche del carico di lavoro e di adattare di conseguenza le configurazioni suggerite. Il carico di lavoro e il sistema regolabile sono caratterizzati utilizzando una nuova metodologia, ottenendo un?apparecchiatura di ?autotuner? in grado di sfruttare le basi di conoscenza raccolte su differenti versioni di hardware e/o software o anche sistemi completamente differenti, proprio come farebbe un essere umano. Particolare attenzione viene data ad evitare errate configurazioni, in modo da rendere pratico introdurre il modulo autotuner proposto in un ambiente di produzione.

L?obiettivo prefissato ? configurare un metodo di messa a punto in grado di considerare l?intero stack IT e di adattarsi continuamente (un processo cosiddetto ?al volo? o ?online?) al carico di lavoro corrente, anche senza strettamente richiedere una base di conoscenza raccolta. Quando una tale base di conoscenza ? disponibile, comunque, essa pu? essere sfruttata il pi? possibile per velocizzare il processo di ricerca della configurazione messa a punto. Ancora pi? importante, il sistema dovrebbe essere in grado di condividere le conoscenze raccolte durante la messa a punto di sistemi differenti: ad esempio, se ? stato appreso come il sistema operativo Linux dovrebbe essere messo a punto per un DBMS, non dovrebbe essere richiesto di ricominciare ex novo durante la messa a punto del sistema operativo Linux che esegue un calcolo scientifico.

Le forme di esecuzione descritte nella presente descrizione riguardano tecniche e apparecchiature per la messa a punto di parametri regolabili in un tipico sistema IT comprendente un?infrastruttura server che presenta un numero di livelli (stack di livelli) che consente a un utente di gestire un?applicazione tramite la quale vengono erogati alcuni servizi: per esempio, un?infrastruttura server di una banca che eroga servizi bancari online o un?infrastruttura server che eroga altri servizi ai consumatori (come consigli di acquisti, piattaforma di ecommerce, ecc.).

Sebbene qui vengano prevalentemente forniti esempi con riferimento a questo tipo di ambiente, va notato che dette tecniche e apparecchiature non sono limitate a tale infrastruttura server. Ad esempio, altri dispositivi e infrastrutture che possono trarre vantaggio dalle tecniche qui descritte possono comprendere, senza limitazioni, dispositivi mobili, set-top-box, laptop, computer desktop, dispositivi di navigazione installati a bordo di veicoli mobili, sistemi di gestione del volo in aeromobili e veicoli senza pilota umano e un qualsiasi altro dispositivo simile dove i parametri regolabili devono essere messi a punto in base a un obiettivo di prestazioni.

Resta inteso che il metodo dell?invenzione ? un metodo messo in opera da computer. Di conseguenza, l?invenzione pu? essere concepita come un metodo attuato per mezzo di un?apparecchiatura informatica e relativo supporto leggibile da computer che archivia istruzioni atte a comandare l?apparecchiatura informatica per eseguire il metodo. Un dispositivo o apparecchiatura informatica pu? comprendere almeno una memoria operativa, un?unit? di elaborazione centrale (CPU), una memoria dati rimovibile/non rimovibile e pi? dispositivi I/O (come tastiera, mouse, dispositivi di rilevamento, schermo di visualizzazione, stampante, sensori, ...).

Il supporto leggibile da computer pu? comprendere dispositivi di memoria dati, come ad esempio dischi magnetici, nastro magnetico, RAM, ROM, memoria di sola lettura programmabile e cancellabile elettricamente (EEPROM), memoria flash o altra tecnologia di memoria, memoria di sola lettura per compact disc (CD-ROM), dischi versatili digitali (DVD) o altra memoria ottica e cos? via. Resta inteso, comunque, che i supporti leggibili da computer, come qui utilizzati, possono comprendere non solo supporti di archiviazione fisici per computer ma anche mezzi di comunicazione, come ad esempio onde portanti o un altro meccanismo di trasmissione.

L?applicazione dell?invenzione pu? selezionare in modo automatico i parametri di configurazione di un qualsiasi sistema IT di terze parti in modo da ottimizzarne le prestazioni.

Il metodo ? in grado di mettere a punto una configurazione di un sistema IT, senza utilizzare linee guida di messa a punto standard, adattate al carico di lavoro effettivo.

Caratteristiche dettagliate, vantaggi e forme di esecuzione dell?invenzione saranno illustrati e risulteranno evidenti da una valutazione della descrizione dettagliata, dei disegni e delle rivendicazioni seguenti.

Inoltre, resta inteso che sia la descrizione sommaria dell?invenzione di cui sopra che la seguente descrizione dettagliata sono esemplificative, non limitative e intese a fornire una spiegazione accettabile - nella misura necessaria per mettere un esperto del ramo in condizione di attuare l?invenzione - senza limitare l?ambito dell?invenzione come rivendicato. Varianti e modifiche varie entro l?ambito dell?invenzione risulteranno evidenti a questi esperti del ramo da questa descrizione dettagliata.

Breve descrizione dei disegni

I disegni allegati sono integrati e costituiscono una parte di questa descrizione; i disegni intendono illustrare forme di esecuzione preferite dell?invenzione e insieme alla descrizione dettagliata intendono spiegare i principi dell?invenzione.

La seguente descrizione dettagliata delle forme di esecuzione preferite ? fornita a titolo di esempio e deve essere letta insieme ai disegni allegati, in cui:

Figg. 1A-1B sono grafici di throughput di DBMS in differenti sistemi IT dove sono stati modificati i valori di alcuni parametri regolabili;

Fig. 2 ? un diagramma che mostra un schema del processo di messa a punto e dell?architettura dell?invenzione;

Figg. 3A e 3B sono due grafici che esemplificano un processo di Ottimizzazione Bayesiana;

Figg. 4A-4C sono grafici del metodo di Reaction Matching (Corrispondenza di Reazione) utilizzato per calcolare distanze tra attivit? (tasks), in particolare Fig. 4A che rappresenta il valore di una metrica di prestazione ottenuta da un?attivit? ? quando compilato con flags speci ?cati in Fig. 4B ? la rilevanza calcolata con un?Equazione 2 (si veda sotto); e Fig. 4C mostra le distanze tra l?attivit? ? e misurate con l?Equazione 3 (si veda sotto) utilizzando e

Fig. 5 ? uno pseudocodice esemplificativo di un processo CGPTuner utilizzato nel metodo dell?invenzione.

Descrizione dettagliata delle forme di esecuzione preferite

Di seguito, ? illustrata la soluzione che viene suggerita al problema di messa a punto automatica delle prestazioni.

Un metodo di messa a punto (messo in opera tramite un modulo tuner (ottimizzatore)) per un Sistema sotto Test (SUT) provvisto di un certo numero di parametri regolabili ? composto principalmente da due componenti: un modulo di caratterizzazione e un modulo tuner. Per offrire una migliore comprensione, ciascun componente viene descritto di seguito in modo separato e, infine, viene descritta la loro combinazione.

La spiegazione viene, comunque, fornita formalizzando prima il problema di messa a punto automatica di configurazione, quindi descrivendo l?Ottimizzazione Bayesiana e la sua estensione contestuale, quindi viene descritta in dettaglio la caratterizzazione del Reaction Matching e, infine, il metodo di messa a punto automatica effettivo.

L?obiettivo del metodo di messa a punto o di un processo di ottimizzazione ? cercare e trovare un vettore di configurazione messo a punto nello spazio di configurazione che, quando applicato a un sistema IT porta a ottimizzare un determinato indicatore di prestazione

Si intende selezionare il vettore di configurazione tenendo conto del particolare carico di lavoro a cui ? esposto il sistema IT dove ? lo spazio dei possibili carichi di lavoro e ? una descrizione del carico di lavoro fornita da una determinata metodologia di caratterizzazione del carico di lavoro. Si assume che una tale descrizione esista solo per essere in grado di descrivere il processo di messa a punto, ma questa descrizione non ? utilizzata nella soluzione proposta.

L?indicatore di prestazione pu? essere una qualsiasi caratteristica misurabile del sistema (come throughput, tempo di risposta, consumo di memoria, ecc.).

In base all?approccio scelto, viene sfruttata la conoscenza raccolta durante le passate sessioni di messa a punto. Vale a dire, ? disponibile una base di conoscenza composta da tuple Di nuovo, la presenza di nella base di conoscenza serve solo a sottolineare il fatto che ciascuna tupla potrebbe essere stata raccolta su una differente combinazione sistema (SUT)-carico di lavoro; in realt?, l?accesso al valore di non ? richiesto per mandare in esecuzione il processo di messa a punto.

Se non ? disponibile alcuna conoscenza, il metodo di messa a punto inizia con una base di conoscenza vuota ed esegue alcune fasi preliminari. In particolare, le iterazioni preliminari di messa a punto sono quindi dedicate al bootstrap (inizializzazione) della base di conoscenza. Inizialmente, viene valutata la configurazione predefinita del fornitore (linea di base). Quindi, l?utente pu? specificare e immettere ulteriori configurazioni da valutare, se sono disponibili configurazioni promettenti; altrimenti, il metodo comporterebbe una fase casuale in cui viene valutato un certo numero di configurazioni selezionate casualmente definite dall?utente.

Si suppone che la conoscenza sia stata raccolta nello stesso spazio di ricerca che ? attualmente in fase di ottimizzazione:

Poich? il carico di lavoro si evolve nel tempo, si evolve anche il vettore di configurazione ottimale. Si assume che, al tempo il metodo di messa a punto porti a suggerire una configurazione candidata che ? adattata al carico di lavoro corrente e al sistema di destinazione viene quindi rilevato che l?applicare al sistema sotto il carico di lavor comporta una misurazione delle prestazioni rumorosa, il che significa che l?indicatore di prestazione ? al di fuori dell?intervallo limite accettabile predefinito

Il metodo di messa a punto viene eseguito come illustrato in Fig. 2 e viene ripetuto in modo iterativo col passare del tempo.

L?iterazione ? viene avviata applicando a un Sistema sotto Test (SUT) una configurazione ??? suggerita dal modulo tuner (descritto in dettaglio di seguito), si veda la fase (1). Quindi, viene eseguito un test delle prestazioni in modo da raccogliere le metriche delle prestazioni, ottenendo un punteggio delle prestazioni si veda la fase (2). Va notato che all?iterazione il sistema ? soggetto a un carico di lavoro in arrivo che non pu? essere controllato n? misurato. A questo punto, ? stata completata la valutazione di i dati raccolti (ossia, la tupla vengono archiviati nella base di conoscenza (si veda la fase (3)) e ci si prepara per la successiva iterazione.

Il modulo di caratterizzazione e previsione (descritto in dettaglio di seguito) utilizza i dati archiviati nella base di conoscenza (si veda la fase (4)) per costruire un vettore di caratterizzazione Durante una fase di caratterizzazione, ? necessario ricostruire le informazioni mancanti su tutti i carichi di lavoro passati e anche acquisire le informazioni su sistemi precedenti

Inoltre, il modulo di caratterizzazione e previsione produce una previsione sul successivo vettore di caratterizzazione

Infine, la caratterizzazione calcolata il vettore di caratterizzazione previsto lo stesso ?e le informazioni provenienti dalla base di conoscenza

vengono forniti al modulo tuner, si veda la fase (5). A questo

punto, pu? essere avviata nuovamente una successiva iterazione (si veda la fase (6)), ottenendo un nuovo suggerimento dal modulo tuner e tornando alla fase (1).

Di seguito, viene adesso fornita una descrizione separata del modulo di messa a punto e del modulo di caratterizzazione e previsione. Ottimizzazione Bayesiana

In questa sezione viene spiegato il comportamento del modulo di messa a punto, che si basa sull?Ottimizzazione Bayesiana.

L?Ottimizzazione Bayesiana (BO) ? uno strumento potente che ha guadagnato una grande popolarit? negli ultimi anni (una revisione approfondita di BO pu? essere trovata in Bobak Shahriari et al. ?Taking the Human Out of the Loop: A Review of Bayesian Optimization?. In ?Proceedings of the IEEE 104.1 (Jan.

2016)? pp. 148?175. issn: 0018-9219.). Qui viene fornita solo una breve introduzione, sintetizzata visivamente nelle Figg. 3A e 3B.

Formalmente, ? necessario ottimizzare una funzione obiettivo incognita

(Eq. 1)

dove non presenta alcuna forma chiusa semplice ma pu? essere valutata in un qualsiasi punto di interrogazione arbitrario ?? nel dominio pertinente. La valutazione della funzione pu? portare a trovare osservazioni rumorose in termini di parametri di prestazione e di solito ? piuttosto dispendiosa da eseguire. L?obiettivo ? convergere rapidamente verso buoni punt in modo da ottimizzare rapidamente

Inoltre, ? necessario evitare di valutare punti che portano a valori di funzione errati. In uno scenario ideale, come detto sopra, il modulo autotuner funzionerebbe direttamente in un ambiente di produzione, quindi ? necessario trovare rapidamente configurazioni ben performanti ed evitare di esplorare eccessivamente lo spazio di ricerca. In termini di messa a punto IT, si desidera trovare una configurazione che ottimizzi un determinato indicatore di prestazione e questo processo di ricerca dovrebbe essere eseguito simultaneamente per: (i) esplorare lo spazio di configurazione per raccogliere conoscenza e (ii) sfruttare la conoscenza raccolta in modo da convergere rapidamente verso configurazioni ben performanti. Si noti che l?Equazione 1 ? equivalente al problema di messa a punto automatica delle prestazioni che ? stato esposto all?inizio di questa descrizione, ad eccezione della dipendenza dal sistema e dal carico di lavoro che non ? considerata in questo stadio.

Pi? precisamente, ora viene fornita una descrizione di un modulo tuner che funziona per una singola combinazione (fissa) SUT-carico di lavoro.

L?Ottimizzazione Bayesiana (BO) ? un approccio basato su modelli sequenziali per risolvere il problema di ottimizzazione dell?Equazione 1. Essenzialmente, viene creato un modello surrogato di ed esso viene raffinato sequenzialmente man mano che vengono osservati pi? dati. Utilizzando questo modello, viene calcolato in modo iterativo un valore di una Funzione di Acquisizione che viene utilizzata per selezionare il successivo punto da valutare.

La Funzione di Acquisizione ? ricavata analiticamente dall?emissione del modello surrogato. Intuitivamente, la Funzione di Acquisizione valuta l?utilit? dei punti candidati per la successiva valutazione di trovando un compromesso tra l?esplorazione di zone incerte con lo sfruttamento di zone buone. Poich? la Funzione di Acquisizione ? ricavata analiticamente dal modello surrogato, ? molto facile da ottimizzare. Ad esempio, la Funzione di Acquisizione pi? semplice ? il Limite Inferiore di Confidenza (LCB), che, per ciascun punto, ? definito come il valore previsto dal modello surrogato per quel punto meno l?incertezza sulla previsione. Assumendo che il nostro obiettivo sia ridurre al minimo la funzione obiettivo, l?LCB fornisce una stima ottimistica della funzione. I punti da valutare vengono quindi selezionati per via di un ottimo valore previsto (sfruttamento) o di un?elevata incertezza di previsione (esplorazione).

Pertanto, l?Ottimizzazione Bayesiana (BO) presenta due ingredienti chiave: il modello surrogato e la Funzione di Acquisizione

In questo contesto, i Processi Gaussiani (GP) sono considerati modelli surrogati, che ? una scelta molto comune nell?Ottimizzazione Bayesiana (BO), comunque funzionerebbero anche scelte differenti, disponibili in letteratura (come Foreste Casuali o Reti Neurali). Nell?esempio rappresentato nelle Figg. 3A e 3B, il Limite Inferiore di Confidenza (LCB) viene utilizzato come Funzione di Acquisizione ma sono possibili altre scelte, come Expected Improvement (EI), Probability of Improvement (PI), Thompson Sampling (TS), o anche strategie miste, come l?approccio GP-Hedge che, invece di concentrarsi su una specifica funzione di acquisizione, adotta un portafoglio di funzioni di acquisizione governate da una strategia dei banditi multi-armati (multi-armed bandit) online. L?idea chiave dell?approccio GP-Hedge ? calcolare molte differenti Funzioni di Acquisizione a ciascuna iterazione di messa a punto e selezionare progressivamente la migliore in base alle prestazioni precedenti.

Facendo riferimento alle Figg. 3A e 3B, ? mostrata schematicamente un?Ottimizzazione Bayesiana (BO) esemplificativa. In questa forma di esecuzione, si intende ridurre al minimo la funzione incognita e sono gi? stati osservati 3 punti, che vengono utilizzati per calcolare la media e l?incertezza previste dai GP: questi due attributi di GP vengono combinati nelle Funzioni di Acquisizione per selezionare il successivo punto da valutare. Funzioni di Acquisizione differenti selezionano punti differenti.

Un Processo Gaussiano GP ? un modello non parametrico che ? completamente caratterizzato da (i) la sua funzione media p

e (ii) il suo kernel definito positivo o funzione di covarianza,

Sia il set delle osservazioni passate e un punto di test arbitrario. La variabile casuale condizionata alle osservazioni segue una distribuzione normale con funzioni di media e varianza che dipendono dalla funzione media precedente e dai dati osservati tramite il kernel. Cos?, il kernel sta rappresentando la covarianza delle variabili casuali di Processo Gaussiano. In altri termini, la funzione di kernel modella la covarianza tra ciascuna coppia in uno spazio.

La previsione di GP dipende dalla funzione precedente e dai dati osservati tramite il kernel. La funzione precedente controlla la previsione di GP in zone non osservate e, quindi, pu? essere utilizzata per integrare ?convinzioni? precedenti sul problema di ottimizzazione. Il kernel (o funzione di covarianza), invece, controlla quanto i punti osservati influenzano la previsione nelle zone vicine e, quindi, governa le previsioni nelle zone gi? esplorate.

Di conseguenza, quando due punti (ossia, due configurazioni) nello spazio di ricerca presentano un?alta correlazione (in base al kernel selezionato), ci si aspetta che i loro valori di funzione associati (ossia, i loro indicatori di prestazione) siano simili.

Il kernel viene quindi utilizzato per misurare la similarit? di due configurazioni, esprimendo l?idea che configurazioni simili dovrebbero rendere prestazioni simili.

Essenzialmente, il GP ? un modello di regressione che ? molto utile nel prevedere il valore atteso di un punto e l?incertezza su tale previsione. Nell?Ottimizzazione Bayesiana (BO), le due grandezze vengono combinate dalla Funzione di Acquisizione per comandare il processo di ricerca. Nella presente forma di esecuzione, ? stato utilizzato per gli esempi proposti un kernel Mat?rn 5/2, che ? la classe di kernel pi? ampiamente utilizzata in letteratura, comunque, funzionerebbero anche altre scelte di kernel.

Finora si ? assunto che la prestazione possa essere espressa solo come una funzione della configurazione Tuttavia, le prestazioni di un sistema IT, ad esempio un DBMS, dipendono anche da altre variabili, non controllate, come ad esempio il carico di lavoro a cui l?applicazione ? esposta e, cosa pi? importante, l?effettivo SUT ? affrontato.

Secondo l?invenzione, l?Ottimizzazione Bayesiana (BO) ? stata estesa per gestire tali situazioni. L?idea chiave ? che vi sono diverse attivit? correlate

che devono essere ottimizzate. Essenzialmente, i dati di un determinata attivit?

brevemente detta nel seguito, possono fornire informazioni su un?altra

attivit? brevemente detta nel seguito.

Un?attivit? ? ? considerata una definizione di una determinata combinazione SUT-carico di lavoro (ad es., il DBMS Cassandra che esegue un carico di lavoro di sola lettura) e viene associata ad una caratterizzazione numerica che verr? descritta di seguito.

Si assume che sia una caratterizzazione numerica dell?attivit? e viene definita una nuova funzione di kernel combinato (o covarianza) che funziona su configurazioni e caratterizzazioni di attivit?

Questo nuovo kernel combinato ? formalizzato come la somma di due kernel definiti nello spazio di configurazione ? e nello spazio di caratterizzazione di attivit? rispettivamente: Il kernel

? chiamato kernel di configurazione e misura la covarianza tra le confi-

gurazioni, il kernel ? il kernel di attivit? e misura la covarianza tra le attivit?.

Un GP con questo kernel combinato ? un modello predittivo con una struttura aggiuntiva composta da due componenti: Il componente

modella le tendenze generali tra le attivit?, mentre il componente modella la deviazione specifica della configurazione da questa tendenza. Analogamente a quanto fatto per il kernel di configurazione, viene utilizzato un kernel Mat?rn 5/2 anche per il kernel di attivit? negli esempi proposti, ma funzionerebbero anche altre scelte.

Resta inteso che differenti funzioni di covarianza possono essere selezionate per il kernel di configurazione e per il kernel di attivit?.

Nel metodo dell?invenzione, si sfrutta il fatto che le prestazioni di una determinata combinazione SUT-carico di lavoro sono correlate con le prestazioni di altre combinazioni SUT-carico di lavoro simili, dove la similarit? ? misurata dalla funzione di kernel combinato definita sopra.

Si noti che il kernel combinato ? stato definito utilizzando un?operazione di somma. Ci? intende che due punti nello spazio di ricerca sono considerati simili (altamente correlati) quando essi (1) presentano una configurazione simile (altamente correlati secondo la funzione di kernel di configurazione selezionata) o (2) presentano un?attivit? simile (altamente correlati secondo il kernel di attivit? selezionato). Le due grandezze possono essere combinate utilizzando operazioni differenti, ottenendo comportamenti differenti. Come esempio, se i due kernel vengono moltiplicati, i due punti sarebbero considerati simili solo quando essi sono altamente correlati sia in termini di configurazione che di attivit?.

In altri termini, utilizzando questo kernel combinato lo spazio di Processo Gaussiano viene ampliato con il componente di caratterizzazione di attivit?, ma quando si ottimizza la Funzione di Acquisizione viene ottimizzato solo il sottospazio di configurazione. Cos?, si ottiene una configurazione suggerita che ? adattata per la combinazione SUT-carico di lavoro corrente, e questa configurazione viene selezionata sfruttando tutte le configurazioni che sono state testate in passato, anche su differenti SUT e/o carichi di lavoro.

Reaction Matching

In questa sezione, viene descritto un processo di Reaction Matching, ossia una metodologia di calcolo della distanza che viene utilizzata per ricavare una caratterizzazione di attivit?.

L?obiettivo finale ? fornire al modulo tuner un vettore di caratterizzazione. Per fare ci?, il metodo prevede di iniziare a calcolare similarit? tra attivit? differenti utilizzando il Reaction Matching: una tecnica ispirata al campo dei Sistemi di Raccomandazione (RS).

I programmi di Sistema di Raccomandazione (RS) sono ampiamente utilizzati nella nostra vita quotidiana. Essi sono adottati per suggerire articoli agli utenti, aiutandoli a navigare in vasti cataloghi (come Netflix<? >o Amazon<?>). Lo scopo essenziale di un Sistema di Raccomandazione (RS) ? prevedere la rilevanza di un articolo per un utente

Per raggiungere questo obiettivo, il Sistema di Raccomandazione (RS) sfrutta le similarit? tra articoli o utenti.

Cos?, il metodo proposto tratta l?attivit? bersaglio (combinazione SUT-carico di lavoro) come un utente in un Sistema di Raccomandazione (RS) e una determinata configurazione come l?articolo all?interno del catalogo del Sistema di Raccomandazione (RS), contenente tutte le impostazioni possibili per il sistema. La rilevanza riflette quanto il sistema ? beneficia della configurazione rispetto alla configurazione di linea di base (ossia, predefinita del fornitore) quando esposto al carico di lavoro

Quando ? necessario ottimizzare un determinato indicatore di prestazione

(es., tempo di esecuzione), ? definito come il valore di questo

indicatore di prestazione ottenuto dal sistema quando configurato utilizzando

ed esposto al carico di lavoro Assumendo la configurazione di linea di base

la rilevanza ? definita come:

(Eq. 2)

Per illustrare l?approccio del Reaction Matching, si suppone di avere accesso ad alcune informazioni raccolte in precedenza sulle prestazioni di alcune attivit? (ossia, combinazioni SUT-carico di lavoro) (che potrebbe essere lo stesso sistema esposto a un differente carico di lavoro o anche sistemi completamente differenti) dove ciascuna attivit? ? stata valutata su una variet? di configurazioni Le configurazioni valutate possono essere differenti tra attivit? differenti, ma si assume che vi sia almeno una qualche sovrapposizione (ossia, per ogni coppia di attivit? si deve avere almeno due configurazioni comuni).

Per misurare la similarit? tra due attivit?, viene utilizzato il processo di Reaction Matching (RM), che ? rappresentato graficamente nelle Figg. 4A-4C e descritto di seguito. Fig. 4B mostra i punteggi di rilevanza calcolati utilizzando l?Eq. 2, che porta tutte le linee di base a 0.

Dopo aver calcolato i punteggi delle prestazioni con l?Eq. 2, la similarit? tra due attivit? ? definita come inversamente proporzionale alla distanza dei punteggi di rilevanza ricevuti con le stesse configurazioni.

Definendo come il set delle configurazioni che sono state valutate sia su un?attivit? bersaglio (l?attivit? da caratterizzare) sia su un?altra at (che ? disponibile nella base di conoscenza), la distanza tra due attivit?

calcolata come:

(Eq.3)

Nell?esempio di Fig. 4C, il Reaction Matching (RM) utilizza per misurare le distanze, e identifica come l?attivit? pi? simile a poich? la similarit? ? definita come l?inverso della distanza.

Va notato che la definizione di distanza dipende dai vettori di configurazione che viene valutata su entrambe le attivit? e, quindi, ? dipendente dal tempo. In altre parole, il Reaction Matching (RM) ? un processo ?in tempo reale? o ?al volo? e le distanze calcolate variano man mano che la messa a punto procede e risulta disponibile una maggiore conoscenza. Ci? ? in contrasto con altre metodologie di caratterizzazione e approcci basati su codice che non aggiornano mai le loro ?convinzioni?. Inoltre, misurando le prestazioni effettive, la caratterizzazione di Reaction Matching (RM) ? dipendente dal carico di lavoro e disaccoppiata dal codice sorgente, che pu? essere ingente e complesso come piace allo sviluppatore.

Modello di messa a punto (tuning)

In questa sezione, infine, vengono riuniti tutti i componenti del metodo di messa a punto dell?invenzione. ? stato spiegato come il Reaction Matching (RM) misura la distanza tra differenti attivit? ma l?obiettivo finale ? fornire al modulo tuner una caratterizzazione ? dell?attivit? corrente

Per fare ci?, il metodo inizia misurando la distanza di Reaction Matching (RM) tra tutte le attivit? che possono essere trovate nella base di conoscenza KB.

Quando si inizia ex novo, con una base di conoscenza KB vuota, come spiegato sopra, le prime iterazioni di messa a punto (dove ? definito dall?utente) vengono utilizzate per valutare la configurazione predefinita del fornitore o alcune campionate casualmente (a seconda delle preferenze dell?utente) in modo da inizializzare la base di conoscenza KB disponibile.

Poi, le distanze calcolate dal processo di Reaction Matching (RM) vengono utilizzate come ingresso per un algoritmo di clustering (analisi di gruppi dati) (ad esempio k-means, DBSCAN, EM).

I cluster (gruppi dati) calcolati sono considerati attivit? archetipe, in quanto rappresentano il tipo di attivit? che dovrebbero essere messe a punto in modi simili.

Quindi, la distanza tra l?attivit? bersaglio da valutare e i vari cluster viene infine utilizzata come una caratterizzazione per CGPTuner (Tuner con GP contestuale). Per calcolare questa distanza, ? sufficiente calcolare la distanza di Reaction Matching (RM) tra l?attivit? bersaglio e tutte le attivit? nella base di conoscenza (KB). Quindi, per ciascun cluster viene presa la media delle distanze tra l?attivit? bersaglio e tutte le attivit? che sono state assegnate al cluster considerato mediante l?algoritmo di clustering. Facendo questo per tutti i cluster, si ottiene un vettore di distanze, che viene utilizzato come il vettore di caratterizzazione da immettere nel CGPTuner.

? importante sottolineare che la caratterizzazione del carico di lavoro non si basa sull?identificazione del numero corrente e dei tipi di richieste elaborate dal sistema, come da definizione del carico di lavoro. Piuttosto, SUT e carichi di lavoro sono caratterizzati utilizzando il Reaction Matching (RM). Come comprensione generale, se due differenti SUT, quando esposti a carichi di lavoro differenti, richiedono impostazioni simili, allora queste due attivit? dovrebbero essere considerate simili, e possono essere messe a punto utilizzando la stessa configurazione. Se le due attivit? subiscono un incremento di prestazione dalle stesse configurazioni, si pu? dedurre che esse mostrano reazioni simili anche ad altre configurazioni. In altre parole, ci si aspetta che una coppia di configurazione SUT-carico di lavoro presenti modelli simili in modo tale che determinate configurazioni siano vantaggiose per entrambe, mentre altre sono dannose e altre ancora non presentano proprio alcun effetto.

Come detto sopra, l?attivit? bersaglio corrente ? caratterizzata in termini della sua distanza di Reaction Matching (RM) rispetto alle attivit? archetipe che sono state determinate dalla base di conoscenza mediante l?algoritmo di clustering. Dette attivit? archetipe vengono identificate utilizzando l?algoritmo di clustering nella base di conoscenza KB. Cos?, una volta che la base di conoscenza KB sia stata partizionata in alcuni cluster, pu? iniziare la messa a punto effettiva. Si noti che, man mano che la messa a punto procede, verranno aggiunti sempre pi? punti alla base di conoscenza, modificando potenzialmente l?uscita dell?algoritmo di clustering.

Quando si opera la messa a punto su un determinato sistema ?, vengono considerate le ultime iterazioni del processo di messa a punto Si suppone che l?utente sia in grado di fornire una buona stima di ? tale che, all?interno delle iterazioni considerate, si possa assumere che il carico di lavoro

effettivo non ? cambiato. Si considerano le ultime ? iterazioni come l?attivit? bersaglio corrente e le configurazioni come il set utilizzato per calcolare la distanza di Reaction Matching (RM). Si cercano nella base di conoscenza KB tutti i cluster disponibili e, per ciascun cluster, la distanza di Reaction Matching (RM) tra l?attivit? corrente e il cluster viene misurata utilizzando il set ottenendo un vettore di caratterizzazione come spiegato sopra.

In conclusione, in Fig. 5, ? riportato lo pseudocodice del processo di CGP-Tuner secondo l?invenzione per la messa a punto automatica delle configurazioni di DBMS. Va notato che non ? necessariamente richiesto un criterio di arresto, poich? il processo di messa a punto pu? continuare a ottimizzare il sistema in modo online. In questo modo, il tuner si occupa di adattare la configurazione al carico di lavoro in arrivo. Poich? la tecnica proposta ? basata su BO, si converger? verso configurazioni ottimali una volta trovate.

Come rappresentato in Fig. 5, ciascuna iterazione del metodo di messa a punto prevede 5 fasi. L?iterazione ? ha accesso a tutte le precedenti voci della KB:

1. Nella fase iniziale, la base di conoscenza KB ? suddivisa in attivit? e ogni voce ? assegnata a un?attivit?. Questo pu? essere fatto in tre modi differenti:

a. se le informazioni di carico di lavoro sono disponibili, possono essere utilizzate direttamente e pu? essere applicato un algoritmo di clustering standardizzato;

b. ? possibile creare una nuova attivit? ogni iterazioni;

c. se l?accesso al punteggio di linea di base ? disponibile tramite un gruppo di controllo, ? possibile utilizzare un algoritmo di rilevamento di punti di modifica standardizzato e ricavare le modifiche del carico di lavoro.

Si assume che possa essere facilmente noto quando il sistema cambia e utilizzare tali informazioni per creare una nuova attivit?. In ogni caso, a ciascuna voce ? assegnata un?attivit? Idealmente, vi sono pi? voci che attivit?, in modo da avere pi? voci assegnate a ciascuna attivit?.

2. Utilizzando le informazioni di attivit?, viene calcolata la distanza di RM tra ogni coppia di attivit? nella KB. Le distanze di attivit? vengono quindi utilizzate per eseguire un algoritmo di clustering standardizzato, assegnando c a un cluster La base di conoscenza KB diventa: nche in questo caso, dovrebbero esserci pi? attivit? che cluster.

3. A questo punto, i cluster calcolati e le distanze di attivit? vengono utilizzati per ricavare le informazioni di caratterizzazione di attivit?. Quando si caratterizza l?attivit? appartenente al cluster ?, vengono considerati tutti gli altri cluster Per ciascun altro cluster, vengono considerate le attivit? che ad esso sono state assegnate: Quindi, viene calcolata la distanza di RM media tra l?attivit? bersaglio e le altre attivit? questa sar? la distanza tra l?attivit? bersaglio e l?attivit? archetipe Ripetendo ci? per tutti i cluster, si porta a ricavare la caratterizzazione di attivit? bersaglio

ossia, il vettore numerico Si pu? notare che, se la caratterizzazione calcolata ? molto differente da quella prevista alla fase 5 dell?iterazione precedente, si pu? decidere di utilizzare queste informazioni come un rilevamento di punti di modifica e di creare una nuova attivit?, tornando alla fase 2.

4. Utilizzando viene calcolato un CGP e la AF (Funzione di Acquisizione) associata.

5. Utilizzando tutti i vettori di caratterizzazione calcolati si pu? prevedere la caratterizzazione per il successivo punto. rappresenta la caratterizzazione della combinazione SUT-carico di lavoro della successiva iterazione ed ? essenzialmente una previsione del carico di lavoro. La metodologia di previsione pi? semplice consiste nell?utilizzare l?ultima: La caratterizzazione prevista viene utilizzata per ottimizzare la AF e selezionare la successiva configurazione da valutare. A questo punto, viene applicata la suddetta configurazione, viene misurato il punteggio delle prestazioni associato viene aggiornata la base di conoscenza KB e, quindi, il sistema pu? passare alla successiva iterazione, ricominciando dalla fase 1.

Nella forma di esecuzione di cui sopra, si ? assunto che sia disponibile una ampia base di conoscenza KB, in modo da poter ottenere una quantit? rilevante di informazioni su attivit? differenti. Ci? pu? essere fatto valutando molti sistemi differenti in un ambiente di test prima di passare a sistemi di produzione reali. In effetti, l?intera caratterizzazione ? costruita con l?obiettivo di riutilizzare KB obsolete. Comunque, quando questo non ? il caso, ? anche possibile iniziare ex novo con una base di conoscenza KB vuota. In questo caso, il processo creerebbe semplicemente una singola attivit? e ricorrerebbe alla semplice Ottimizzazione Bayesiana con GP. Man mano che sempre pi? punti diventano disponibili, il numero di attivit? aumenta ed ? possibile ricavare caratterizzazioni utili.

Come si pu? comprendere dalla descrizione di cui sopra, il metodo proposto rappresenta una valida soluzione al problema di messa a punto automatica di configurazione. Elementi pertinenti del metodo sono rappresentati dal processo di Reaction Matching e dal processo di clustering per ricavare una caratterizzazione sia del sistema che del carico di lavoro: ci? permette di sfruttare favorevolmente le conoscenze che sono state raccolte su differenti sistemi regolabili, per ottenere un processo di ottimizzazione pi? veloce e pi? affidabile dei parametri regolabili.

Sebbene la presente descrizione sia stata descritta con riferimento a una forma di esecuzione specifica, resta inteso che il metodo e l?apparecchiatura forniti dalla presente descrizione possono presentare una serie di varianti e correzioni senza allontanarsi dall?ambito e dal contesto della presente descrizione. La descrizione fornita sopra ? puramente illustrativa e non intende essere un elenco esaustivo di tutte le possibili forme di esecuzione, applicazioni o modifiche dell?invenzione. Pertanto, varie modifiche ai metodi e all?apparecchiatura descritti dell?invenzione risulteranno evidenti agli esperti del ramo senza allontanarsi dall?ambito dell?invenzione che ? definito solo dalle rivendicazioni allegate.

Claims (9)

1. RIVENDICAZIONI 1. Metodo di messa a punto (tuning) attuato da computer, eseguito su un sistema IT comprendente un Sistema sotto Test (SUT) che comprende uno stack di livelli software, provvisto di un certo numero di parametri regolabili, il metodo comprendente le fasi di fornire una base di conoscenza (knowledge base) (KB) composta da tuple

   dove rappresenta il Sistema sotto Test (SUT), rappresenta un carico di lavoro (workload) a cui il Sistema sotto Test (SUT) ? ? esposto ? un vettore di configurazione in uno spazio di configurazione di detti parametri regolabili e rappresenta gli indicatori di prestazione di detto Sistema sotto Test (SUT), un modulo di caratterizzazione e previsione, e un modulo tuner (ottimizzatore) dette tuple essendo raccolte durante sessioni iterative di messa a punto, dove ciascuna iterazione ? avviata applicando a un Sistema sotto Test (SUT) ??, soggetto a un carico di lavoro in arrivo ???? ?, una configurazione

   suggerita da detto modulo tuner, quindi eseguendo un test delle prestazioni per raccogliere metriche di prestazioni, ottenendo un punteggio delle prestazioni di detti indicatori di prestazione e infine archiviando dette tuple

   in detta base di conoscenza (KB), caratterizzato da ci? che detto modulo di caratterizzazione e previsione costruisce un vettore di caratterizzazione n base ai dati archiviati in detta base di conoscenza (KB) e produce una previsione sul successivo vettore di caratterizzazione detti vettore di caratterizzazione calcolato e vettore di caratterizzazione previsto

   essendo forniti a detto modulo tuner, dove il vettore di caratterizzazione ? una caratterizzazione numerica associata a un?attivit? (task) che ? definita da una combinazione Sistema sotto Test (SUT)-carico di lavoro e viene calcolata una similarit? tra una prima attivit? da valutare e una seconda attivit? disponibile in detta base di conoscenza (KB), detta similarit? essendo definita come l?inverso di una distanza di punteggi di rilevanza tra la prima attivit? tare e una seconda attivit?

   ricevuta con un set di configuraz

   e quindi, in base a detta similarit?, detto modulo tuner seleziona una nuova configurazione suggerita da applicare a detto Sistema sotto Test (SUT) in una successiva iterazione.
2. 2. Metodo di messa a punto attuato da computer come nella rivendicazione 1, in cui detto punteggio di rilevanza ? definito come: dove catore di prestazione

   ottenuto dal Sistema sotto Test (SUT) ? quando configurato utilizzando una configurazione ed esposto a un carico di lavoro e assumendo una configurazione di linea di base
3. 3. Metodo di messa a punto attuato da computer come nelle rivendicazioni 1 o 2, in cui detta distanza tra una prima attivit? da valutare e una seconda attivit? viene calcolata tramite un processo di Reaction Matching (Corrispondenza di Reazione) come:

   dove ? un set delle configurazioni che sono state valutate sia sulla prima attivit? che su una seconda attivit?
4. 4. Metodo di messa a punto attuato da computer come nelle rivendicazioni 1, 2 o 3, in cui un modello surrogato, utilizzato per selezionare le configurazioni in detto modello tuner basato su Ottimizzazione Bayesiana (BO), ? un Processo Gaussiano (GP).
5. 5. Metodo di messa a punto attuato da computer come nella rivendicazione 4, in cui detto Processo Gaussiano (GP) ? un tuner bandit con processo gaussiano contestuale (CGPTuner) che utilizza come contesto detta caratterizzazione fornita da detta similarit? calcolata.
6. 6. Metodo di messa a punto attuato da computer come nella rivendicazione 5, in cui il Processo Gaussiano (GP) ? provvisto di una funzione di kernel combinato che ? la somma tra il kernel di configurazione

   definito su uno spazio di configurazione e un kernel di attivit? definito su uno spazio di caratterizzazione di attivit? comportando che detto Processo Gaussiano (GP) presenti una struttura aggiuntiva composta da un componente di caratterizzazione che modella tendenze generali tra le attivit? e un componente di configurazione che modella deviazione specifica della configurazione da dette tendenze generali.
7. 7. Metodo di messa a punto attuato da computer come in una qualsiasi delle rivendicazioni precedenti, in cui ? prevista una fase preliminare quando detta base di conoscenza (KB) ? vuota, che comprende le iterazioni preliminari di messa a punto dedicate al bootstrap (inizializzazione) di detta base di conoscenza.
8. 8. Metodo di messa a punto attuato da computer come nella rivendicazione 7, in cui dette iterazioni preliminari di messa a punto comprendono la valutazione di una configurazione predefinita del fornitore (linea di base) ed eventualmente un certo numero di configurazioni definite dall?utente o selezionate casualmente.
9. 9. Sistema di messa a punto per un Sistema sotto Test (SUT) comprendente uno stack di livelli hardware e software, provvisto di un certo numero di parametri regolabili, comprendente una base di conoscenza (KB) composta da tuple dove

   rappresenta il Sistema sotto Test (SUT) rappresenta un carico di lavoro a cui il Sistema sotto Test (SUT) ? esposto, ? un vettore di configurazione in uno spazio di configurazione di detti parametri regolabili e rappresenta indicatori di prestazione di detto Sistema sotto Test (SUT), la base di conoscenza (KB) essendo archiviata in una memoria, un modulo di caratterizzazione e previsione, e un modulo tuner, caratterizzato da ci? che detto modulo di caratterizzazione e previsione e detto modulo tuner sono disposti e fatti funzionare come in una qualsiasi delle rivendicazioni precedenti.