Monitoring & Profiling

Transkript

1 Monitoring & Profiling Simon Tschirner Universität Oldenburg 1 Einleitung Diese Ausarbeitung beschäftigt sich im Rahmen der Projektgruppe Fuzzy Power Management mit dem Thema Monitoring und Profiling. Die Betrachtung der Themen erfolgt in Hinsicht auf das Projektziel, ein Power Management System für Notebooks zu erstellen. Folglich werden einige Beispiele speziell auf Notebooks bzw. PCs und deren Energieverbrauch bezogen sein. Vor allem aber werden am Ende des Textes die Einsatzmöglichkeiten von Monitoring und Profiling in einem Power Management System evaluiert. Zur Einarbeitung in das Thema dienten frühere Arbeiten zu den beiden Themen, in denen spezifisch entwickelte Systeme, die auf bestimmte Art Monitoring bzw. Profiling praktizieren, vorgestellt werden. Versucht man die Worte Monitoring und Profiling zu übersetzen, kann man schon erahnen, dass es bei diesem Thema darum geht, Informationen zu sammeln etwas zu protokollieren. Anhand der erstellten Protokolle können wiederum Rückschlüsse gezogen werden, wie ein bestimmter Vorgang oder ein System optimiert werden könnte. An dieser Stelle zeigt sich eine deutliche Verbindung zur Aufgabe von Power Management Systemen: Ein System soll auf einen möglichst geringen Energieverbrauch bei möglichst aufgabenspezifisch hoher Performanz optimiert werden. Für eine solche Optimierung können u.a. Daten über das System, seine Komponenten und den Ablauf der Nutzung sowohl des Systems als auch der Komponenten interessante und wichtige Informationen enthalten. In den nächsten beiden Kapiteln wird ausführlicher beschrieben, was hinter den Begriffen Monitoring und Profiling steckt. Es werden verschiedene Ansätze und Möglichkeiten sowie spezielle Implementierungen vorgestellt. Mit diesen Informationen sollten schließlich erste Ideen kommen, ob und auf welche Weise die beiden Technologien und die von ihnen gesammelten Daten für die genannte Optimierung genutzt werden können. 2 System Monitoring In diesem Abschnitt wird erklärt, worum es beim Monitoring geht. Es werden einige Grundsätze dargestellt und Dinge, die beachtet werden müssen. Schließlich wird ein implementiertes Monitoring-System mit den dafür vorgenommenen Überlegungen und Entscheidungen vorgestellt. 2.1 Überblick Was ist Monitoring? Monitoring könnte man als das Sammeln von Systeminformationen bezeichnen. Dieses Sammeln kann auf verschiedene Weisen und in verschiedenem Umfang geschehen. Es kann sowohl das gesamte System überwacht werden, als auch nur einzelne

2 2 Ressourcen oder Komponenten (im Folgenden werden diese Begriffe synonym gebraucht); je nachdem, was für den bestimmten Einsatz von Belang ist. Ein System kann dabei ein einzelner Rechner aber auch ein umfangreiches Computernetzwerk sein [1]. Der Blick dieser Ausarbeitung richtet sich allerdings auch wenn sie in Teilen auf gesamte Systeme übertragen werden kann auf einzelne Computer, da diese Einschränkung in Hinsicht auf den Einsatz für ein Power Management System für Notebooks ergiebig erscheint. Interessante Daten sind üblicherweise solche, die den Zeitpunkt und -raum betreffen, über den eine Komponente benötigt wird und sofern es möglich ist, auch Daten über die nominelle Beanspruchung. Der Kontext, in dem die Benutzung stattfand, kann ebenfalls wichtig sein, oft kann dieser jedoch bereits durch die Monitoring- Daten anderer Komponenten gegeben sein. Anhand dieser Daten kann schließlich später die Auslastung eines Systems bei bestimmten Aufgaben analysiert werden (off-line), alternativ können die Daten aber auch sofort dazu eingesetzt werden, das System zu steuern und den Daten entsprechend optimal anzupassen (on-line) [2]. Es gibt verschiedene Möglichkeiten, diese Daten zu generieren und zu verarbeiten bzw. zu speichern. Das Erzeugen von Monitoring-Daten kann z.b. periodisch passieren, so dass jede zu überwachende Komponente in einem festen Abstand seinen Status mitteilt. Anders kann dies aber auch durch Anforderungen (on request) geschehen, indem z.b. ein Programm zum Monitoring eine Anfrage sendet [3, 7]. Eine weitere Möglichkeit, nämlich Monitoring direkt in das Betriebssystem zu integrieren, wird im nächsten Abschnitt genauer erläutert. Wichtig beim Monitoring ist, dass das System dabei möglicht gering beeinträchtigt wird. Wenn z.b. die Benutzung einer Festplatte aufgezeichnet werden soll, ist es offensichtlich, dass ein Monitoring-Programm, welches die Festplatte zusätzlich beansprucht, die eigenen Ergebnisse verfälschen würde. Allerdings gibt es auch hier unterschiedliche Fälle. Liegt das Interesse darin, die Leistung eines Systems zu messen, sollte das System während es diese Leistung bringt möglichst nicht beeinträchtigt werden. Möchte man allerdings wie bei Power Management üblich messen, wie lange Komponenten nicht gebraucht werden, sollten diese möglichst nicht zur Messung benötigt werden; zumindest nicht, wenn dadurch eine Ruhephase unterbrochen würde. 2.2 Vorstellung eines Systems als Beispiel Beispielhaft wird nun ein an der Universität Bologna in Italien entwickeltes Monitoring System vorgestellt. Die Entwicklung erfolgte in Hinsicht auf den Einsatz, in einem Power Management System für Linux-Rechner. Gesammelt werden können sowohl Daten für online- als auch für offline-analyse. Diese Daten sind Ereignisse, die zu einem bestimmten Zeitpunkt an einer Komponente auftreten. Geachtet wurde darauf, dass die Software den Rechenfluss des Computers möglichst wenig beeinflusst und dass die zu überwachenden Ressourcen nicht vorgegeben, sondern dynamisch wechselbar sind. Außerdem sollte das Monitoring also die Nahme der Zeiten der Ereignisse eine hohe Genauigkeit besitzen [2]. Zunächst wird vorgestellt, welche Erweiterungen an dem Betriebssystem durchgeführt wurden, damit die Komponenten am Monitoring-Prozess teilnehmen können.

3 Welche Struktur dazu zur Verfügung gestellt wird, beschreibt der darauf folgende Abschnitt. Schließlich wird noch auf die Bewertungen des Programms hinsichtlich Funktionalität und Genauigkeit eingegangen. Monitoring von Komponenten Es gibt hauptsächlich zwei unterschiedliche Arten von Ressourcen. Auf der einen Seite stehen Kernkomponenten, wie CPU, RAM, Bus-Controller etc., auf der anderen die weiteren Komponenten, die vom Betriebssystem mittels Device-Treibern verwaltet werden. Letztere wurden für das Programm angepasst; so wird jetzt, bevor die Hardware direkt angesprochen wird und nachdem die Hardware wieder bereit ist, jeweils ein Aufruf ausgeführt, der den Zugriff protokolliert. Bei den zuerst genannten Kernkomponenten musste anders vorgegangen werden, da diese nicht über Device-Treiber angesprochen werden. Wenn keine Rechenarbeit erforderlich ist, wird üblicherweise ein spezieller idle-prozess ausgeführt. Er belegt die CPU für den Zeitraum, in dem sie von keinem neuen Prozess benötigt wird. Diese Eigenschaft wurde für das Monitoring genutzt: Wenn der idle-prozess aktiv wird, sowie vor seiner Beendigung, findet ein Aufruf statt, der wie vorher auch den Zugriff hier also die Zeit, in der die CPU nicht benötigt wird festhält. Architektur Für die Aufrufe zum Speichern der Zugriffe steht eine Prozedur bereit, die als Betriebssystemerweiterung implementiert wurde. Übergeben wird dabei die ID der zu überwachenden Komponente zusammen mit der Art des eingetretenen Ereignisses, also z.b. ob die Komponente aktiviert oder ein Vorgang abgebrochen wurde. Zusammen mit einem Zeitstempel werden diese Daten im Kernelspeicherbereich abgelegt. Dies hat den Vorteil, dass es nicht durch die Auslagerung von Speicherinhalten (Paging) zu zusätzlicher Systembelastung kommt. Nachteilig bei dieser Vorgehensweise ist allerdings, dass nur ein begrenzter Speicherplatz zur Verfügung steht. Bei der online-verarbeitung der Messwerte ist diese Einschränkung belanglos, da der Platz ausreicht, um genügend Daten aufzunehmen, nach denen die aktuelle Benutzungssituation bewertet werden kann. Die Daten können von vorne beginnend wieder überschrieben werden. Möchte man die Daten jedoch offline analysieren, muss der Teil aus dem Kernelspeicher zwischendurch gesichert werden, da bei einer solche Analyse alle Werte wichtig sind. Dadurch werden also zusätzliche Hardwarezugriffe notwendig. Kurz gesagt werden also jeweils beim Beginn und Ende der Benutzung einer Ressource die relevanten Informationen des Ereignisses (Zeitpunkt, Ressource und Art) in einen Speicher geschrieben, auf diesen dann für das Monitoring zurückgegriffen werden kann. Ergebnisse Das Programm wurde sehr systemschonend geplant, so werden nur die essentiellen Ereignisse an Komponenten aufgezeichnet, wobei die Aufzeichnungen an sich eben- 3

4 4 falls ressourcenschonend ablaufen: Die Daten werden in einem geschützten Speicherbereich geschrieben, was Paging präventiert, schwerwiegendere Speicheroperationen werden nur selten beim offline-monitoring benötigt und den Abruf des Zeitstempels erledigt ein generell durch die Hardware realisierter Befehl. Den Nutzen dieser Vorüberlegungen belegen durchgeführte Benchmarks, so benötigte das offline-monitoring des gesamten Systems lediglich eine um 0,38% höhere Prozessorlast, im Vergleich zur Nutzung des Systems ohne Monitoring [2]. Schließlich wurde das Monitoring System für verschiedene Experimente benutzt. Hierfür wurde ein Computer verschiedenen Benutzerprofilen entsprechend genutzt. Dabei wurden verschiedene Komponenten bzw. die Zugriffe darauf aufgezeichnet. Mit den Aufzeichnungen wurden Diagramme und Korrelationen erstellt, aus denen einige Schlüsse gezogen werden konnten, die bei der Erstellung und Konfiguration eines Power Management Systems hilfreich sein können. Konkreter wird darauf später im Abschnitt Einsatzmöglichkeiten eingegangen. 3 Profiling Dieser Abschnitt handelt von Profiling. Zunächst wird ein grober Gesamtüberblick über das Thema gegeben. Verschiedene Ansätze werden vorgestellt, wobei auch Bezug auf einzelne Programme genommen wird. Gprof ist ein Vertreter für herkömmliches Profiling, PowerScope profiliert unter Aspekten des Energieverbrauchs. 3.1 Überblick Was ist Profiling? Profiling befasst sich mit konkreten Anwendungen. Diese Anwendungen werden während der Ausführung verfolgt und der Profiler sammelt Daten über die ausgeführten Aufrufe und Funktionen. Das Augenmerk liegt dabei meist auf Zeitpunkt, Häufigkeit und Dauer bzw. Kosten dieser Aufrufe. Mit den während des Profiling gesammelten Daten kann die Anwendung im Nachhinein analysiert werden. Zweck des Ganzen ist normalerweise die Optimierung hinsichtlich eines bestimmten Schwerpunktes. Es können überflüssige Funktionsaufrufe oder aber Funktionen, deren Abarbeitung unverhältnismäßig viel Rechenzeit, Energie etc. beansprucht, gefunden werden. Ursache hierfür können z.b. unzulängliche Planung der Anwendung oder Fehler während der Implementierung sein [4]. Anhand der Profiling- Protokolle kann nachvollzogen werden, an welcher Stelle unnötige oder verschwenderische Vorgänge stattfanden. Die Anwendung kann dann an den entsprechenden Stellen verbessert werden. Eventuell vermittelt dieser Überblick schon eine erste Vorstellung, dass es viele Profiling-Ansätze aus ganz unterschiedlichen Blickwinkeln geben kann. Je nachdem, welche Daten gemessen werden, können unterschiedliche Ergebnisse zu Tage kommen. Denkbar wäre beispielsweise eine Berechnung, die entweder mit einer komplizierten, viel Rechenleistung benötigenden Funktion oder mit einer einfacheren, aber speicherhungrigen Rekursion durchgeführt werden kann. Dementsprechend würde ein Profiler, der die nötige Rechenleistung misst, die Funktion als verschwenderisch, einer, der den Speicherbedarf misst, jedoch die Rekursion als verschwenderisch entlarven.

5 5 3.2 Herkömmliches Profiling in der Anwendungsentwicklung Eine Möglichkeit für einen Programmierer, seine Anwendungen zu optimieren besteht darin, häufig aufgerufene oder unvorteilhaft implementierte Funktionen mit langer Ausführungszeit ausfindig zu machen und sie schließlich zu verbessern. So kann das gesamte Programm an Geschwindigkeit zulegen. Ein Hilfsmittel für diese Art der Optimierung stellt gprof dar. Genutzt werden kann es, indem es bei der Kompilierung von C-Programmen eingebunden wird. Danach erzeugt das entsprechende Programm bei der Ausführung eine Ausgabedatei, die mit gprof analysiert werden kann. Das Ergebnis ist eine Datei, in der Anzahl und Ausführungsdauer aufgerufener Funktionen aufgelistet sind. Außerdem kann nachvollzogen werden, woher die Aufrufe stammen. [4] Anwendung von gprof Da gprof ein relativ weit verbreitetes Profiling-Tool ist, folgt hier ein kleiner Exkurs, wie gprof eingesetzt wird. Ausgangspunkt ist ein unkompiliertes C bzw. C++ Programm (Abb. 1). Indem man es mit dem Flag -pg (g++ -pg programm.c) kompiliert, wird die oben genannte Erweiterung durchgeführt, damit bei der Ausführung Informationen über die Funktionen und deren Aufrufe innerhalb des Programms in der Ausgabedatei (gmon.out) gesichert werden. Diese Ausgabedatei kann mit einem Aufruf von gprof./a.out gmon.out > gprof.out weiterverarbeitet werden../a.out ist dabei das kompilierte C-Programm und als gprof.out wird eine mittels Texteditor lesbare Datei erstellt. Sie enthält das Profil des Aufruf-Graphen (call graph profile) sowie das flache Profil (flat profile) des analysierten Programms. Im flachen Profil (Abb. 3) ist abzulesen, welchen Teil der Laufzeit eine Funktion erzeugt hat, wie oft sie aufgerufen wurde und schließlich, wie viel Zeit ein Aufruf gekostet hat. Der Aufruf-Graph (Abb. 2) schlüsselt detailliert auf, welche Funktionen von wo aus aufgerufen wurden. Zusätzlich wird die Häufigkeit und Gesamtdauer aller Aufrufe aufgeschlüsselt. Der erste Eintrag sagt z.b. Folgendes aus: Am Index [1] erkennt man, dass die Funktion function1 betrachtet wird. Die 100 besagt, dass die Ausführung der Funktion (mit allen enthaltenen Aufrufen weiterer Funktionen) 100 Prozent der Laufzeit beansprucht hat. Die oberen Zeilen zeigen, von wo aus die Funktion wie oft aufgerufen wurde und welche Rechenzeit sie bei diesem Aufruf benötigt hat. Im Beispiel wurde function mal von main aus aufgerufen. Selbst hat function1 dabei 0,02 Sekunden benötigt. Die Aufrufe, die aus der Funktion heraus stattfanden, haben das System 2,49 Sekunden lang belegt. Bei einem komplexeren Programm könnten natürlich weitere Aufrufe stattgefunden haben, die Liste würde dann länger werden. Bei function2 mit dem Index [4] kommt z.b. noch hinzu, wie oft sich die Funktion selbst aufgerufen hat, da function2 rekursiv ist. In der Mitte steht die Funktion selbst, in dieser Zeile wird gezeigt, wie oft die Funktion insgesamt aufgerufen wurde und wie viel Zeit sie insgesamt verbraucht hat. Bei function2 kommen die eigenen Aufrufe dazu.

6 6 Abbildung 1. Quelltext des Programms, das für die Nutzung mit gprof profiliert wurde. function1 wird in einer Schleife mal aus der main-routine aufgerufen, function2 wird aus function1 und von sich selbst aufgerufen. Abbildung 2. Ein mittels gprof ermitteltes Aufruf-Graph- Profil. Es zeigt welche Funktionen, wie oft und von woher aufgerufen wurden. Unten wird aufgelistet, welche Aufrufe aus der aktuellen Funktion heraus stattfanden. Aus function1 wurde also function mal aufgerufen und hat dabei 2.49 Sekunden Rechenzeit benötigt. Als Schluss aus den durch gprof erstellten Profilen könnte man in unserem Fall ziehen, dass, da function2 sehr oft aufgerufen wird und dabei auch (vgl. Abb. 3) am meisten Rechenzeit pro Aufruf verschlingt, sich eine Optimierung der Funktion als eine Verringerung der Gesamtlaufzeit des Programms bemerkbar machen würde. Ebenfalls zeigt das flache Profil offensichtlich, dass die durch function1 getätigten Aufrufe deutlich mehr Zeit beanspruchen, als die Berechnungen in der Funktion selbst; es ergibt sich also ein weiterer Ansatzpunkt für Optimierungen. 3.3 Anwendungsoptimierung hinsichtlich des Energieverbrauchs Ein nicht ganz so konventioneller Profiling-Ansatz ist es, den Energieverbrauch einzelner Prozesse zu messen. Herkömmliches Profiling achtet meist nur auf die Performanz des Systems, über den für Power Management Ansätze wichtigeren Energieverbrauch trifft es jedoch keine akkuraten Aussagen; diese Lücke soll geschlossen werden. Das Profiling des Energieverbrauchs ist mit neuen Vorüberlegungen verknüpft; am wichtigsten ist die Frage danach, wie der Energieverbrauch überhaupt sinnvoll gemessen werden kann. Ein Computer bietet in der Regel keine Möglichkeit, den Energieverbrauch direkt zu messen, so ist zusätzliche Hardware in Form eines externen Messgerätes erforderlich. Um eine hinreichende Genauigkeit zu bieten, muss

7 7 Abbildung 3. Das flache Profil zeigt an, wie oft eine bestimmte Funktion aufgerufen wurde und wie viel Zeit insgesamt und pro Aufruf dort verbracht wurde. es in geringen Abständen zuverlässige Werte bieten können, da bei zu großen Messintervallen die Auswirkungen kurzer Prozesse verloren gehen können. Ist diese Hürde genommen, sollte man sich Gedanken darüber machen, welche Daten des Systems eine Messung ergänzend gespeichert werden müssen. Außerdem ist die Frage zu lösen, wie die Messdaten mit den Systemdaten synchron genommen werden können. Ein System, das den Energieverbrauch einzelner Prozesse und Prozeduren messen soll, stellt Jason Flinn mit PowerScope in [5] vor. Als Daten über den aktuell laufenden Prozess werden zu jeder Messung Programmzähler (program counter / PC ) sowie Prozess ID (process identifier / PID) assoziiert. Anhand der Prozess ID können im Nachhinein die einzelnen Messwerte einem einzelnen Prozess zugeordnet werden. Die Synchronisation erfolgt über ein Signal, welches das Messgerät nach jeder erfolgten Messung erzeugt. Gespeichert werden die Daten auf einem zweiten Rechner, um die Messwerte möglichst wenig zu verfälschen. Für die anschließende Optimierung einer Anwendung auf geringen Energieverbrauch bleibt anzumerken, dass das Programm auf mehreren Systemen profiliert werden sollte. Einige Anpassungen, die spezifisch für ein System bessere Werte zeigen, können nämlich auf einem anderen System gegensätzliche Auswirkungen haben. [5] Neben dem durch PowerScope verfolgten Ansatz, gibt es noch weitere Verfahren, um den Energieverbrauch von Anwendungen zu messen. Eines nennt sich energy accounting. Für bestimmte Vorgänge der Hardware wird der jeweilige Stromverbrauch gemessen, z.b. den Verbrauch einer Festplatte während der Benutzung, während des Stillstandes und den Übergängen zwischen beiden Zuständen. Während ein Programm ausgeführt wird, wird die entsprechende Benutzung protokolliert. Anschließend werden die vorher ermittelten Verbrauchswerte mit der Häufigkeit der Zugriffe multipliziert, um den Gesamtverbrauch eines Prozesses zu ermitteln. Für einen umfassenden Einsatz müssen viele Messungen vorgenommen werden, jedes unterschiedliche System erfordert neue Messungen. Das andere, ebenfalls in [5] beschriebene Verfahren ist power analysis. Dabei wird mit detaillierten Energiemodellen gearbeitet. Dies kann entweder ein Modell der Hardware (architecture-level) oder ein Modell über den Verbrauch pro Anweisung (instruction-level) sein. Es erfolgen also keine direkten Messungen, sondern Berechnungen über Modelle, daher wird die bestimmte Hardware zur Messung nicht

8 8 benötigt. Ziel dieser Verfahren ist weniger die Optimierung einzelner Programme als viel mehr die Optimierung von Compilern oder die Erforschung neuer Hardwarearchitekturen. Power analysis betrachtet jedoch nur die Kernkomponenten eines Systems, nicht jedoch z.b. den Energieverbrauch des Bildschirms. Des weiteren kann eine Analyse umfangreicher Software unter Umständen zu Problemen führen. 4 Einsatzmöglichkeiten im Kontext Power-Management Da nun die beiden Begriffe, die den Titel dieser Ausarbeitung zieren, hinreichend erklärt wurden, können die Themen nun näher mit der eigentlichen Projektaufgabe verknüpft werden. Hierzu werden sie kurz miteinander verglichen, bevor es schließlich praktischer wird. 4.1 Abgrenzung zwischen Monitoring und Profiling Monitoring überwacht die Ressourcen eines Systems bezüglich deren Auslastung und dem Zeitpunkt der Benutzung. Das Endprodukt dabei sind entweder Statistiken, die eine nachträgliche, genaue Analyse des Nutzungs- und Systemverhalten ermöglichen, oder aktuelle Systemdaten, die in direkte Entscheidungen einfließen können. Profiling zeichnet jeden Schritt einer Anwendung auf, um festzustellen, wann das Programm suboptimal agiert. Mit den richtigen Änderungen an entsprechenden Stellen, kann die Anwendung schließlich angepasst und verbessert werden. Vergleicht man nun diese kurzen Beschreibungen, kann man zumindest einen gemeinsamen Zweck, zu dem die Techniken eingesetzt werden können, erkennen: Auch wenn Profiling meist die Ausführungszeit im Visier hat, können beide letztendlich dabei helfen, Energie zu sparen. Doch man sieht auch einen sehr deutlichen Unterschied: Monitoring liefert Daten auf ein Hardwaresystem die Umgebung vieler Programme bezogen, Profiling hingegen kümmert sich nur um eine spezielle Anwendung. Diese Erkenntnis ist von großer Bedeutung, wenn man die Einsatzmöglichkeiten in einem Power Management System abschätzen möchte, was das weiterführende Ziel dieser Ausarbeitung ist. 4.2 Einsatzmöglichkeiten Ziel von Power Management ist es, ein System während der Laufzeit so zu verwalten, dass möglichst wenig Energie verbraucht wird. Profiling scheint hierfür wenig geeignet, da es hauptsächlich eingesetzt wird, um Software zu optimieren. Einzelne Anwendungen zu optimieren dürfte jedoch kaum Aufgabe von Power Management Systemen sein. Denkbar ist höchstens der indirekte Einsatz von Profiling-Systemen, um allgemein häufig eingesetzte Software zu analysieren, welche Funktionen häufig benutzt werden. Hiervon könnte abgeleitet werden, welche Hardware durch diese Software häufig und in welchen Situationen benutzt wird, woraus beispielsweise folgt, wann sich das Abschalten einer Komponente (wenig) lohnen würde. Eine solche Nutzung verlangt jedoch ausgiebige Vorarbeit und scheint nur wenig Erfolg zu versprechen.

9 Lediglich der Ansatz architekturorientierter Energieanalyse (architecture-level power analysis) befasst sich nicht mit Software, sondern ist dazu geeignet, Hardware zu optimieren. Anpassungen an der Hardware vorzunehmen, widerspräche jedoch dem Ansatz,ein flexibles Power Management System zu entwickeln. Anders als Profiling zielt Monitoring nicht darauf ab, Anwendungen zu optimieren. Monitoring sammelt Daten über die Ressourcen des gesamten Systems. Mit diesen Daten können sowohl umfassende Benutzungsprofile (offline) erstellt, als auch Daten über den aktuellen Zustand des Systems (online) gesammelt werden. Monitoring bietet also sehr gute Vorraussetzungen für den Einsatz beim Power Management. In [2] wurden schon einige Experimente hinsichtlich dieses Einsatzes vorgenommen. Die Ergebnisse werden im folgenden Abschnitt zusammengefasst. Beispielhafte Nutzung von Monitoring Als Grundlage wurde ein ganzes System, während verschiedene, typische Arbeiten auf ihm durchgeführt wurden, protokolliert. Aus den aufgenommenen Daten konnten diverse Informationen gewonnen und als Graphen dargestellt werden. 9 Abbildung 4. Die Graphen zeigen die Zeit zwischen den Zugriffen auf die entsprechende Ressource. Die (obere) dicke Linie gibt die Wahrscheinlichkeitsverteilung an, die gestrichelte ist das zugehörige Komplement. (Quelle: [2]) Abbildung 5. Die Korrelation zwischen der Anzahl an Anforderungen an die Festplatte und anderen Ressourcen in einem Zeitfenster von 100 ms. (Quelle: [2]) Abb. 4 zeigt die Zeit zwischen den Anforderungen an eine Ressource und ihre Wahrscheinlichkeitsverteilung an, während an einem System Software entwickelt wird. Demnach finden gerade an Maus und Festplatte weitere Zugriffe in den ersten Nanosekunden nach einem Zugriff statt, bei der Tastatur hingegen treten in den ersten 50 bis 100 ns kaum erneute Zugriffe auf. Ein weiterer, aus den Monitoring-Daten erstellter Graph (Abb. 5) zeigt die Korrelation des Auftretens von Anforderungen an die Festplatte mit dem Zugriff auf andere Ressourcen, sowie der Festplatte selbst binnen 100 ns. Behält man die Festplatte im Auge, zeigen einem die Graphen interessante Tatsachen: Auf der einen Seite ist die Wahrscheinlichkeit eines weiteren Zugriffs auf

10 10 die Festplatte, wenn sie eine gewisse Zeit (ca. 0,5 s) lang nicht genutzt wurde, sehr gering und andererseits wird durch die Korrelation deutlich, dass Festplattenzugriffe relativ häufig weitere Zugriffe nach sich ziehen. Mit dieser Erkenntnis könnte bereits ein einfaches Power Management System für Festplatten umgesetzt werden: Da eine Festplatte eine gewisse Zeit und Energie benötigt, um vom Stillstand wieder in den Betriebsmodus zu wechseln, sollte vor dem Abschalten der Festplatte hinreichend sicher sein, dass sie eine gewisse Zeitspanne tatsächlich nicht gebraucht wird. Nach dem Korrelationsdiagramm ist der deutlichste Indikator für eine Nutzung der Festplatte die Nutzung der Festplatte. Zieht man nun die Erkenntnis aus Abb. 4 hinzu, kann ab einer längeren Nichtbenutzung der Festplatte tatsächlich davon ausgegangen werden, dass die oben genannte Zeitspanne erfüllt wird. Das Power Management System müsste folglich nur beobachten, wann der letzte Festplattenzugriff erfolgte, um dann nach einer bestimmten Zeitspanne die Festplatte in den Ruhezustand zu versetzen. 5 Zusammenfassung In dieser Ausarbeitung wurden die Begriffe Monitoring und Profiling erläutert und mittels einiger Beispiele veranschaulicht. Dabei wurden auch Grundideen für Implementierungen gegeben. Bei dem Vergleich der beiden Techniken ist deutlich geworden, dass Profiling für das Rahmenprojekt dieser Ausarbeitung wenig geeignet ist, da sein Fokus darauf liegt, Daten für die Optimierung von Anwendungen zu sammeln. Monitoring hingegen liefert Daten über das gesamte System, wie es unter verschiedenen Umständen benötigt wird und reagiert, die auf zwei Weisen eingesetzt werden können. Zum Einen lassen sich aus einer Analyse dieser Daten im Nachhinein wichtige Informationen gewinnen, die beim Entwurf von Power Management Systemen hohen Stellenwert besitzen. Zum Anderen kann ein entwickeltes Power Management System Monitoring wiederum dazu einsetzen, während der Laufzeit Daten zu sammeln, die essentiell für sofortige Entscheidungen des Systems sind. Auch hierzu wurde in der Ausarbeitung ein Beispiel vorgeführt. Literatur 1. Verkhedkar, S.A.: A highly customizable system monitoring and control tool. Technical Report TR99-11 (1999) 2. Benini, L., Bogliolo, A., Cavallucci, S., Riccó, B.: Monitoring system activity for os-directed dynamic power management (1998) 3. Mansouri-Samani, M., Sloman, M.: Monitoring distributed systems (a survey) (1992) 4. Graham, S.L., Kessler, P.B., McKusick, M.K.: gprof: a call graph execution profiler. In: SIGPLAN Symposium on Compiler Construction. (1982) Flinn, J.: Extending mobile computer battery life through energy-aware adaption (2001) 6. Eric, P.T.: Combining software and hardware monitoring for improved power and (2003) 7. Klar, R., Quick, A., Sötz, F.: Tools for a model driven instrumentation for monitoring (1992)