Analisi dei fenomeni di Software Aging nei sistemi operativi...

Università degli Studi di Napoli Federico II

SCUOLA POLITECNICA E DELLE SCIENZE DI BASE

Corso di Laurea Magistrale in Ingegneria Informatica

Tesi di laurea magistrale in Impianti di Elaborazione

Analisi dei fenomeni di Software Aging nei sistemi operativiAndroid

Candidato:

Roberto MaistoMatricola M63000553

Relatore:

Domenico Cotroneo

Correlatore:

Roberto Pietrantuono

Anno Accademico 2016–2017

Android Software Aging

Indice

Introduzione 5

1 Software Aging and Rejuvenation: stato dell’arte 9

1.1 Concetti base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Tipi di analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Tipi di sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4 Effetti ed Indicatori di Aging . . . . . . . . . . . . . . . . . . . . . . . 25

1.5 Tecniche di Rejuvenation . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2 Design of Experiments 31

2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2 Variabili di Risposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.1 User-perceived . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.2 System-related . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3 Fattori e livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4 Piano sperimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.5 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.6 Script Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3 Analisi dei risultati 51

3.1 Software Aging tra gli Android vendors . . . . . . . . . . . . . . . . . . 51

3.1.1 Analisi del Launch Time . . . . . . . . . . . . . . . . . . . . . . 51

3.1.2 Analisi dell’uso di memoria . . . . . . . . . . . . . . . . . . . . 54

2


3.2 Software aging tra versioni di Android . . . . . . . . . . . . . . . . . . 57

3.2.1 Analisi del Launch Time . . . . . . . . . . . . . . . . . . . . . . 57

3.2.2 Analisi dell’uso di memoria . . . . . . . . . . . . . . . . . . . . 60

3.3 Analisi dei processi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.3.1 Analisi della Garbage Collection . . . . . . . . . . . . . . . . . . 64

3.3.2 Analisi dei Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Conclusioni 68

Bibliography 70

3


Elenco delle figure

1.1 Analisi del trend del consumo di risorse in un sistema Unix [Garg et al.

1998b] IEEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Modello probabilistico di transizione di stato per un sistema con rejuvenation. 12

2.1 Panoramica della metodologia per l’analisi del Software Aging . . . . . 33

2.2 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1 Launch Time delle Attività per Gruppi dell’EXP39 . . . . . . . . . . . 53

3.2 Distribuzione dei trend di LT per tutti i produttori e versione fissata ad

Android 6 (EXP13∼EXP60) . . . . . . . . . . . . . . . . . . . . . . . . 54

3.3 Distribuzione dei trend di PSS: EXP13∼EXP60 . . . . . . . . . . . . . 56

3.4 Distribuzione dei trend di LT: EXP49∼EXP72 (Samsung S6 Edge) . . 59

3.5 Distribuzione dei trend di LT: EXP1∼EXP24 (Huawei P8) . . . . . . . 59

3.6 Distribuzione dei trend di LT: EXP37∼EXP48-EXP73∼EXP84(Lg Nexus) 60

3.7 Distribuzione dei trend di PSS: EXP1∼EXP24 (Huawei P8) . . . . . . 61

3.8 Distribuzione dei trend di PSS: EXP49∼EXP72 (Samsung S6 Edge) . . 62

3.9 Distribuzione dei trend di PSS: EXP37∼EXP48-EXP73∼EXP84 (Lg

Nexus) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.10 Numero di occerrenze di trend per le metriche GC: EXP1∼EXP84 . . . 65

3.11 Numero di occorrenze di trend per le metriche Task: EXP1∼EXP84 . . 66

4


Introduzione

Il software aging è un fenomeno che colpisce un gran numero di sistemi software

complessi long-running. Esso consiste nella degradazione delle prestazioni o nell’aumento

del tasso di fallimento del sistema stesso, che possono essere dovuti all’accumulo di

errori che prima o poi portano al fallimento del sistema. Questo fenomeno è stato

osservato per molto tempo ma, con la crescita del software, sia in dimensioni che in

complessità, il software aging è stato rilevato su un numero sempre maggiore di sistemi

long-running. La causa principale può essere attribuita a software bugs complessi che,

quando attivati, non causano direttamente un fallimento del software ma si manifestano

come: perdite di memoria, frammentazione di memoria, thread non terminati, file locks

non liberati, corruzione dei dati o accumulo di errori numerici che portano lentamente

il sistema a degradare le sue prestazioni e prima o poi a fallire. Spesso, questi tipi di

bug sono difficili o troppo costosi da rimuovere durante lo sviluppo e il testing. La

Software Rejuvenation è una soluzione economicamente vantaggiosa per contrastare

gli effetti del software aging. La Software Rejuvenation è un approccio proattivo

per prevenire la degradazione delle prestazioni ed i fallimenti causati dal software

aging: essa consiste in una occasionale o periodica rimozione degli effetti del software

aging (che può essere ottenuta tramite il riavvio del software o al ripristino dell’intero

ambiente di esecuzione o parte di esso), in modo da posticipare i fallimenti e ristabilire le

prestazioni. La software rejuvenation rappresenta una forma di manutenzione software

preventiva rispetto ad altre forme già esistenti, come installazione di aggiornamenti o

reingegnerizzazione del software.

Al giorno d’oggi, i dispositivi mobili rappresentano sistemi long-running e business-critical

5


a tutti gli effetti. Essi risultano complessi, ricchi di funzionalità e ampiamente personalizzati,

rendendoli sensibili al problema del software aging. I dispositivi mobili (come smartphone,

tablet e wearables) assistono le persone nelle loro attività personali, e sono oggi una

risorsa fondamentale per comunicare e usufruire di un’ampia gamma di servizi cloud,

ad esempio: social networking, servizi bancari, e-commerce, archiviazione dati e mail.

Si prevede che nel prossimo futuro possano diventare portafogli digitali e veri e propri

oggetti di riconoscimento digitali. Inoltre, vengono anche utilizzati in contesti aziendali

per accedere a dati e servizi sensibili. Di conseguenza, gli utenti si aspettano una

piattaforma affidabile, che dovrebbe essere veloce, evitando perdite di dati e crash degli

smartphone. Assicurare tali caratteristiche è una sfida per i produttori di smartphone:

nel tempo sono diventati profondamente complessi e ricchi di funzionalità, vengono

aggiornati di continuo e sono fortemente personalizzati dai produttori per differenziare

i loro prodotti dai competitors. Tale aumento di complessità porta inevitabilmente

a problemi di affidibilità.. Il sistema operativo mobile Android, che correntemente

domina nel mercato degli smartphone, è cresciuto fino a più di 6 milioni di linee di codice

Java e C++. Inoltre, recenti studi hanno mostrato che la complessità del software e

le personalizzazioni dei produttori hanno avuto un impatto negativo sull’affidabilità di

Android in termini di vulnerabilità e densità di bug. A sua volta, tutto ciò si riflette

nella bassa qualità percepita dagli utenti che colpisce la popolarità dei prodotti mobili

sul mercato.

Fin dai primi studi sul software aging e software rejuvenation, è stato dedicato molto

sforzo alla caratterizzazione del fenomeno di aging e all’individuazione della migliore

strategia di rejuvenation. Il seguente studio si pone come obiettivo principale quello di

analizzare il software aging all’interno del sistema operativo Android. A tal proposito

verrà presentata una metodologia sperimentale per analizzare tale fenomeno. Tale

metodologia usa tecniche statistiche per identificare quale fattore (ad esempio workload

e configurazione dei device) incide maggiormente sulla degradazione delle prestazioni

e sul consumo delle risorse. Inoltre, analizza la correlazione tra le metriche di software

aging e quelle di consumo delle risorse, per identificare quali sottosistemi di Android

sono maggiormente colpiti da tale fenomeno.

6


In particolare si cercherà di rispondere alle seguenti domande:

1. Il sistema operativo Android è affetto dal fenomeno del software aging?Il software

aging influisce sulla responsività e/o sul consumo di risorse? Fino a che punto?

La prima domanda è la base per esplorare i problemi del software aging in Android e per

motivare ulteriori ricerche sulla mitigazione di questo problema attraverso rejuvenation

o un testing migliore. Per rispondere a questa domanda vengono presi in considerazione

un’ampia gamma di condizioni sperimentali in termini di workload e configurazioni dei

device che potrebbero influenzare la portata degli effetti del software aging. Inoltre,

viene misurata la risposta percepita dall’utente nel tempo per analizzare se il software

aging ha un impatto sull’esperienza utente.

2. Il software aging è diffuso anche su diversi dispositivi provenienti da differenti

produttori?

Per quanto detto finora, i diversi produttori Android introducono profonde personalizzazioni

nei loro prodotti. Quindi, la versione open-source di Android (AOSP) viene estesa

con nuove interfacce grafiche e servizi per migliorare l’esperienza utente. Queste

personalizzazioni possono introdurre ulteriori difetti software, e aggravare i problemi

di software aging.

3. Il software aging è diffuso anche su differenti versioni del sistema operativo

Android?

Il sistema operativo Android ha subito numerose modifiche architetturali nel corso degli

ultimi anni. Pertanto, si vuole investigare se l’evoluzione di Android ha avuto influenze

sui problemi di software aging.

4. Dove originano i problemi di software aging che colpiscono il sistema operativo

Android?

Per meglio comprendere le cause del software aging, vengono analizzate anche le metriche

di consumo delle risorse sia a livello dei processi che dei task, correlandole con i dati

7


relativi alla risposta percepita dall’utente. Tale informazione è utile per identificare

quale tra i numerosi componenti di Android sia quello più colpito dal software aging, per

mettere in atto eventuali meccanismi di prevenzione o mitigazione come la rejuvenation.

Panoramica dei capitoli

Nel primo capitolo verranno discusse le principali tecniche di caratterizzazione del

software aging allo stato dell’arte; nel secondo capitolo verranno descritte tutte le

scelte effettuate relative al design of experiments; nel terzo capitolo verranno effettuate

le analisi dei dati ottenute dagli esperimenti.

8


Capitolo 1

Software Aging and Rejuvenation:

stato dell’arte

Lo scopo del seguente capitolo è quello di fornire una visione globale circa lo stato

dell’arte della Software Aging and Rejuvenation (SAR). In particolare, verranno descritti

gli approcci che vengono usati per prevedere il fenomeno dell’aging e per pianificare la

rejuvenation, i tipi di sistemi e sintomi di aging che sono stati studiati e le tecniche che

sono state proposte per la rejuvenation di sistemi software complessi.

1.1 Concetti base

Il fenomeno del Software Aging consiste, in generale, nell’aumento del tasso di fallimento

e/o nella degradazione delle prestazioni di un sistema software long-running. A sua

volta, ciò è dovuto all’attivazione e propagazione dei cosiddetti Aging-Related Bugs

(ARBs), una particolare classe di software fault che manifestano i loro effetti solo dopo

un lungo periodo di esecuzione. L’attivazione di questi bug non causa immediatamente

il fallimento del sistema: considerando la catena concettuale fault-error-failure [62], la

peculiarità degli ARBs è che la loro attivazione/propagazione dipende dalla durata di

tempo che il sistema sta eseguendo, e, portando un accumulo di errori, causano un

transito graduale del sistema da uno stato corretto ad uno stato soggetto al fallimento.

Dopo che è trascorso un certo tempo di esecuzione, o dopo che si è accumulata una

9


certa quantità di errori, gli ARBs portano all’ aging-related failure (ad esempio,

fallisce una operazione che alloca memoria, facendo crashare il processo). Tipicamente,

l’accumulo di errori deriva da una cattiva gestione della memoria che porta all’esaurimento

delle risorse, come memory leaks, thread non terminati, e file locks non liberati:

in questi casi, ci si riferisce al tempo previsto all’aging-related failure come time

to (resource) exhaustion (TTE). Inoltre, l’accumulo di errori è influenzato dalla

quantità e tipo di lavoro che il sistema esegue, denominato workload.

Gli Aging effects sono il risultato dell’accumulo di errori, in termini di perdite di

risorse o stato corrotto; questi effetti possono essere rilevati per mezzo degli aging

indicators, ovvero, variabili di sistema che possono essere direttamente misurate e che

possono essere correlate al fenomeno del software aging. Esempi di aging indicators

sono le informazioni circa l’uso di risorse di un sistema operativo, come memoria fisica

libera, spazio di swap utilizzato e dimensioni delle tabelle di file e processi. In [Garg et

al 1998b], è stato eseguito un esperimento monitorando l’uso di risorse del SO in una

LAN di workstation UNIX usando un tool di monitoraggio distribuito SNMP, in modo

da identificare i trend di software aging. La figura 1.1 mostra il consumo di memoria e

le tabelle di file su un arco di 53 giorni. Siccome il fenomeno di aging può non essere

evidente soltanto da una ispezione visuale dei dati, vengono spesso utilizzate tecniche

di trend detection per rilevare l’inizio del software aging. In figura 1.1, viene rilevato

un trend tramite lo smoothing dei dati con una regressione locale pesata robusta, che

fornisce indicazioni visive circa la graduale decrescita di memoria libera e l’incremento

delle tabelle dei file. Per effettuare affermazioni decisive circa la presenza o l’assenza

di trend di software aging con una confidenza statistica, è richiesto l’uso di tecniche

statistiche: esempi di tecniche che vengono spesso utilizzate sono il seasonal Kendall

e il Mann-Kendall test for trend, per testare l’ipotesi che esiste un trend crescente o

decrescente nei dati osservati, e la Sen’s procedure per il calcolo dello slope dei trend.

Quindi, è possibile calcolare il TTE atteso di una data risorsa utilizzando lo slope

stimato.

Il consumo di risorse o altri effetti di aging dovuti ad ARBs si possono manifestare

in software applicativo, nelle librerie di cui l’applicativo fa uso oppure nel suo ambiente

10


(a) Free memory (b) File table size

Figura 1.1: Analisi del trend del consumo di risorse in un sistema Unix [Garg et al.

1998b] IEEE.

di esecuzione (ad esempio, il sistema operativo). Ad ogni modo, riparare tali bug

non è sempre fattibile; per esempio, essi potrebbero trovarsi in software di terze parti,

o codice riusato, per cui gli sviluppatori non hanno il codice sorgente oppure non

sono molto esperti sui meccanismi interni; inoltre, potrebbe essere davvero difficoltoso

identificare questi bug in sistemi software complessi. La Software Rejuvenation è un

approccio conveniente economicamente per rimuovere gli effetti di aging ed evitare gli

aging-related failure, perchè non necessita di sapere dove siano collocati gli ARBs, o

della loro stessa esistenza. La Software rejuvenation viene definita in [Huang et al.1995]

come il riavvio preventivo di applicazioni continuamente in esecuzione per prevenire

fallimenti in futuro. Siccome un’applicazione può non essere disponibile durante il

riavvio, la rejuvenation può aumentare il downtime del sistema e quindi causare dei

costi (ad esempio, costi dovuti alla perdita di attività). Tuttavia, questi costi possono

essere minimizzati pianificando la rejuvenation durante i tempi di maggiore inattività

dell’applicazione. Al contrario, è probabile che i costi di downtime saranno alti se la

rejuvenation non è pianificata, così come accade durante un fallimento. La Rejuvenation

può evitare, o almeno posporre, gli aging-related failure, perciò può ridurre il downtime

complessivo ed i relativi costi.

Per questa ragione, il problema più importante nell’ambito della SAR è pianificare

quando effettuare la rejuvenation durante l’esecuzione (rejuvenation schedule) in

modo da migliorare l’availability e ridurre i costi. Un esempio è rappresentato dal

11


semplice modello basato su catene di Markov a tempo continuo (CTMC) introdotto

in [Huang et al. 1995] per analizzare la software rejuvenation (figura 1.2). In questo

modello, dopo il suo avvio, l’applicazione si trova nello stato robusto S0, in cui la

probabilità di un aging-related failure è trascurabile poichè non è trascorso molto

tempo. Dopo un certo tempo (ad un tasso r2 più basso degli altri), l’applicazione

andrà in uno stato failure-probable SP (ad esempio, alcune risorse si sono consumate

e sono vicine all’esaurimento); in questo stato, l’applicazione può fallire con tasso λ

e passare allo stato "fallito" SF per poi essere successivamente riparato ad un tasso

r1. Se il sistema effettua la rejuvenation, passerà dallo stato SP allo stato SR ad un

tasso r4 e poi di nuovo allo stato robusto S0 con tasso r3. Questo modello permette

di calcolare il downtime atteso (sia nel caso pianificato che non) ed i suoi costi; a sua

volta, permette di analizzare quando, e sotto quali condizioni, la software rejuvenation

è benefica per l’availability. Ad esempio, se il costo di rejuvenation è basso ed il tasso

di fallimento è alto, la rejuvenation dovrebbe essere effettuata non appena il sistema

passa nello stato failure-probable.

Figura 1.2: Modello probabilistico di transizione di stato per un sistema con

rejuvenation.

Un semplice modo per effettuare la software rejuvenation è di riavviare l’applicazione.

Il riavvio può coinvolgere l’accodamento temporaneo di messaggi in ingresso, ripulire le

strutture dati di memoria, rigenerare i processi nel loro stato iniziale o nel loro ultimo

stato salvato. Inoltre, la rejuvenation può essere eseguita a diversi livelli, che vanno

dal riavviare un singolo componente al riavviare l’intero nodo su cui l’applicazione

12


è in esecuzione. La definizione di tecniche di rejuvenation (come effettuare la

rejuvenation), capaci di ridurre la probabilità di aging failure e tenere bassi i costi

causati dal downtime, è un altro importante problema della SAR.

13


1.2 Tipi di analisi

Questa sezione tratta i diversi tipi di analisi in letteratura circa la Software Aging e

Rejuvenation.

Analisi Model-based. Il software aging è stato analizzato a partire dalle osservazioni

empiriche che diversi sistemi long-running sono affetti da failure transienti e hanno

bisogno, di tanto in tanto, di essere riavviati. Per quanto detto finora, c’è un’alta

incidenza di bug che si manifesta come perdite di memoria, puntatori danneggiati, file

lock non liberati ed accumulo di errori, che portano lentamente il sistema a degradare

le sue prestazioni e prima o poi a fallire. Pertanto, da molto tempo sono state adottate

alcune forme di software rejuvenation per contrastare tali effetti. Questo approccio

ha fatto sorgere il problema di trovare una pianificazione ottimale e vantaggiosa delle

azioni di rejuvenation. [Huang et al. 1995] tentarono di modellare il fenomeno in modo

da fornire una vista astratta del problema ed un trattamento matematico. Questo

ha permesso ai ricercatori di far fronte al software aging formulando analiticamente il

fenomeno, concentrando l’attenzione su come pianificare in maniera ottimale le azioni

di rejuvenation.

I modelli analitici furono impiegati per la prima volta per dimostrare che la software

rejuvenation può ridurre i costi del downtime di un sistema e minimizzare i tempi di

completamento di un’applicazione in presenza di software aging. Gli studi Model-based

possono essere distinti in base al tipo di processo stocastico utilizzato per modellare il

fenomeno. Ce ne sono di diversi tipi, spesso markoviani. Tra questi:

• Processi markoviani e processi semi-markoviani : questo tipo di processi con le

loro varianti sono la base per l’analisi model-based nella SAR. Il primo lavoro sul

software aging da Huang et al. è stato quello di modellare il fenomeno usando

una catena di Markov a tempo continuo (CMTC) a quattro stati, che ancora oggi

è rappresenta il modello base del fenomeno (come discusso nella sezione 1.1).

Questo modello base è stato esteso in molti modi, usando processi markoviani e

semi-markoviani. Alcuni esempi sono [Garg et al. 1998a] in cui viene utilizzata

una CTMC non omogenea (il tempo di soggiorno in ciascuno stato non è distribuito

14


esponenzialmente) e [Bao et al. 2005] dove vengono impiegati processi semi-markoviani

(i tassi di transizione da uno stato all’altro dipendono, oltre che dallo stato

corrente, anche dal tempo speso in esso) per modellare una gestione dei fault

proattiva.

Le catene di Markov sono ancora ampiamente utilizzate nella loro forma più

semplice, tipicamente per: a) analizzare sistemi complessi, con più strategie di

rejuvenation, b) analizzare l’aging in nuovi contesti, come sistemi che usano la

virtualizzazione [Myint and Thein 2010], c) descrivere manifestazioni di fallimenti

più complessi (invece di modellare un solo stato di fallimento che causa la totale

indisponibilità del servizio, vengono considerati più gradi di fallimento per modellare

la decrescita del tasso di servizio, ovvero, la performance degradation).

• Altri modelli basati su Markov : sebbene la maggior parte degli studi adottino

processi markoviani e semi-markoviani, altri esplorano diversi tipi di modellazione.

Ad esempio, in [Garg et al 1995; 1998a; Wang et al 2007] sono stati usati processi

markoviani rigenerativi (MRGP), insieme alle Stochastic Petri Nets (SPN), in

modo da costruire un modello semplice ma generale per stimare la pianificazione

ottimale della rejuvenation in un sistema software. I processi markoviani rigenerativi

sono una generalizzazione dei processi markoviani e semi-markoviani che possono

catturare il comportamento di sistemi reali con distribuzioni sia deterministiche

che esponenziali. Quindi, mentre i primi modelli considerano solo tassi di rejuvenation

distribuiti esponenzialmente nello stato failure-probable, le MRGP affrontano

anche il caso di un intervallo deterministico di rejuvenation, partendo dallo

stato robusto. Gli autori mostrano gli effetti di un intervallo di rejuvenation

deterministico in termini di downtime e costo.

Il problema di trovare la pianificazione ottimale della rejuvenation è stato formulato

anche come processo decisionale di Markov (MDP) dove: il tempo è discretizzato

e rappresenta una dimensione dello stato descritto, la decisione in ciascuno stato

determina se il sistema dovrebbe eseguire la rejuvenation o meno, e la soluzione

consiste nel trovare la pianificazione ottimale per minimizzare la funzione di costo.

15


• Reti di Petri : le reti di Petri e le loro numerose varianti sono formalismi strettamente

correlati ai modelli di Markov, ma sono più compatte e più facili da definire.

Questi modelli permettono di esprimere più facilmente le metriche di performability

con più livelli di performance, e sono particolarmente utili per esprimere metriche

in sistemi più complessi, come sistemi con più nodi.

Ad esempio, le Deterministic and Stochastic Petri Nets (DSPN) furono impiegate

in [Wang et al. 2007], per costruire un modello per analizzare la performability

di un sistema a cluster sottoposto a workload variabile. Similmente, le Stochastic

Reward Nets (SRN) furono usate in [Vaidyanathan et al. 2001] per modellare un

sistema a cluster.

Gli studi basati su modelli analizzano modelli astratti, facendo molte assunzioni

semplificative sul sistema, ad esempio riguardo le distribuzioni stocastiche che lo caratterizzano.

Rispetto all’approccio basato su misure, questi modelli possono essere applicati ad una

grande varietà di sistemi, perchè possono fornire risultati più generali e possono essere

portabili tra diversi sistemi. Tuttavia, la rejuvenation software model-based potrebbe

essere meno efficace rispetto agli approcci basati su misure, siccome potrebbe trascurare

alcune peculiarità di uno specifico sistema e potrebbe non essere in grado di adattarsi

a condizioni differenti da quelle attese. In ogni caso, gli approcci model-based possono

basarsi su dati reali, che potrebbero essere ottenuti da analisi basate su misure, al fine

di tarare i parametri del modello.

Analisi basate su misure. In letteratura è stata dedicata molta attenzione anche

all’analisi empirica del Software Aging, basata su misure di sistemi reali. Siccome

tale fenomeno si manifesta sotto forma di degradazioni delle prestazioni e/o consumo

di risorse, i ricercatori hanno concentrato la loro attenzione su approcci per sfruttare

misure empiriche, in modo da identificare se il sistema si trova in uno stato failure-prone,

per ritardare il time-to-aging-failure e pianificare la Software Rejuvenation. Gli studi

basati su misure forniscono anche informazioni dettagliate circa il fenomeno dell’aging

in sistemi reali, che sono utili per comprendere meglio la natura e l’estensione del

Software Aging ed aumentare la consapevolezza su questa tematica.

16


L’idea di base degli approcci di rejuvenation basati su misure è quella di monitorare

direttamente le variabili del sistema, dette indicatori di aging, che possono indicare

l’inizio del software aging e predire l’occorrenza di aging failure analizzando statisticamente

i dati acquisiti a runtime. Ciò fornirà dati circa il tempo migliore per eseguire la

rejuvenation. Sono stati proposti diversi approcci per effettuare la predizione, che

possono essere raggruppati in:

• Time Series Analysis. Un approccio ampiamente utilizzato è quello di analizzare

le serie temporali delle risorse monitorate. Le serie temporali sono tipicamente

analizzate prima utilizzando test di trend per accettare o rigettare l’ipotesi che

non ci sia trend nei dati (ad esempio, Mann-Kendall, t-student, Seasonal Kendall

tests) e poi usando tecniche per stimare il trend e possibili stagionalità nei dati

(ad esempio, regressione lineare multipla, smoothing, procedura di stima Sen’s

slope, modelli autoregressivi).

Una delle prime analisi basate su misure è riportata in [Garg et al. 1998b]: in

questo studio sono stati monitorati un insieme di 9 workstation Unix per un

arco di 53 giorni, utilizzando uno strumento di monitoraggio basato su SNMP.

Durante il periodo di osservazione, il 33% delle interruzioni riportate era causata

da un esaurimento delle risorse, sottolineando che il Software Aging è una fonte

di fallimenti non trascurabile in un sistema.

In [Li et al. 2002; Grottke et al. 2006], gli autori hanno analizzato la degradazione

di prestazioni anche nel Web Server Apache, campionando il tempo di risposta

del web server a richieste HTTP predefinite a intervalli fissi.

In [Grottke et al. 2006] sono state considerate anche analisi di pattern stagionali,

in cui, i trend sono analizzati anche in presenza di stagionalità nei dati.

In [Li et al. 2002] sono stati usati modelli di serie temporali ARMA/ARX sul

Web Server Apache, in modo da stimare l’esaurimento delle risorse. Rispetto

ai modelli di regressione lineare e regressione lineare estesa, il modello ARX ha

un overhead iniziale più alto, ma una volta stabilito, può essere usato per la

previsione per un lungo periodo senza dover stimare nuovamente i parametri del

17


modello.

Le analisi delle serie temporali sono state adottate anche per studiare la relazione

tra il fenomeno del Software Aging e il workload in sistemi complessi, compresi

il codice del Kernel Linux [Cotroneo et al. 2010], e la Java Virtual Machine

[Cotroneo et al. 2011b]. In entrambi i casi, l’analisi dei parametri del workload

viene utilizzata per fornire indicazioni sulle possibili cause del Software Aging,

evidenziando i sottosistemi i cui parametri sono correlati ai trend di aging osservati.

In questo lavoro sono state adottate l’analisi delle componenti principali (PCA)

seguita dalla regressione lineare multipla, in modo da rimuovere le correlazioni di

primo ordine tra i predittori per poi fornire una stima lineare degli aging trends,

tramite la regressione, riducendo il problema della multicollinearità.

In [Magalhaes and Silva 2010] sono stati usati modelli ARIMA (Autoregressive

Integrated Moving Average) e Holt-Winters (Triple-exponential Smoothing), dove

gli autori hanno sviluppato un framework, indirizzato ad applicazioni web e

component-based, per la rilevazione di anomalie di performance causate dall’aging.

In particolare, il framework monitora parametri applicativi e di sistema, che

vengono utilizzati per determinare la correlazione tra il tempo di risposta dell’applicazione

e il workload in input, a sua volta utilizzata per addestrare gli algoritmi di

machine learning. A tempo di esecuzione, i parametri acquisiti dal monitoraggio

vengono stimati dagli algoritmi ARMA e Holt-Winters, e le stime vengono classificate

dagli algoritmi di ML già addestrati, per determinare se l’applicazione può incorrere

in anomalie di prestazioni.

In [Araujo et al 2011b] vengono utilizzati 4 differenti modelli di serie temporali, in

modo da pianificare adeguatamente la software rejuvenation. I modelli utilizzati

sono: il modello lineare, il modello quadratico, il modello a crescita esponenziale

ed il modello della logistica di Pearl-Reed. Questi, sono stati adottati per predire

il trend del consumo di memoria sul framework di cloud computing Eucalyptus.

In [Hoffmann et al. 2007] sono stati confrontati modelli nonlineari multivariati

(macchine a vettori di supporto, funzioni di base universali e raidiali) e modelli

lineari multivariati). I primi modelli hanno mostrato una performance migliore

18


rispetto ai modelli lineari nei casi di benchmarking.

In [Jia et al. 2008] il fenomeno di aging viene studiato in Apache costruendo un

modello dinamico per descrivere il processo di software aging seguendo il metodo

dell’inversione nonlineare dinamica. È stato mostrato che il processo di software

aging è nonlineare e caotico.

• Machine Learning. Gli approcci di machine learning sono una forma più sofisticata

di analisi dati, che adotta algoritmi del campo dell’Intelligenza Artificiale (ad

esempio classificatori e regressori) per identificare i trend e classificare gli stati del

sistema come robusti o failure-prone. In [Cassidy et al. 2002] gli autori adottano

metodi di riconoscimento di pattern per predire il Software Aging in server OLTP.

Quest’approccio applica una regressione nonlineare e nonparametrica ad un gran

numero di variabili di sistema, ed analizza l’errore residuo tra i valori predetti e

quelli reali usando un sequential probability ratio test, in modo da predire l’inizio

degli effetti del Software Aging. I risultati hanno mostrato che questi due metodi

permettono di rilevare deviazioni significative dall’andamento "standard" con un

anticipo di due ore.

In [Alonso et al. 2011a] viene esplorato un’altra applicazione di machine learning

per predire i fallimenti dovuti al Software Aging nel contesto di un sistema

J2EE three-tier. È stato proposto un approccio basato sul machine learning per

costruire automaticamente alberi di regressione che correlano diverse variabili

di sistema (ad esempio numero di connessioni e throughput) con i trend di

aging, basandosi sull’osservazione che i trend di Software Aging possono essere

approssimati usando modelli lineari a tratti. Questi modelli sono stati addestrati

utilizzando dati acquisiti in esperimenti preliminari, e furono usati per predire il

TTE delle risorse di sistema sotto condizioni differenti da quelle osservate durante

la fase di addestramento.

19


• Approcci Threshold-based. A differenza dei casi precedenti, questi tipi di approcci

definiscono delle soglie per alcuni indicatori di aging e la rejuvenation viene

attivata non appena gli indicatori monitorati superano tale soglia. Ad esempio,

gli indicatori possono riferirsi al consumo di risorse. La difficoltà maggiore sta

nell’identificare i migliori indicatori e le giuste soglie, che siano in grado, allo

stesso tempo, di prevenire fallimenti ed inutili azioni di rejuvenation.

In [Silva et al. 2009] vengono adottate soglie sugli indicatori del tempo di risposta

medio e qualità del servizio.

Nel lavoro [Silva et al. 2006] viene presentata un analisi di software aging in un

server basato su SOAP, in cui è stato preliminarmente condotto uno studio di

dependability benchmarking per valutare alcune implementazioni SOAP-RPC,

concentrandosi in particolare su Apache Axis, dove è stata rilevata la presenza

di aging monitorandone i parametri.

In [Matias Jr. and Filho 2006] viene presentata una valutazione degli effetti di

aging in Apache Web Server, basandosi su un esperimento controllato. In questo

lavoro vengono osservate la memoria consumata da Apache e tre parametri di

workload controllabili: la dimensione delle pagine, il tipo di pagina (statica o

dinamica) e la frequenza di richiesta; come indicatore di aging è stato usato l’uso

della memoria virtuale.

In [Avritzer and Weyuker 2004] vengono monitorati threads e memoria mentre le

soglie vengono impostate sulla garbage collection.

In [Araujo et al. 2011b] viene combinato sia l’approccio basato su soglie (con

una soglia sull’utilizzo di memoria) con l’analisi delle serie temporali. È stata

implementata una strategia di rejuvenation nell’infrastruttura di calcolo cloud

Eucalyptus, basata su soglie multiple e modelli di serie temporali. I modelli

utilizzati sono: lineare, quadratico, growth curve, S-curve trend.

Gli studi basati su misure prevedono il software aging basandosi su misure dirette

(ad esempio basate su serie temporali) e forniscono dati empirici circa il fenomeno.

Il vantaggio di questo approccio è che la previsione di software aging può adattarsi

20


alle condizioni correnti del sistema (profilo operazionale che potrebbe non essere stato

previsto precedentemente) e può essere predetta accuratamente. Tuttavia, questo

tipo di approccio non è facilmente generalizzabile, siccome sfrutta alcune peculiarità

relazionate alla natura del sistema considerato.

Studi ibridi. Con questo metodo si cerca di combinare i benefici degli approcci basati

su misure e su modelli, descrivendo il fenomeno analiticamente, spesso con catene di

Markov, e determinando i parametri del modello attraverso le misure, ovvero i dati

osservati. Malgrado l’importanza pratica degli approcci ibridi, non ci sono molti studi

che li hanno adottati. Alcuni esempi sono [Vaidyanathan and Trivedi 1999, 2005] in cui

sono stati presentati i risultati di un’analisi condotta sullo stesso insieme di workstation

Unix usate in [Garg et al. 1998b]. Mentre l’ultimo considerava solo la rilevazione del

trend delle serie temporali e la stima dell’esaurimento delle risorse senza considerare il

workload, questo studio considerò anche il workload e costruì un modello per stimare

i tempi di esaurimento delle risorse. Inoltre, sono stati presi in considerazione alcuni

parametri per includere il workload nell’analisi, come il numero di context switch della

CPU e il numero di invocazioni di system call. Furono identificati diversi stati del

workload tramite un’analisi dei cluster e fu costruito un modello dello spazio di stato,

determinando le distribuzioni dei tempi di soggiorno; successivamente, fu definita una

funzione di reward per il modello basandosi sul tasso di esaurimento delle risorse per

ciascuno stato del workload. Risolvendo il modello, gli autori ottennero i trend di

esaurimento delle risorse ed il TTE per ogni risorsa considerata in ciascuno stato del

workload. Tale metodologia permette di eseguire una caratterizzazione workload-driven

del fenomeno di aging.

21


1.3 Tipi di sistemi

Il Software Aging ha mostrato di influenzare molti tipi di sistemi software long-running,

che vanno dai sistemi business-oriented a quelli altamente critici. È importante capire

su quale classe di sistemi i ricercatori hanno concentrato le loro attenzioni nel studiare

il fenomeno di aging. A differenti domini corrispondono differenti pratiche di sviluppo,

cicli, tecniche, e metodologie, che possono incidere sulla probabilità del sistema finale

di soffrire del problema di aging.

Analizzando i paper si può effettuare una classificazione a seconda dello scenario in cui

un sistema viene adottato: safety-critical, non-safety-critical, non specificati.

La prima classe indica sistemi che vengono impiegati in scenari che sono critici dal

punto di vista della safety, ovvero, sistemi il cui malfunzionamento può causare seri

danni o perdite di vite umane, come sistemi militari o spaziali. La seconda include

applicazioni di business e mission-critical, come Web Server o DBMS. L’ultima classe

si riferisce a paper che non presentano una sperimentazione su sistemi reali, ma usano

simulazioni o esempi numerici per dimostrare la validità dei loro risultati. I paper sui

sistemi non-safety-critical costituiscono la maggior parte della letteratura a differenza

dei safety-critical. Questo perchè questi ultimi sono progettati e testati molto meglio.

Nonostante vengano progettati rispettando stringenti requisiti di dependability e vengono

testati estensivamente, una piccola parte dei paper ha comunque considerato il problema

dell’aging anche in questi sistemi. Da un lato, questo conferma che i problemi di aging

sono difficili da rilevare durante la fase di sviluppo: sebbene i sistemi safety-critical

siano tipicamente sviluppati tramite delle pratiche di sviluppo ben definite e sono

sottoposti ad estensive attività di testing, l’aging si può comunque manifestare durante

l’esecuzione. Infatti, essendo una sottoclasse di Mandelbugs, gli ARBs sono difficili da

riprodurre: anche dopo essersi attivati, la loro manifestazione impiega troppo tempo

per essere evidente e rende i tempi di testing insufficienti per rilevare il problema.

D’altra parte, ciò suggerisce che il software aging dovrebbe essere preso sistematicamente

in considerazione dagli sviluppatori di sistemi critici, sia nelle prime fasi di sviluppo

che in fase esecutiva.

22


Una grande varietà di sistemi ha dimostrato di soffrire di aging, tra cui: applicazioni

web, webserver, sistemi operativi, DBMS, cloud computing, ambienti di virtualizzazione,

middleware ed applicazioni server. Tra questi, le applicazioni web e i webserver rappresentano

la maggioranza. Infatti, questo tipo di applicazioni è ampiamente diffuso nel mercato e

sono usate da ampie comunità in internet: ciò giustifica il motivo per cui vengono spesso

scelti come casi di studio. Esempi di applicazioni web usate per questo tipo di studi

sono web services ed applicazioni service-oriented, applicazioni server, applicazioni di

e-commerce.

La classe dei web server, che è strettamente correlata alla precedente, rappresenta

una parte rilevante. Apache Web Server è una delle applicazioni più studiate. Sono

state effettuate diverse analisi basate su misure di questo sistema, specialmente da

ricercatori più vicini alla dependability e alla fault tolerance piuttosto che all’ingegneria

del software. Alcuni degli studi più conosciuti sono: [Li et al. 2002], [Matias Jr. and

Filho 2006], [Grottke et al. 2006], in cui vengono raccolti misure dall’esecuzione di

Apache riguardo l’uso delle risorse come, consumo di memoria, area swap, uso della

cache, tempo di risposta, ed utilizzano tecniche statistiche per predire l’aging.

Anche le applicazioni server rappresentano una parte significativa. Alcuni degli studi

più rilevanti sono in [Castelli et al. 2001], dove viene valutato l’impatto di differenti

politiche di rejuvenation (basate su predizione e sul tempo) sull’availability, per mezzo

di modelli analitici basati su SRN nei server IBM Director for xSeries; in [Okamura

et al. 2003], in cui l’autore calcola analiticamente, in un sistema Transaction-Based

Multi-Server, la politica di rejuvenation ottimale, basandosi su alcune misure di dependability

del sistema, comparando la configurazione multi-server con quella single-server; in

[Oppenheimer et al. 2003], vengono prima analizzate le cause dei fallimenti usando

dati da tre servizi Internet a larga scala (come errori operatore, errori di configurazione,

fallimenti in custom front-end software) e successivamente vengono confrontate diverse

tecniche di manutanzione preventiva, osservando che, migliorando gli strumenti di

manutenzione e i sistemi usati dallo staff di servizio, ridurrebbe il tempo per diagnosticare

e riparare problemi.

La categoria di benchmarking è anch’essa rilevante; la maggior parte dei paper in

23


questa categoria è comunque relativa ad analisi statiche/dinamiche per il rilevamento

di memory leak, che adotta suite di benchmarking per testare i risultati ([Novark et al.

2009]; [Jung and Yi 2008]).

Un’altra classe di sistemi è rappresentata dal cloud computing, un’area relativamente

giovane. In questi studi, i ricercatori spesso analizzano numerose politiche di rejuvenation

basate su virtual machine e/o reboot/rejuvenation di virtual machine monitor. Tali

strategie vengono successivamente valutate sia con approcci model-based ([Machida et

al. 2011]) che measurement-based ([Kourai and Chiba 2007]; [Araujo et al. 2011b]).

La disponibilità del software cloud di sperimentare le strategie con costi ridotti favorisce

l’analisi di aging sul cloud. Un esempio rilevante è rappresentato dagli studi su Eucalyptus,

un framework per cloud computing ([Araujo et al. 2011a,2011b]; [Matos et al. 2011]).

I sistemi di telecomunicazioni sono tra le prime classi di sistemi ad essere considerati

per l’analisi di aging. I primi esempi di software aging e rejuvenation su sistemi di

telecomunicazioni provengono dalla AT&T Labs, come quelli forniti in [Huang et al.

1995]. In quegli anni, altri studi hanno considerato i sistemi di telecomunicazione nei

loro esperimenti: in [Huang et al. 1996], sono studiate le capacità di fault tolerance di

diversi prodotti e servizi di comunicazione arricchiti con componenti di rejuvenation: in

[Balakrishnan et al. 1997], il software aging è analizzato in applicazioni di fatturazione

delle telecomunicazioni, così come nell’annesso software di switching. Negli anni seguenti,

altri paper hanno trattato applicazioni di telecomunicazioni, come paper in [Liu et al.

2002, 2005] dove la software rejuvenation è proposta come una tecnica di manutenzione

proattiva installata in un cluster CTMS (Cable Modem Termination System), ed il

lavoro in [Okamura et al. 2005], in cui gli autori valutano le performance di dependability

di un sistema di rete con software rejuvenation.

Nelle restanti classi è bene menzionare alcuni aspetti: nella classe degli OS, la fetta più

grande è rappresentata da lavori su sistemi Unix e Linux ([Vaidyanathan and Trivedi

1999]; [Yoshimura et al. 2011]; [Cotroneo et al. 2010]), Solaris ([Ni et al. 2008]),

Windows NT ([Robb 2000]) e Android ([Park and Choi 2012]). I lavori nella categoria

DNS Server sono principalmente mirati a prevenire fallimenti security-related tramite

rejuvenation (come in [Huang et al. 2006]) ed a rilevare vulerabilità di sicurezza che

24


causano aging ([Antunes 2008]). Infine, la categoria di sistemi Space, che è una delle

più rilevanti e studiate nella classe dei sistemi critici: alcuni esempi sono [Tai et al.

1999], che descrive il sistema X2000 della NASA per la missione Pluto-Kuiper Express

lunga 15 anni.

1.4 Effetti ed Indicatori di Aging

L’analisi degli effetti di aging (ad esempio stati erronei causati dall’aging) e degli

indicatori di aging mostra come il Software Aging si è manifestato nei sistemi software

complessi. Gli indicatori di aging sono un’importante area di studio, siccome sono di

valido aiuto per rilevare quando il sistema è incline agli aging-failures, monitorandoli

durante l’esecuzione. Gli indicatori di aging possono essere indicatori dell’utilizzo di

risorse e indicatori di performance. Di seguito viene riportata una lista di classi di

indicatori di aging:

Consumo di memoria: evidenze empiriche hanno mostrato che la memoria libera

esibisce un TTE minore tra le varie risorse di sistema [Garg et al. 1998b], e che

la cattiva gestione della memoria è tra le cause primarie di fallimenti [Sullivan and

Chillarege 1991]. Perciò, molti studi sulla SAR analizzano il fenomeno del software

aging che interessa la memoria libera, misurando la quantità di memoria fisica libera

e lo spazio di swap [Grottke et al. 2006; Vaidyanathan and Trivedi 1999] e diversi

approcci basati su misure applicano serie temporali e modelli statistici a tali variabili.

Degradazione delle prestazioni. Gli studi sulla SAR hanno spesso riportato una

degradazione delle prestazioni in sistemi software colpiti dal Software Aging. Una delle

cause della degradazione delle prestazioni è il consumo delle risorse di sistema: ad

esempio, il consumo di memoria fisica aumenta il tempo richiesto dalle procedure di

allocazione di memoria e garbage collection, siccome la loro complessità computazionale

è funzione della quantità di memoria allocata [Carozza et al. 2010; Ferreira et al. 2011;

Cotroneo et al. 2011b]. In applicazioni web [Silva et al. 2006], webserver [Grottke et

al. 2006; Matias Jr. 2006] ed applicazioni basate su CORBA [Carrozza et al. 2010]

sono stati riportati un aumento nel tempo di risposta alle richieste ed una diminuzione

25


del throughput. In presenza di questo tipo di fenomeni, la software rejuvenation può

essere attivata quando la qualità del servizio (ad esempio in termini di response time

e throughput) è al di sotto di una certa soglia.

Altri consumi di risorse. Il software aging può coinvolgere diversi tipi di risorse.

Oltre alle risorse di memoria (memoria fisica, memoria virtuale, memoria cache, area

swap...) ci sono:

• risorse relative al filesystem, come stream descriptors e file handles [Weimer 2006;

Zhang et al. 2011; Garg et al. 1998b];

• storage, il cui spazio può essere consumato da una cattiva gestione [Bobbio et al.

2001];

• risorse relative alle reti, come i descrittori di socket [Weimer 2006];

• risorse relative alla concorrenza, come locks, thead e processi [Zhang et al. 2011;

Garg et al. 1998b];

• risorse application-specific, come DBMS shared pool latches [Cassidy et al. 2002].

In diversi paper, l’approccio proposto non si vincola ad una specifica risorsa, ma si

concentra sul rilevare uno scorretto uso delle API e degli handler di eccezione che

possono causare una perdita di memoria. Ad esempio, il lavoro in [Zhang et al.

2011] presenta un approccio che dinamicamente cerca dei pattern nell’uso delle risorse

monitorando le chiamate alle API e fornisce una valutazione sperimentale di programmi

open source basati su Java I/O e concorrenza delle API. Una perdita di risorse frequente

nei programmi Java è rappresentata da socket e file handles, a causa di gestori delle

eccezioni scorretti che non liberano queste risorse [Weimer 2006; Zhang et al. 2011].

Alcuni paper analizzano un insieme più ampio di risorse. In [Garg et al. 1998b], veniva

monitorato un insieme di workstation Unix in rete in modo da identificare trend di

aging nel consumo di diverse risorse (memoria virtuale, OS kernel, filesystem, disco, e

rete) e fu notato un trend statisticamente significativo nella table size dei processi e

nella table size dei file.

26


Oltre a questi effetti di aging menzionati fin’ora, ne esistono altri tipi che sono stati

studiati in lavori recenti. Uno dei campi in cui la software rejuvenation è stata studiata

di recente è relativo agli attacchi di sicurezza, ovvero, tentativi di utenti maliziosi di

accedere a risorse non autorizzate o di rendere il sistema indisponibile. Infatti, gli

attacchi possono aver luogo e compromettere gradualmente il sistema su un lungo

periodo di tempo (ad esempio, password rubate tramite bruteforce, o attacchi di

flooding che attivano il software aging in un sistema), che potrebbero essere mitigati

effettuando periodicamente la rejuvenation, come cambiare le chiavi crittografiche

riavviando processi compromessi, o randomizzando la località di dati e istruzioni in

memoria [Sousa et al. 2010; Tai et al. 2005; Valdes et al. 2003; Cox et al. 2006;

Huang et al. 2006; Roeder and Schneider 2010]. Altri tipi di effetti di aging sono

relativi all’accumulo di errori numerici [Grottke et al. 2008] e alla frammentazione

di memoria [Grottke et al. 2008; Macedo et al. 2010]. Questo tipo di effetti non

è necessariamente causato da bug nel software, ma sono relativi rispettivamente alla

natura dell’aritmetica floating-point e agli algoritmi di allocazione della memoria.

Infine, molti studi propongono modelli e approcci per affrontare il software aging

indipendentemente dallo specifico tipo di risorsa o aging effect osservati.

1.5 Tecniche di Rejuvenation

La maggior parte dei paper sulla SAR si concentrano sul determinare la pianificazione

ottimale della rejuvenation, sia tramite modelli analitici (rejuvenation time-based), sia

tramite misure (rejuvenation inspection-based). In questa sezione viene posta maggiore

attenzione sulle tecniche adottate per effettuare la rejuvenation di un sistema. La

rejuvenation mira a portare il software da uno stato failure-prone (ad esempio sono

stati accumulati errori) ad uno stato aging-free. Quindi, le tecniche di rejuvenation

possono essere confrontate rispetto a come viene processato lo stato e a come viene

raggiunto lo stato aging-free dopo la rejuvenation.

Si possono riconoscere due macro categorie di tecniche di rejuvenation, riferite come

application-specific, tecniche che sfruttano caratteristiche speciali del dominio o dell’architettura

27


dell’applicazione, e application-generic, tecniche che riavviano il sistema o sue parti e

che non sono specifiche a nessuna classe di sistemi. Tra le tecniche application-generic

si riconoscono differenti sottocategorie: Riavvio dell’applicazione, Riavvio del sistema

operativo, Riavvio di Virtual Machine Monitor (VMM) e Virtual Machine (VM, Cluster

Failover.

Riavvio dell’applicazione. Viene riavviata l’intera applicazione (ad esempio tutti

i processi dell’applicazione vengono terminati e riavviati). Questa è la forma più

semplice di rejuvenation [Huang et al. 1995; Huang et al. 1998]. Questa tecnica

si basa sul meccanismo di inizializzazione di stato disponibile a livello del SO, che,

quando un processo è terminato, dealloca tutte le risorse che erano parte dello stato

dell’applicazione, come aree di memoria dinamica, socket e file handle aperti. Inoltre,

questa rejuvenation si avvantaggia del meccanismo di inizializzazione che i programmatori

introducono nelle loro applicazioni per portarle nel loro stato iniziale. Questo tipo di

rejuvenation non interessa la parte di stato che appartiene all’ambiente di esecuzione

(SO o altre applicazioni). Ad esempio, le risorse del SO che non vengono rilasciate

quando un processo è terminato (un file temporaneo archiviato nel disco, oppure

memoria allocata persa da altre applicazioni) non sono recuperate dalla rejuvenation.

Riavvio del SO. Questa azione riavvia il sistema operativo, e tipicamente le applicazioni

che eseguono in quel SO. Questa forma di rejuvenation è anche detta node reboot

nei sistemi distribuiti. Sebbene sia possibile preservare lo stato delle applicazioni e

ripristinarlo dopo il riavvio, questa possibilità non viene mai considerata negli studi

sulla SAR. Nella sua forma più semplice, il riavvio del SO coinvolge un reset dell’hardware

(la memoria ed i dispositivi hardware vengono reinizializzati e testati prima che il

software possa eseguire), l’avvio del kernel del SO ed il riavvio di tutte le applicazioni

user-space. Schemi più sofisticati riducono il tempo di riavvio dell’OS, portandolo nel

suo stato iniziale evitando il reset dell’hardware [Nelitheertha 2004; Oracle 2012; Alonso

et al. 2011b], come nel caso dei sistemi Linux e Solaris. Questo metodo è ottenuto

invalidando il contenuto della memoria principale e riavviando l’esecuzione del SO

dal suo entry point. Un altro problema è rappresentato dalla perdita di performance

dopo il riavvio del SO: siccome i contenuti della file cache (ad esempio, una copia

28


del contenuto del file conservata nella memoria principale per accelerare gli accessi al

file) sono persi dopo il riavvio, la performance della file cache è degradata fino alla

sua ripopolazione. Per risolvere questo problema, il meccanismo della warm-cache

reboot [Kourai 2010] preserva la file cache in memoria principale durante il riavvio e

permette al SO di ripristinarla dopo il reboot. Inoltre, questo meccanismo deve gestire

il problema dell’inconsistenza della file cache coi dischi (ad esempio, i contenuti del

file sono stati modificati nella memoria principale, ma non sono stati riscritti nel disco

dopo il riavvio - siccome modifiche in attesa possono essere incomplete o affette da

corruzione dei dati, dovrebbero essere scartate dopo il reboot). CacheMind [Kourai

2010] gestisce questo problema eseguendo il SO in una virtual machine, ed usando il

Virtual Machine Monitor (uno strato software che crea un’ambiente di virtual machine

per sistemi operativi e loro applicazioni) per tenere traccia dello stato delle pagine di

file cache, in modo da garantirne la consistenza dopo il riavvio. Bisogna notare che,

quando un SO esegue in una virtual machine e viene riavviato, l’infrastruttura della

virtual machine non viene coinvolta dalla rejuvenation.

Riavvio di Virtual Machine Monitor (VMM) e Virtual Machine. La software

rejuvenation può agire sull’infrastruttura di virtual machine, riavviando il VMM o le

sue VM. In [Machida et al. 2010], vengono ideate diverse strategie, a seconda che

la rejuvenation sia eseguita solo sulla VMM o anche sulle VM che eseguono su di

esso. Nella rejuvenation Cold-VM, quando viene riavviato il VMM vengono riavviate

anche le VM. Nella rejuvenation Warm-VM, l’esecuzione dello stato di ciascuna VM

(incluso il SO e le applicazioni che vi eseguono) sono archiviate in memoria persistente e

ripristinate dopo il riavvio del VMM, in modo da ridurre il downtime di riavviare le VM

ed i loro servizi (sebbene il software che esegue nella VM non venga riavviato). Questa

operazione può essere eseguita velocemente adottando un meccanismo on-memory

syspend/resume, in cui l’immagine di memoria delle VM è preservata in memoria

principale durante il riavvio del VMM, in modo da evitare le lente operazioni di

read/write in memoria persistente (come nel caso di RootHammer [Kourai and chiba

2007; 2001]). Nella rejuvenation Migrate-VM, il downtime è ulteriormente ridotto

migrando le VM su un altro host mentre il VMM viene riavviato, in modo tale da

29


renderle disponibili durante la rejuvenation. Quest’ultimo schema non riavvia le VM,

ed è limitato alla capacità degli altri host di accettare le VM migrate. La miglior tecnica

(o la miglior combinazione di esse) dipende dalla velocità di archiviazione/migrazione

dello stato delle VM e dalla capacità degli host, così come dalla velocità di aging di

VM e VMM. Pertanto la rejuvenation dovrebbe essere pianificata in accordo a questi

fattori [Machida et al. 2010].

Gli approcci application-specific hanno il maggior potenziale per migliorare la velocità

di rejuvenation e ridurre la probabilità di fallimenti. Queste tecniche sono efficaci nel

ridurre il costo della rejuvenation siccome non portano il sistema al suo stato iniziale,

ed evitano un lavoro di redo per ricostruire gran parte dello stato del sistema (riavviare

le transazioni che stavano avvenendo all’istante della rejuvenation). Questo problema

è trascurabile nelle applicazioni stateless, sebbene ha grande importanza nel caso di

applicazioni stateful. Tuttavia, questo approccio non è inteso come economicamete

vantaggioso, in quanto va adattato alla specifica applicazione in modo da salvare

soltanto una parte rilevante dello stato del sistema ed evitare di includere errori aging-related

nel checkpointing, che richiede sforzo di sviluppo che può essere soggetto ad errori.

30


Capitolo 2

Design of Experiments

L’obiettivo della Design of Experiments è progettare il piano sperimentale per ottenere

la massima informazione con il minor numero di esperimenti. La performance di un

sistema spesso dipende da più fattori. Un’analisi adeguata richiede che gli effetti di

ciascun fattore siano isolati da quelli degli altri cosicchè possano essere fatte affermazioni

significative sui differenti livelli di un fattore. Inoltre, permette di determinare se un

fattore ha un effetto significativo o se la differenza osservata è dovuta a variazioni

casuali o ad errori di misura o a parametri non controllabili.

2.1 Metodologia

La metologia sfrutta lo stress test per identificare i problemi di aging. In generale,

lo stress test impone al sistema un workload molto intenso, in termini di volume di

richieste utente per unità di tempo, per un lungo periodo (tipicamente diverse ore)

in modo da aumentare significativamente la probabilità di far emergere gli effetti di

software aging, ad esempio facendo accumulare le perdite di memoria nel tempo. Lo

stress testing dev’essere bilanciato: da un lato, richiede che vengano eseguiti diversi

test sotto diverse condizioni, in modo da esplorare quanti più scenari aging-prone

possibili, poichè l’estensione del software aging (il tasso con cui il dispositivo presenta

degradazione delle prestazioni o esaurimento delle risorse) dipende da come il sistema è

configurato e dagli input sottoposti; dall’altro, il numero di stress test dovrebbe essere

31


tenuto al minimo, siccome ciascun test può richiedere un tempo significativo prima

che gli effetti di aging siano visibili. Ad esempio, nel contesto di Android, app utente

diverse potrebbero avere un impatto differente sul software aging, in quanto potrebbero

attivare servizi diversi nel SO Android; oppure differenti configurazioni di Android

(produttori o versioni) potrebbero esibire differenti effetti di aging. Però, considerare

tutte le combinazioni possibili di workloads e configurazioni porta ad un altissimo

numero di esperimenti long-running, che richiederebbe un tempo di completamento

impraticabile. Per indirizzare il problema di gestire molti parametri (ad esempio,

workload, produttore, versione SO, ecc...), viene adottato un approccio Design of

Experiments (DoE) per ottenere un tradeoff tra precisione e numero degli stress test.

La DoE ha lo scopo di creare un insieme minimo di scenari di test (detto piano

sperimentale) che spieghino la maggior parte della variabilità dell’output con pochi

trattamenti, separando l’impatto delle variabili di interesse dall’impatto (di solito

trascurabile) di più variabili combinate. In questo modo, a seconda di quanti trattamenti

possono essere fatti, il tester può sistematicamente decidere di ignorare le variabili

meno importanti. Nei paragrafi a seguire, verranno definiti i fattori e le variabili

di risposta scelte per applicare la DoE nel contesto del SO mobile. I Fattori sono i

parametri che possono potenzialmente influire sulle variabili di risposta; il loro valore

è scelto tra un insieme di possibili livelli. La combinazione di fattori e livelli definisce

il piano sperimentale. Innanzitutto, vengono identificate le combinazioni fattibili di

dispositivi e versioni Android, dato che non è possibile installare tutte le versioni

su tutti i dispositivi. Successivamente, viene definito un design blocked full-factorial

in riferimento agli altri fattori. La variabile di risposta rappresenta il risultato di

un esperimento; per esempio, la metrica che quantifica l’effetto di aging. Verranno

considerate sia metriche di risposta user-perceived, che riflettono il software aging così

come viene direttamente percepito dall’utente, sia metriche di risposta system-related,

che riflettono la quantità di stress imposta sulle risorse e sui sottosistemi, ed indirettamente

le possibili cause dell’aging user-perceived.

Infine, i dati sperimentali vengono analizzati tramite tecniche statistiche, quali:

32


• Test di Mann-Kendall, per affermare statisticamente se esiste un trend monotono

in una serie temporale della variabile di interesse;

• Sen’s procedure, per calcolare, in modo non parametrico, lo slope di un trend;

• Coefficiente di correlazione per ranghi di Spearman, per analizzare la dipendenza

statistica tra due variabili di interesse;

• Analisi della Varianza (ANOVA) e test d’ipotesi Kruskal-Wallis/Wilcoxon per

analizzare se le differenze tra due insiemi di esperimenti sono statisticamente

significative (e non dovuti a variazioni aleatorie);

La figura 2.1 fornisce una vista della metodologia utilizzata per l’analisi dei dati.

Le analisi su memoria e task verranno applicati solo per quattro processi principali.

Quest’aspetto verrà ulteriormente approfondito nelle successive sezioni.

Figura 2.1: Panoramica della metodologia per l’analisi del Software Aging

33


2.2 Variabili di Risposta

2.2.1 User-perceived

Per quantificare come il software aging viene percepito dagli utenti, viene considerata

la responsività del SO Android, in quanto è uno degli obiettivi del design del sistema

operativo mobile. Ad esempio, uno degli obiettivi più recenti è stato quello di “cold-start

a basic application, up to a responsive GUI, within 200ms at most“ [63], [64]. Pertanto,

la responsività user-perceived viene quantificata misurando il Launch Time (LT) delle

attività Android (un componente di un’applicazione che fornisce una GUI). Il LT è il

periodo di tempo tra la richiesta di iniziare un’Attività e l’apparizione dell’Attività

sullo schermo, includendo l’inizializzazione degli elementi di background e foreground.

Per misurare il LT vengono analizzati i log dell’Activity Manager del SO Android,

che è il servizio responsabile per istanziare nuove attività, per passare da un’attività

all’altra e per salvare e ripristinare il loro stato. L’Activity Manager traccia gli eventi

che innescano l’inizio di una nuova Attività (indicato dal tag "ActivityManager" e dalla

parola chiave "Displayed"), compreso il tempo speso per avviare l’attività, e possono

essere raccolti tramite l’utility logcat.

Per ottenere periodicamente osservazioni del LT durante l’esperimento, le applicazioni

utente usate come workload vengono periodicamente (ad una bassa frequenza, ogni

sessanta secondi) terminate e riavviate. C’è bisogno di terminare le app altrimenti,

il sistema operativo Android metterebbe in cache le Attività (ad esempio, se l’app è

stata aperta di recente, le Attività sono recuperate dalla cache quando l’utente passa

nuovamente su quell’app) e impedirebbe l’avvio di nuove Attività, senza quindi fornire

alcuna informazione circa la responsività del sistema. Inoltre, siccome l’obiettivo è

quello di studiare il software aging nel sistema operativo sottostante e non all’interno

delle app, riavviando periodicamente le app, non è possibile che si accumulino effetti

di software aging (come memory leak) all’interno dell’app stessa.

34


La linea seguente è un esempio di messaggio di log che mostra l’Attività "MainActivity"

dall’applicazione "com.example.myapp", che impiega 100ms per completare la sua

inizializzazione:

I/ActivityManager(1097): Displayed com.example.myapp /.MainActivity: +100ms

Dopo un esperimento, viene analizzato il LT per identificare una degradazione nella

responsività. Idealmente, se il dispositivo fosse libero dal software aging, il LT medio

non cambierebbe attraverso gli esperimenti, siccome il workload e le condizioni di test

vengono tenute fissate durante l’esperimento. Però, ci si aspetta che il software aging

manifesti gradualmente i suoi effetti durante l’esperimento, degradando continuamente

il LT delle app del workload.

Per analizzare il LT (figura 2.1), viene prodotta una serie temporale per ciascun

esperimento utilizzando le osservazioni di LT di tutte le Attività collezionate durante

l’esperimento, e viene applicato il test statistico non-parametrico di Mann-Kendall

(MK) per verificare se la serie temporale esibisce un trend. Questo test statistico verifica

l’ipotesi nulla che non ci sia un trend monotono nella serie temporale, e fornisce un

livello di significatività (p-value) per la probabilità che l’ipotesi nulla sia effettivamente

vera nella serie temporale. Se il p-value è minore di un dato α, si può rigettare l’ipotesi

nulla con probabilità, ossia con una confidenza, maggiore di (1 − α), che indica che il

LT è affetto da trend. Viene richiesto che la confidenza sia maggiore del 90% (α = 0.1).

Inoltre, nel caso in cui il LT esibisca un trend, viene calcolato lo slope di tale trend

applicando la Sen’s procedure, che è una tecnica non parametrica che trova un modello

lineare per i dati e calcola il tasso con cui i valori delle osservazioni aumentano nel

tempo. Essa calcola lo slope come mediana di tutti gli slope tra valori accoppiati ed è

insensibile agli outlier. Come visto nel capitolo 1, questo approccio è spesso adottato

negli studi di software aging dove il sistema è stressato sotto fisse condizioni, il che è

probabile che conduca ad un tasso di degradazione fisso (se esiste).

35


2.2.2 System-related

Per analizzare il software aging in profondità, vengono collezionate anche metriche

sull’utilizzo di risorse e sugli eventi che avvengono all’interno del SO Android. Le

metriche system-related includono l’utilizzo di memoria (che è la risorsa più esposta al

problema del software aging a causa dei bug di cattiva gestione e tipicamente è scarsa

nei sistemi mobili); l’utilizzo di CPU (è anch’esso esposto al software aging, ad esempio,

a causa di bug algoritmici che sprecano il tempo di CPU su una struttura dati molto

grande); e la durata di garbage collection (che è un’attività critica per l’uso efficiente

della memoria). Nella successiva analisi, verranno analizzate le metriche system-related

per indicare quali sono le aree più stressate del sistema operativo Android che possono

essere la causa del software aging. Inoltre, queste metriche forniscono una valida base

per lo sviluppo di soluzioni di software rejuvenation visto che possono essere monitorate

facilmente, con poca intrusività ed in modo portabile attraverso i dispositivi Android,

utilizzando le interfacce standard fornite dal framework Android e dal kernel Linux.

1)Memoria: viene posta maggior attenzione sull’utilizzo di memoria, poichè precedenti

studi sugli effetti del software aging hanno dimostrato che questa è la risorsa più colpita

e tende ad avere il TTE minore. Il sistema operativo Android utilizza meccanismi

elaborati per gestire la memoria, gestendo automaticamente il ciclo di vita delle app

(ad esempio recuperando le risorse quando un’app non è utilizzata per molto tempo,

ad esempio, attraverso l’out-of-memory-killer [63]), riciclando i processi (ad esempio,

quando viene avviata una nuova Attività) e gestendo la memoria all’interno delle

applicazioni basate sull’ambiente Java ART (Android Run-Time). Un’altra possibile

causa degli effetti di aging nell’utilizzo di memoria è rappresentato dalla complessità

dei servizi del SO Android, come l’Activity Manager ed il Package Manager, che sono

persistenti e possono accumulare effetti di aging nel tempo.

Le informazioni sulla memoria vengono collezionate tramite l’utility Android dumpsys,

che riporta il consumo di memoria del SO Android sia in user-space (a esempio, la

memoria utilizzata dalle app ed i servizi Android) che in kernel-space (ad esempio,

le estensioni Android al kernel linux come il Kernel Samepage Merging (KSM) e la

36


compressione di memoria virtuale (zram)). L’attenzione verrà però concentrata sul

consumo di memoria di ciascun processo del SO Android, raccogliendo periodicamente

(ogni trenta secondi) il suo Proportional Set Size (PSS), ovvero, la quantità di RAM

mappata in un processo che comprende il Resident Set Size (la porzione di memoria

occupata in RAM da un processo, escludendo quelle parti che non consumano memoria,

come il codice del programma che ancora non è stato eseguito e che risiede nello storage)

e, in proporzione, la quantità di memoria condivisa con altri processi. Questa metrica

viene considerata la più rilevante in quanto in recenti studi si è mostrata la più correlata

ai trend di performance degradation [66].

Verrà verificato se la degradazione del LT è collegata alla metrica di PSS per ciascun

processo, prima controllando se c’è un trend nel PSS dei processi e poi correlandoli al

trend del LT. Per ciascuna serie del PSS vengono eseguiti i seguenti passi: (i) viene

testata la presenza del trend (e viene calcolato il suo slope) usando il test di Mann-Kendall

e la Sen’s procedure; (ii) viene calcolata una misura di correlazione tra gli slope della

metrica di memoria e lo slope del trend di LT, per tutti gli esperimenti, utilizzando il

coefficiente di correlazione per ranghi di Spearman, siccome è robusto agli outlier e non

fa assunzioni restrittive circa la distribuzione dei dati, contrariamente alle controparti

parametriche. La correlazione indica se un trend di una metrica è sistematicamente

accompagnato da un trend di degradazione del LT.

2) Garbage Collection: La Garbage Collection (GC) è un componente chiave per i

moderni ambienti di programmazione, siccome gestisce l’allocazione di memoria dinamica

al posto del programmatore (ad esempio liberando aree non utilizzate) in modo da

evitare bug di cattiva gestione della memoria. Comunque, nonostante la garbage

collection, ci possono ancora essere effetti di software aging residui: se gli oggetti

non più utilizzati sono ancora referenziati dal programma (a causa di una cattiva

gestione degli oggetti del programmatore), il GC non è in grado di smaltire gli oggetti,

che possono accumularsi nel tempo. Inoltre, la frammentazione della memoria (l’uso

di diversi piccoli oggetti piuttosto che di uno grande) ed altre cattive pratiche di

programmazione (frequente riallocazione di oggetti che invece potrebbero essere riutilizzati)

può impattare sulla GC e degradare significativamente la performance percepita dagli

37


utenti. Se la GC impiega troppo tempo, l’applicazione può risultare "congelata" per

brevi periodi o essere notevolmente rallentata durante la GC. Pertanto, tra le metriche

system-related viene includa anche la GC.

Le informazioni circa la GC vengono raccolte dai log del SO Android tramite il tool

logcat, contrassegnati con il tag "art" come nell’esempio seguente:

I/art : ExplicitconcurrentmarksweepGCfreed104710(7MB)AllocSpaceobjects, 21(416KB)LOSobjects, 33%free, 25MB/38MB, paused1.230mstotal67.216ms

L’ART riporta la GC solo nel caso in cui essa impieghi più tempo del solito (in

particolare, quando il Pause Time del GC supera i 5ms, oppure la Duration del

GC supera i 100ms). In questo caso, il log include l’evento che ha attivato la GC

(ad esempio, se la GC è stata attivata in background, oppure è stata esplicitamente

invocata dal programma come nel caso di alcuni servizi del SO Android); l’algoritmo

di GC (siccome la ART ne supporta più di uno); il tempo speso per effettuare la GC;

il quantitativo di oggetti liberati dalla GC; la memoria heap disponibile. Questi log

vengono collezionati non appena appaiono nel corso dell’esperimento. I log della ART

evidenziano casi di lentezza della GC, che sono rilevanti per l’analisi. Ci si aspetta

che workload intensi (come quelli usati nello stress test) possano evidenziare gli effetti

di cattiva gestione della memoria nei componenti Android, che a loro volta possono

risultare in una degradazione delle prestazioni. Le metriche di GC vengono analizzate

individualmente per ciascun processo, calcolando i trend usando il test di Mann-Kendall

e la Sen’s procedure. Poi, vengono contati il numero di casi in cui un processo esibisce

un aumento dei tempi di GC, che rivela una possibile relazione tra il software aging

(in particolare, perdita di responsività, e memory bloat (un aumento netto dell’uso di

memoria a causa dell’allocazione di molti oggetti) o frammentazione.

3) Utilizzo di CPU e memoria a livello task: Il SO Android adotta una complessa

architettura multi-processo e multi-thread per eseguire i suoi numerosi servizi e componenti

(ad esempio, per gestire specifiche risorse hardware o fornire una API). Comunque,

le metriche precedenti forniscono informazioni circa i processi, ma non forniscono

specifiche informazioni circa i thread individuali all’interno di un processo. Questa

è una limitazione per l’analisi del SO Android, siccome esso esegue la maggior parte

dei suoi servizi base (ad esempio, camera, audio, phone, ...) come thread all’interno

38


di pochi processi (come il SystemServer ed il MediaServer) [65]. Pertanto, vengono

introdotte metriche addizionali per entrare più nel dettaglio delle attività dei servizi

che eseguono all’interno dei thread. Nel kernel Linux sottostante, sia i processi che i

thread sono rappresentati come task. Un processo multi-thread consiste in un insieme

di task che condividono le stesse risorse (ad esempio, spazio di indirizzamento virtuale,

file aperti, ...). Perciò vengono analizzate metriche di utilizzo di CPU e memoria per

task individuali. Queste metriche indicano quali task sono più attivi durante l’inizio

degli effetti di software aging, e sono una potenziale radice della causa del software

aging.

Le metriche task-level vengono collezionate dal filesystem proc del kernel Linux. In

particolare, viene utilizzato il file virtuale stat esposto dal kernel (nella cartella /proc/TASK_PID/)

per fornire informazioni circa lo scheduling e l’uso di memoria di ciascun task. Queste

metriche includono il numero di minor and major page faults (ad esempio, il task

richiede nuovo codice o nuovi dati, denotando così un’elevata attività di memoria), ed

il tempo di esecuzione speso in user-space e kernel-space (che rispettivamente indicano

l’attività di CPU ed I/O del task). Le metriche task-level vengono campionate periodicamente

ogni trenta secondi.

Per identificare i task critici, viene calcolato il trend per ciascuna metrica e per ciascun

task utilizzando il test di Mann-Kendall e la Sen’s procedure. Poi, viene contato

il numero di casi in cui una metrica esibisce un trend in maniera statisticamente

significativa per un task, ad un livello di confidenza del 90%. Quanto più elevato

è il conteggio, tanto più è alta la probabilità che la metrica evolva con un effetto di

software aging, rivelando quindi una potenziale relazione tra il task ed il software aging

del dispositivo.

Di seguito viene riportata una tabella riassuntiva di tutte le metriche utilizzate in

questo studio.

39


Metrica Unità di misura Descrizione Utility Fonte

Responsività Launch Time ms Tempo totale

trascorso tra l’inizio

di un’attività e la sua

comparsa sul display

Logcat Log ART

Memoria PSS per processo kB Quantità di RAM

mappata nel processo

dumpsys meminfo /proc//smaps

Garbage CollectionPause Time ms Quantità di tempo

che il processo ha

trascorso in pausa

durante la GC

Logcat Log ART

Duration ms Tempo di

completamente per la

garbage collection

Logcat Log ART

Task

Minor page faults # di page faults Numero di page

faults servidi dalle

pagine condivise già

in memoria

leggendo direttamente da /proc /proc//task/stat

Major page faults # di page faults Numero di page faults

che richiedono una

operazione di I/O


User time kernel jiffies Quantità di tempo

spesa dal processo in

user-mode

leggendo direttamente da /proc /proc//tas/stat

System time kernel jiffies Quantità di tempo

spesa dal processo in

kernel-mode


Tabella 2.1: Panoramica metriche

40


2.3 Fattori e livelli

Per stressare estensivamente il sistema operativo Android e per attivare effetti di aging

latenti, vengono eseguiti test sotto differenti configurazioni e applicazioni del workload,

che rappresentano i fattori del piano sperimentale, sintetizzate in tab 2.2. Vengono

considerati 5 fattori, e viene derivato il piano sperimentale variando le combinazioni

dei livelli in accordo con la DoE.

1. Insieme di Applicazioni (APP): Gli esperimenti usano diversi insiemi di

applicazioni come workload per stimolare il sistema operativo Android. Queste

app sono scelte come rappresentative di scenari d’uso comuni (compresi, navigazione

browser, fare foto, effettuare chiamate, chattare) ed includono sia app stock che

app di terze parti. Questi insiemi dovrebbero includere applicazioni Android

popolari, elencate in tab 2.2, che devono essere installate su tutti i dispositivi

usati negli esperimenti. Le applicazioni vengono organizzate in due gruppi, che

possono rappresentare i due livelli del fattore APP: applicazioni eu-us (EU-US),

ed applicazioni cinesi (CHINA), che sono rispettivamente ottenute dalla versione

europea del Google app market, e dall’app market cinese.

2. Dispositivo (DEV): Gli esperimenti possono essere eseguiti su differenti dispositivi

Android provenienti da diversi produttori, ciascuno con le sue configurazioni

hardware-software e le sue personalizzazioni. Ciascun dispositivo Android disponibile

nel piano sperimentale stabilisce un livello del fattore. Gli esperimenti sono

stati condotti su dispositivi di fascia alta di diversi produttori; quindi, abbiamo

quattro livelli per il fattore DEV, etichettati come HTCONEM9, HUAWEIP8,

LGNEXUS, SAMSUNGS6EDGE.

3. Configurazione degli eventi di workload (EVENTS): Il generatore di workload

(basato sul tool Android monkey) produce un insieme di "eventi" per interagire

con le app ed il dispositivo Android. Questi eventi comprendono: switch tra

applicazioni, touch, motion, trackball ed eventi di navigazione. Questi eventi sono

generati casualmente ed è possibile configurarne la probabilità di occorrenza. Il

41


fattore EVENTS varia attraverso tre livelli: MIXED1, dove la metà sono eventi di

switch tra applicazioni; MIXED2, dove la metà sono eventi di touch; MIXED3,

dove la metà sono eventi di navigazione. In ciascun livello, la restante parte

degli eventi sono dei tipi rimanenti e sono selezionati secondo una distribuzione

uniforme casuale.

4. Uso dello spazio di archiviazione (STO): Gli esperimenti possono essere

eseguiti con o senza spazio di archiviazione disponibile (in termini di spazio

libero), siccome questo aspetto può influire su alcuni dei servizi del SO Android

(come l’archiviazione di foto e video dalla fotocamera). Quindi, il fattore STO

varia su due livelli: HIGH, dove la memoria è occupata per più del 90% da

file multimediali (come video e immagini); e LOW, dove viene utilizzata la

quantità di storage di default (ovvero lo spazio è occupato solo da file di sistema

e applicazioni).

5. Versione Android (VER): I dispositivi Android possono eseguire differenti

versioni del SO Android. Le versioni di Android OS disponibili per un dispositivo

determinano i livelli del fattore VER. Bisogna osservare che non tutti i livelli del

fattore DEV possono essere combinati con tutti i livelli del fattore VER, perchè

alcuni dispositivi non supportano le vecchie o le nuove versioni del SO Android

(ad esempio, alcuni dispositivi possono supportare solo Android 5 e 6 mentre altri

possono supportare solo Android 6 e 7). In totale, ci sono tre livelli per il fattore

VER: ANDROID5, ANDROID6 e ANDROID7.

Nell’analisi, asseriamo se questi cinque fattori contribuiscono alla gravità del software

aging, al fine da fornire un contesto di quali condizioni siano le più problematiche. Verrà

applicata la tecnica l’Analisi della Varianza one-way (ANOVA) per affermare quali

fattori influiscono in maniera statisticamente significativa sulla variabile di risposta.

Per utilizzare l’ANOVA non parametrica ed essere robusti alla distribuzione degli errori

potenzialmente non-normale, verrà usato il test d’ipotesi di Kruskal-Wallis/Wilcoxon.

L’ipotesi nulla, in questo caso, è che il fattore non influisce sulla variabile di risposta,

ed il p-value indica, ancora, la confidenza nel rigettare l’ipotesi. Si può concludere che

42


il fattore impatta sulla variabile di risposta se il livello di confidenza è maggiore del

90%, ovvero, il p-value è minore di 0.1.

Fattore Livello Descrizione

DEV

HTCONEM9 Dispositivo HTC One M9

HUAWEIP8 Dispositivo Huawei P8

LGNEXUS Dispositivo LG Nexus

SAMGUNGS6EDGE Dispositivo Samsung S6 Edge

VER

ANDROID5 Android 5 (Lollipop)

ANDROID6 Android6 (Marshmallow)

ANDROID7 Android7 (Nougat)

APPEU-US

com.google.android.videos

com.*.camera, com.android.browser

com.android.email

com.android.contacts

com.google.android.apps.maps

com.android.chrome

com.google.android.play.games

com.android.calendar

com.google.android.music

com.google.android.youtube

CHINA

com.tencent.mm

com.sina.weibo

com.qiyi.video

com.youku.phone

com.taobao.taobao

c

Analisi dei fenomeni di Software Aging nei sistemi operativi...

Documents

Transcript of Analisi dei fenomeni di Software Aging nei sistemi operativi...