Metodologie di ottimizzazione e analisi prestazionale degli elaboratori

Transcript

1 Metodologie di ottimizzazione e analisi prestazionale degli elaboratori Seminario del corso di Architettura degli elaboratori elettronici LABORATORIO UNIVERSITA CATTOLICA DI BRESCIA 23 novembre 2005 Roberto Pane Resp. Settore Sistemi Distribuiti e Sicurezza Logica Lombarda Sistemi e Servizi

2 Agenda Il laboratorio di oggi è organizzato nel seguente modo: Ripresa di alcuni temi già esposti nel seminario teorico» Metodologie di analisi prestazionali delle architetture (performance monitoring)» Esposizione del laboratorio e degli strumenti che saranno utilizzati zati nella sessione operativa Sessione di LABORATORIO:» Determinare la prestazione del sistema server al crescere della concorrenza degli utenti, monitorando su WAST e riportando su Excel l andamento dei tempi in funzione del carico simulato» Determinare il bottleneck provocato nei due scenari: (A) CPU Starvation (B) Memory leakage

3 Il concetto di performance Per performance si intende lo sfruttamento delle risorse della macchina m HW dalla macchina software (l applicazione di business) tramite l intermediazione l del sistema operativo. La performance ottimale è quella che, data l applicazione, l ottimizza l uso l dell hardware e che, data l applicazione, l le risorse hardware sono effettivamente atte a sopportarne il carico (vedi problema del dimensionamento). d Il processo di rilevazione ed ottimizzazione delle performance è sempre un attivit attività complessa in quanto deve tener conto dei seguenti aspetti: Architettura del sistema e tipologia del sistema Caratteristiche dell applicazione (Client( Client/Server, web, uso di basi dati, transazionalità distribuita) Caratteristiche della rete su cui viaggiano le informazioni Altre applicazioni che girano all interno della macchina

4 Casi critici per la performance Date le caratteristiche che sono in grado di influenzare fortemente le performance delle applicazioni ci sono alcuni casi che meritano un approfondimento in quanto sono tipologie standard in cui ricadono la maggior parte dei casi. Colli di bottiglia (Bottlenecks( Bottlenecks): si definisce collo di bottiglia una condizione in cui la limitazione di uno dei componenti (HW & SW) causa il rallentamento di tutti gli altri. Se il bottleneck non è identificato e risolto, il potenziamento di altri componenti non coinvolti nel bottleneck,, non migliorerà le prestazioni del sistema. Utilizzo della risorsa (utilization( utilization): anche se una risorsa fortemente utilizzata ha le caratteristiche per essere un bottleneck non è detto che lo sia fino a che non causa il non utilizzo di altre che sarebbero disponibili. Il 100% di utilizzo di una risorsa non è detto che causi un bottleneck e ci sono risorse con un grado di utilizzo inferiore al 100% che sono dei bottleneck. Code (queues): il bottleneck si evidenzia nel momento in cui si verificano degli accodamenti all interno del sistema o della risorsa insufficiente o mal utilizzata.

5 Strumenti di rilevazione Gli strumenti di rilevazione sono specifici del sistema operativo o utilizzato. Nel nostro caso useremo gli strumenti forniti all interno del sistema Microsoft Windows. PERFORMANCE MONITOR (PERFMON.EXE( PERFMON.EXE): è uno degli strumenti più utilizzati e consente un monitoraggio puntuale delle risorse HW e SW della macchina. Inoltre le applicazioni possono integrarsi con il performance monitor esponendo i relativi contatori. TASK MANAGER (TASKMGR.EXE( TASKMGR.EXE): è uno strumento rapido che consente un indagine veloce dello stato del sistema.

6 Ambiente del laboratorio Nel lab, oltre agli strumenti prima evidenziati, sarà utilizzata un applicazione freeware open-source basata su.net che sarà utilizzata al fine di effettuare il test. L applicazione è un portale informativo ed è presente nel CD-ROM anche con i source, è composta da un web server, dal framework.net e da un DB server (SQL Server). Database of portal application SQL SERVER - DATABASE - Server with Web portal (INTERNET INFORMATION SERVER) - WEB SERVER and.net framework - APPLICATION SERVER PC with WAST installed simulating multi-user activity

7 Strumenti: Uso del PERFMON Il PERFMON è in grado di campionare l attività in essere all interno della macchina sotto analisi tramite contatori. I contatori possono essere sere mostrati tramite Chart (line o istogram) ) e registrati tramite Log e successivamente elaborati via PERFMON o altri strumenti. Inoltre lo strumento è in grado di inviare Alerts al supero di determinate soglie e di redigere Report. Nel Perfmon Graph a sinistra è visualizzato l andamento di alcuni contatori durante l esecuzione l dello script del WAST che sarà utilizzato durante il laboratorio

8 Strumenti: Performance Counters per i LAB CONTATORE ISTANZA OGGETTO DESCRIZIONE Pagine/Sec --- Memoria Pagine/sec è la velocità di lettura o di scrittura delle pagine da o su un disco per risolvere gli errori di pagina di memoria hardw are. Questo contatore è l'indicatore primario dei tipi di errore che causano ritardi a tutto il sistema. È espresso in nume Lunghezza media coda del disco _Total Disco fisico Lunghezza media della coda del disco è il numero medio delle richieste di lettura e di scrittura messe in coda per il disco specificato durante l'intervallo di tempo campione. % Tempo processore _Total Processore % Tempo processore è espresso come percentuale del tempo che il processore impiega per eseguire un thread attivo. Questo contatore è l'indicatore primario dell'attività del processore e mostra la percentuale media di tempo trascorso eseguendo lavoro utile Connessioni correnti _Total Servizio Web Connessioni correnti è il numero corrente di connessioni stabilite con il Servizio Web. Tentativi di connessione/sec _Total Servizio Web Frequenza dei tentativi di connessione con il Servizio Web. User Connections --- SQL Server: General Statistics Number of users connected to the system. Richieste in esecuzione _PortalCSVS ASP.NET Applications Numero delle richieste attualmente in esecuzione. Richieste nella coda dell'applicazione _PortalCSVS ASP.NET Applications Numero di richieste nella coda di richieste dell'applicazione. Richieste/sec _PortalCSVS ASP.NET Applications Numero di richieste soddisfatte al secondo.

9 Strumenti: Uso del WAST Il WAST (Web Application Stress Tool) è uno strumento atto a stressare le applicazioni web simulando n connessioni concorrenti su pattern di navigazione prestabiliti. Il suo utilizzo è in generale teso a rilevare le capacità elaborative del sistema o ad ottimizzare l applicazione l rilevando delle particolari navigazioni o funzionalità applicative particolarmente lente. Noi utilizzeremo il Wast per determinare la presenza di bottleneck all interno del sistema. 1 utilizzo: determinare la presenza del bottleneck ed identificarlo. 2 utilizzo: eliminato il bottleneck,, verificare la capacità di carico del sistema

10 Strumenti: CPUStress, Leaky App Al fine di simulare un bottleneck all interno del sistema saranno utilizzate due differenti applicazioni fornite all interno del Resource Kit di Microsoft Windows. Normalmente i bottleneck non devono essere provocati ma sono l oggetto l della ricerca. CPUSTRESS (SP2004.EXE): è uno strumento che consente di simulare uno stress della CPU tramite una serie di elaborazioni CPU-intensive. Il risultato è quello di limitare fortemente e gradualmente le risorse della macchina. LEAKYAPP (LEAKYAPP.EXE( LEAKYAPP.EXE): è uno strumento che consente di simulare un applicazione che abbia dei memory leak.. Un memory leak consiste nel fatto che un applicazione o un servizio non disallochi la memoria dopo averla utilizzata causandone in questo modo la perdita. A lungo andare il sistema risente della perdita di memoria ed è necessaria la sua ripartenza (reboot system).

11 Determinare i processor bottlenecks (CPU Starvation) Il rilevamento di un processor bottleneck è in generale semplice in quanto si verifica nel momento in cui uno specifico processo o il processo di sistema consuma eccessivamente CPU. Attenzione che molte volte un supposto processor bottleneck è invece un memory bottleneck mascherato. I contatori più interessanti per verificare un processor bottleneck sono rappresentati da:» SYSTEM: % Total Processor Time» SYSTEM: Processor Queue Length» PROCESSOR: % Processor Time» PROCESS: % Processor Time» PROCESS: % User Time» PROCESS: % Privileged Time Object System System Processor Process Process Process Process Thread Thread Thread Thread Thread Thread Counter % Total Processor Time Processor Queue Length % Processor Time % Processor Time % User Time % Privileged Time Priority Base Thread State Priority Base Priority Current Context Switches/Sec % User Time % Privileged Time

12 Determinare i memory bottlenecks Memory leak Windows è equipaggiato con un sistema di Virtual Memory in grado di utilizzare come memoria sia la RAM che uno o più spazi su disco (i cosiddetti pagefile ). Nel momento in cui la memoria disponibile tende a diminuire, come e nel caso di un memory leak,, il sistema tende sempre di più a caricare e scaricare il pagefile, causando così un netto ed importante degrado prestazionale. Un importante indicatore della possibilità di un memory bottleneck è rappresentato dai page faults,, ossia dall evento che si verifica quando la pagina di memoria necessaria all applicazione applicazione non si trova in RAM ma su disco. Object Memory Memory Memory Memory Memory Memory Memory Process Process Process Process Counter Page Faults/sec Page Reads/sec Page Writes/sec Pages Input/sec Pages Output/sec Available bytes Nonpaged pool bytes Page Faults/sec Working set Private Bytes Page File Bytes

13 LAB Materiale a supporto Sul CD distribuito nel seminario si trova /PPT: si trovano i PDF relativi ai PPT del seminario Sessione Teorica e Sessione Pratica /STRUMENTI: si trovano i seguenti file» Sp2004.exe SW di CPU Stress» LAB_Counters.msc file del PERFMON con i performance counters preimpostati» WAST_Setup.exe File di installazione del WAST» LEAKYAPP.ZIP > > SW di Memory Leak» WAST_Script_DB.mdb DB di Script per il WAST /APPLICAZIONI:» ASP.NET Portal (CSVS) Installer v1.0.msi Setup del Web Portal» Portal Whitepaper.doc Documentazione del Portal App» SourceCode.exe Source code del Portal App» Microsoft SQL Server 2000 evaluation KIT

14 LAB 1 Il LAB 1 ha l obiettivo l di determinare, al crescere del carico, le variazioni dei tempi di risposta dell applicazione Portale in un ambiente dedicato. Non ci sono quindi altre applicazioni che utilizzano risorse all infuori dei sottosistemi necessari per l ambiente di esecuzione. Attività nel LAB: Uso del WAST per eseguire gli script dai differenti client Monitoraggio dei performance counters identificati per interpretare l andamento il carico sul sistema Interpretazione dei risultati prestazionali del test dai report del WAST

15 LAB 2/A CPU Starvation Partendo dai dati ottenuti nel LAB precedente si effettueranno una u serie di test utilizzando il SW di CPU Stress in differenti configurazioni. Il SW di CPU Stress simula una compresenza all interno della macchina di differenti applicazioni facendo quindi diventare il sistema condiviso. Attività del LAB: Uso di CPU Stress per simulare differenti condizioni di carico esterno e all applicazioni applicazioni Uso del WAST per eseguire gli script dai differenti client Monitoraggio dei performance counters identificati per interpretare l andamento il carico sul sistema Interpretazione dei risultati prestazionali del test dai report del WAST

16 LAB 2/B Memory Leaking Partendo dai dati ottenuti nel LAB precedente si effettueranno una u serie di test utilizzando il Leaky App per simulare un drenaggio anomalo della memoria. Attività del LAB: Uso di Leaky App per simulare condizioni di memory leaking Uso del WAST per eseguire gli script dai differenti client Monitoraggio dei performance counters identificati per interpretare l andamento il carico sul sistema con focalizzazione sugli aspetti di memory management Interpretazione dei risultati prestazionali del test dai report del WAST

17 Fine del seminario Arrivederci a tutti e BUON ESAME