Performance-Modellgenerierung von verteilten Java-Enterprise-Edition-Anwendungen unter Berücksichtigung von CPU-, Memory- und I/O- Ressourcen

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Finance & Information Management Performance-Modellgenerierung von verteilten Java-Enterprise-Edition-Anwendungen unter Berücksichtigung von CPU-, Memory- und I/O- Ressourcen Bernhard Alexander Koch-Kemper

2 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Finance & Information Management Performance-Modellgenerierung von verteilten Java-Enterprise-Edition-Anwendungen unter Berücksichtigung von CPU-, Memory- und I/O- Ressourcen Performance Model Generation of Distributed Java Enterprise Edition Applications considering CPU, Memory and I/O Resources Bearbeiter: Bernhard Koch-Kemper Aufgabensteller: Prof. Dr. Helmut Krcmar Betreuer: Felix Willnecker Abgabedatum: 21. September 2015

3

4 Erklärung Ich versichere, dass ich diese Master s Thesis selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Garching b. München, den <Datum> Ort, Datum Unterschrift

5 Zusammenfassung Um universell anwendbar zu sein, müssen Ressourcen-Profile auf Basis von Performance- Modellen alle relevanten Aspekte eines Anwendungssystems repräsentieren. Neben der Software-Architektur und der Deployment-Struktur sind auch die betrachteten Hardware- Ressourcen ein großer Einflussfaktor in diesen Modellen. Grundlage für die automatisierte Erstellung der Modelle liefern Messdaten, die während des laufenden Betriebs erhoben werden, da die Kosten einer manuellen Modellierung deren Nutzen oft übersteigt. Zugehörige Simulations-Frameworks erzeugen auf Basis der Modelle Vorhersagen zu Performance- Metriken wie Antwortzeit, Durchsatz und Ressourcen-Auslastung. Die Erhebung der Messdaten ist in vielen Fällen nicht einfach, was dazu führt, dass beispielsweise nur eine Teilmenge der Hardware-Ressourcen abgebildet wird. Um die Lücke auf dem Weg zu einem holistischen Ressourcen-Profil zu schließen, müssen insbesondere die Memory- und die HDD-Ressourcen untersucht werden, welche in der Literatur bezüglich Performance- Modellgenerierung oft ausgeklammert werden. In dieser Arbeit werden Techniken zur Erhebung und Abbildung der beiden Ressourcen entwickelt. Mithilfe des RETIT-Frameworks kann so eine Industrie-Benchmark-Applikation unter Berücksichtigung aller relevanten Ressourcen modelliert und Performance-Metriken vorhergesagt werden. Stichworte: Performance-Modell, Deployment Unit, Garbage-Collection-Simulation, Heap, I/O, Festplatte, Kapazitätsplanung, Palladio Component Model, Software Performance Engineering. Abstract To use resource profiles based on performance models universally they must be able to represent all relevant aspects of an enterprise application. Software architecture, deployment structure and hardware resources have a big impact in these models. Because creating such models manually often outweighs their benefits, the automatic generation must be based on measurement data which is extracted from a running application. Simulation frameworks further use these models to predict performance metrics (e.g. response time, throughput and resource utilization). The extraction of all relevant measurement data is difficult and therefore often only a subset of resources is included in the models. To fill this gap, this thesis focusses on the extraction and representation techniques for memory and hard disk drives as these resources are often excluded in the literature. Using the RETIT framework for automatic performance model generation an industry benchmark is used as an example enterprise application to evaluate performance predictions based on all relevant measurement data to predict performance metrics. Keywords: Performance Model, Deployment Unit, Garbage Collection Simulation, Heap, I/O, Hard Disk Drive, Capacity Planning, Palladio Component Model, Software Performance Engineering. III

6 Inhaltsverzeichnis Zusammenfassung... 3 Inhaltsverzeichnis... 4 Abbildungsverzeichnis... 6 Tabellenverzeichnis... 7 Abkürzungsverzeichnis... 8 Einleitung Motivation Ziele der Masterarbeit Forschungsfragen Methodik Nutzen der Arbeit Grundlagen Betriebliche Anwendungssysteme Hardware-Ressourcen CPU-Ressource MEM-Ressource HDD-Ressource NET-Ressource Queuing und Scheduling von Hardware-Ressourcen Performance und Metriken Das Palladio Component Model als Ressourcen-Profil Ressourcen-Profil Das Palladio Component Model RETIT-Framework Java-EE-Technologien Übersicht relevanter Messwerkzeuge für Memory- und HDD-Ressourcen Verwendete Messwerkzeuge für Memory- und HDD-Ressourcen in der Literatur Weitere HDD-Messwerkzeuge Das /proc-dateisystem Per-Task Statistics Interface PostgreSQL pg_statistics Java Mission Control SIGAR Zusätzliche Betriebssystem-Werkzeuge IV

7 3.3 Weitere Memory-Messwerkzeuge RETIT JMX-Logger HeapAudit Schlussbemerkungen zur Auswahl der Werkzeuge Integration und Abbildung der Memory- und HDD-Messdaten in dem RETIT-Framework Architekturübersicht der Messdatenerhebung im RETIT-Framework HDD Integration und -Abbildung Messdatenerhebung der HDD Demands auf Operations-Granularität Abbildung der HDD-Ressource und Demands in PCM Memory-Integration und -Abbildung MEM Demands und deren aktuelle Modellierung im RETIT-Framework Das Java-Speichermanagement und eine darauf angepasste PCM-Modellierung 40 5 Evaluation der Modellgenerierung Der SPECjEnterpriseNext-Benchmark Faban Framework und Driver Insurance Domain und Microservices Testumgebung und -Methodik Hardware-Ausstattung und verwendete Software Testmethodik Experimentauswertung Zusammenfassung und Ausblick Literaturverzeichnis Anhang V

8 Abbildungsverzeichnis Abbildung 1: Beispielhafte Architektur eines verteilten Anwendungssystems... 5 Abbildung 2: Transaktionen eines verteilten Anwendungssystems... 6 Abbildung 3: Komponenten und Operationen einer Transaktion... 7 Abbildung 4: Schematische Darstellung von Komponenten und Deployment Units... 8 Abbildung 5: Heap-Generationen Abbildung 6: Schematische Abbildung der Nutzung von Hardware-Ressource Abbildung 7: Ressourcen-Profil Abbildung 8: Das Palladio Component Model Abbildung 9: Java EE Web Container Abbildung 10: Java EE EJB Container Abbildung 11: Schematische Architektur des RETIT-Monitoring-Frameworks Abbildung 12: Schematische Abbildung der HDD-Ressource im PCM Resource Environment Abbildung 13: Schematische Abbildung der HDD Demands im PCM Repository Model Abbildung 14: MEM-Abbildung im PCM Repository Model Abbildung 15: MEM-Nutzung einer Operation im PCM Repository Model Abbildung 16: GC-Heap-Interface-Erweiterung im PCM Repository Model Abbildung 17: GC-Ausführung im PCM Repository Model Abbildung 18: GC Event Trigger im PCM Usage Model Abbildung 19: Insurance Domain Web Flow Abbildung 20: Architektur der Insurance Domain Abbildung 22: Gemessene und simulierte RT bei 100 Nutzern Abbildung 22: Gemessene und simulierte RT bei 120 Nutzern Abbildung 24: Gemessene und simulierte RT bei 140 Nutzern Abbildung 24: Gemessene und simulierte RT bei 160 Nutzern VI

9 Tabellenverzeichnis Tabelle 1: Definition der Auslastungen von Hardware-Ressourcen Tabelle 2: Beispielausgabe von /proc/pid/tasks/tid/io Tabelle 3: Overheadanalyse des /proc-dateisystems Tabelle 4: Testumgebung der Evaluation Tabelle 5: Abkürzungensübersicht der Evaluation Tabelle 6: Auswertung der Ressourcen-Auslastung Tabelle 7: Auswertung der Response-Times je Business Transaction VII

10 Abkürzungsverzeichnis AJAX Asynchronous JavaScript and XML API Application Programming Interface APM Application Performance Management AwS Anwendungssystem CPU Central Processing Unit, Prozessor CSV Comma Separated Value EJB Enterprise Java Beans GC Garbage Collection GUI Graphical User Interface HDD Hard Disk Drive, Festplatte HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure I/O Input/Output Java EE Java Platform, Enterprise Edition JAX-RS Java API for RESTful Web Services JDBC Java Database Connectivity JMC Java Mission Control JMX Java Management Extension JNI Java Native Interface JPA Java Persistence API JSF JavaServer Faces JSON JavaScript Object Notation JSP JavaServer Pages JVM Java Virtual Machine MBeans Managed Beans MEM Memory, Arbeitsspeicher ms Millisekunde NET Network, Netzwerk PCM Palladio Component Model PMW Performance Management Work SEFF Service Effect Specification RDSEFF Resource Demanding Service Effect Specification REST Representational State Transfer RT Response Time s Sekunde SPE Software Performance Engineering SPEC Standard Performance Evaluation Corporation SQL Structured Query Language SUT System Under Test UML Unified Modeling Language URL Uniform Resource Locator VM Virtuelle Maschine VIII

11 Einleitung 1.1 Motivation Bei der Planung und Entwicklung von Anwendungssystemen (AwS) spielt die Performance eine entscheidende Rolle. Sie wird durch Metriken wie die Antwortzeit, Durchsatz oder Ressourcenverbrauch beschrieben (Becker et al., 2009) und beeinflusst somit sowohl die Akzeptanz bei Endanwendern als auch die Hardware-, Software- und Energie-Kosten des AwS. Performance ist somit ein wichtiges Qualitätsmerkmal. Um Performance-Ziele sicherzustellen und zu erreichen, existieren Werkzeuge wie Performance-Modelle. Diese sind ein abstraktes Modell des AwS, welches sich beispielsweise aus Merkmalen wie der Softwarearchitektur, der Hardwareinfrastruktur oder dem Nutzerverhalten zusammensetzt. Mittels einer analytischen Lösung oder Simulation des Modells kann dann eine Vorhersage bezüglich der Performance-Metriken des AwS getroffen werden. Heutige AwS sind sehr komplex und bestehen in der Regel aus vielen Software- Komponenten. Diese Komponenten werden wiederum in sogenannten Deployment Units gebündelt. Neben der Bündelung in einer einzigen Deployment Unit können Komponenten hiermit auch separiert werden. So ist es möglich, ein verteiltes AwS aufzusetzen, bei dem die Komponenten auf verschiedenen Hardwareumgebungen eingesetzt werden und zusammenwirken. Um die Skalierbarkeit des AwS zu erhöhen können gleiche Deployment Units auch simultan auf verschiedene Hardwareumgebungen in Betrieb genommen werden. Load Balancer sorgen dann für eine effiziente Lastverteilung beide Systeme. Aufgrund der Komplexität heutiger AwS kann eine manuelle Performance-Modellierung sehr zeitaufwändig sein. Sie ist zudem fehlerbehaftet und kann zu falschen Vorhersagen führen, da beispielsweise vom Modellierer ein ungünstiger Abstraktionsgrad für das Modell des AwS gewählt wurde, der wesentliche Performance-Einflussfaktoren nicht abbildet. Der Aufwand einer manuellen Performance-Modellierung wird somit oft erst gar nicht betrieben, da er den Nutzen übersteigt (Koziolek et al., 2011). Es existieren deshalb in der Literatur Ansätze, die die Performance-Modellgenerierung auf Grundlage einer Menge an Messdaten (semi-) automatisieren (Brosig, Huber, & Kounev, 2011; Brunnert, Vögele, & Krcmar, 2013). Hierdurch wird der zeitliche Aufwand minimiert und die Bestimmung der für Operationen verbrauchten Hardware-Ressourcen erhöht, wenn möglichst feingranulare Messdaten aller Kontrollflüsse des laufenden Systems zur Erstellung verwendet werden. Diverse Ressourcen wie die Prozessoren (CPUs), der Arbeitsspeicher/Memory (MEM), Netzwerkzugriffe (NET), das Lesen und Schreiben von Daten auf Speichermedien 1 (HDD, genauer: HDDread und HDDwrite) oder Zugriffe auf externe Systeme wie Datenbanken haben Einfluss auf die Performance des AwS. Die bislang bekannten Ansätze für eine automatisierte Modellgenerierung bilden oft nur eine Teilmenge dieser Ressourcen in den Modellen ab. Dies ist oft schon ausreichend für eine genaue Performance-Vorhersage, da diejenigen Ressourcen (wie die CPU) abgebildet werden, die in der Regel einen großen Einfluss auf die Performance des AwS haben. Da es je nach Anwendungsfall aber auch 1 Zugriffe auf das Netzwerk oder Speichermedien werden oft unter dem Begriff Input/Output (I/O) subsummiert. 1

12 Systeme gibt, deren Performance sehr stark von der MEM- oder der HDD-Ressource abhängen, sollten möglichst viele Ressourcenarten in die Modelle integriert werden, um das AwS genauer abzubilden und die Vorhersagefähigkeit zu optimieren. 1.2 Ziele der Masterarbeit Um holistische Performance-Modelle zu generieren, die nicht nur eine Teilmenge der Hardware-Ressourcen abbilden, müssen im Betrieb des AwS Messdaten für diese Ressourcen erhoben werden. Das erste Ziel ist folglich die Bestimmung und die Auswahl dieser Werkzeuge, mit denen Memory- und I/O-Messdaten auf der Granularität von Operationen gemessen werden können. Dies wird in Kapitel 3 diskutiert. Nach der Auswahl geeigneter Werkzeuge zur Erhebung der Memory- und I/O- Messdaten sollen diese danach für die Erstellung von Ressourcen-Profilen genutzt werden. Hierfür bietet sich die Verwendung des RETIT-Frameworks (RETIT, 2015) an, welches unter anderem aus einer Java-EE-Monitoring-Lösung und einem Performance-Modellgenerator besteht. Mit ersterer können Messdaten von Ressourcen einer laufenden Java-EE-Applikation erhoben werden. Der Modellgenerator ermöglicht darauf aufbauend die automatisierte Erzeugung des Ressourcen-Profils. Als Meta-Modell wird hierbei das Palladio Component Model (PCM) (Becker et al., 2009) verwendet. Diese Umsetzung wird in Kapitel 4 beschrieben. Die Integration von Memory- und I/O-Messdaten für die Modellgenerierung muss anschließend analysiert werden. Angelehnt an die bestehenden Evaluationen (Brunnert et al., 2013; Brunnert, Wischer, et al., 2014; Willnecker, Brunnert, Gottesheim, & Krcmar, 2015) soll hierbei jedoch eine aktuellere Java-EE-Benchmark-Applikation der nächsten Generation ausgewählt werden. Software-Komponenten des Benchmarks sollen hierbei in verschiedene Deployment Units gebündelt und separat in einer verteilten Hardwareumgebung eingesetzt werden, um das in Kapitel 2 motivierte verteilte AwS aus dem betrieblichen Kontext widerzuspiegeln. 1.3 Forschungsfragen Aus den Zielen ergeben sich drei Forschungsfragen: Forschungsfrage 1: Welche Ansätze, Memory- und I/O-Ressourcen auf Operationsebene zu messen oder zu approximieren, existieren in der Literatur? Das Ziel bei der Beantwortung dieser Forschungsfrage ist es, geeignete Werkzeuge zu finden, mit denen Memory- und I/O-Ressourcen gemessen werden können. Hierzu sollte eine Übersicht mit themenrelevanter Literatur erstellt werden, um bereits verwendete Werkzeuge und Methoden gezielt ausfindig machen zu können. Für die Memory-Ressourcen kann hierbei eventuell auf bekannten Ansätzen wie in Brunnert et al. (2013) aufgebaut werden. Aktuell ist der Ansatz jedoch mit Problemen verbunden, da die Memory-Messinstrumentierung auf Operations-Granularität einen großen Overhead erzeugt, der Auswirkungen auf das Messen anderer Ressourcen (CPU) hat (Brunnert, Neubig, & Krcmar, 2014). Forschungsfrage 2: Wie können Messwerte der Memory- und I/O-Ressourcen zweckmäßig in ein komponentenbasiertes Performance-Modell überführt werden? 2

13 Das Ziel dieser Forschungsfrage ist es herauszufinden, wie die RETIT-Monitoring-Lösung und der Modellgenerator mit dem zugehörigen Datenmodell angepasst werden müssen, um Memory- und I/O-Ressourcen zu berücksichtigen und eine bestmögliche Performance- Vorhersage zu gewährleisten. Da für die Repräsentation von Memory-Messdaten bereits ein Ansatz existiert, muss überprüft werden, inwieweit dieser wiederverwendet oder erweitert werden kann. Als Anhaltspunkt könnte beispielsweise das dynamische Speichermanagement dienen, welches aktuell nicht im Modell abgebildet wird. Für die Integration von I/O-Messdaten ist neben einer Anpassung und der Messerhebung und des Datenmodells auch die eigentliche Modellgeneration interessant, da I/O im RETIT- Framework zwar in Form der NET-Ressource aber nicht in Form der HDD-Ressource modelliert wird. Hierbei muss sichergestellt werden, dass der Prozess der Modellgenerierung automatisiert werden kann. Forschungsfrage 3: Welche Unterschiede in Genauigkeit und Funktionalität ergeben sich durch den Einsatz der zusätzlichen Integration von Memory- und I/O-Ressourcen für eine verteilte Benchmark-Applikation? Das Ziel dieser Forschungsfrage ist die Beantwortung, welche Auswirkungen die neu hinzugefügten Messdatenarten oder Modellierungserweiterungen auf die Performance- Vorhersage haben. Hier muss die Vorhersage in Form von Antwortzeiten oder Ressourcenauslastungen auf Systemebene überprüft werden. 1.4 Methodik Um die erste Forschungsfrage zu beantworten, bietet sich eine Literaturrecherche (angelehnt an Webster und Watson (2002)) an. Hauptbestandteile bezüglich einer Klassifikation der Werkzeuge und Approximationsmöglichkeiten sind die Verwendbarkeit des Datenformats, mit dem man die Messdaten erheben kann sowie deren Granularität, da die RETIT- Modellgenerierung Messdaten auf Operations-Granularität verwendet. Die Messdaten müssen automatisiert in den Modellgenerierungsprozess eingefügt werden können. Als Ergebnis entsteht somit ein Literaturüberblick inklusiv einer Bewertung der einzelnen Werkzeuge und Messansätze/Methoden. Für die Beantwortung der zweiten Forschungsfrage eignet sich als Methode die von Hevner, March, Park, und Ram (2004) beschriebenen Design-Science-Leitlinien. Es muss hierbei die RETIT-Messinstrumentierung erläutert und angepasst werden, um die neuen Messdaten auf Grundlage verschiedener Deployment Units zu repräsentieren. Ebenso müssen die Anpassungen, die dadurch in der Modellgenerierung entstehen, beschrieben werden. Um die dritte Frage zu beantworten, wird ein Controlled Experiments nach Hevner et al. (2004) durchgeführt. Hierfür wird eine (Benchmark-)Applikation ausgewählt und verwendet werden. Auf Basis dieser laufenden Applikation werden durch eine Minimalinstrumentierung Performance-Metriken wie die Antwortzeit oder die Ressourcen-Auslastungen gemessen. Anschließen wird in einem zweiten Schritt die Applikation mit der RETIT-Monitoringlösung (inkl. der Erweiterung für Memory und I/O) instrumentiert und aus den so erzeugten 3

14 Messdaten mit dem Modellgenerator ein Performance-Modell erstellt. Dieses Modell wird simuliert und die daraus errechneten Performance-Metriken werden mit denen aus dem vorhergehenden Schritt verglichen. Dies dient dazu, die Vorhersagefähigkeit des Modells einzuschätzen. Die Applikation muss sich in beiden Testläufen nahezu deterministisch verhalten, damit die Performance-Metriken vergleichbar sind. Als Applikation bietet sich die Aktualisierung des bereits für vorhandenen Evaluationen (vgl. z.b. Brunnert und Krcmar (2015)) verwendeten Java-EE-Benchmarks SPECjEnterprise2010 (SPEC, 2015b) an. Diese wird unter dem Namen SPECjEnterpriseNext aktuell noch weiterentwickelt und liegt der Performance Management Group (fortiss, 2015a) in einer Vorabversion vor. Um die Applikation zu betreiben ist ein Lasttest nötig. Dieser simuliert eine bestimmte Anzahl an gleichzeitigen Nutzer und dient dazu, die Ressourcen des Systems auszulasten. An dem laufenden System können so Messdaten auf Basis dieses charakteristischen Workloads erhoben sowie Performance-Metriken wie Response Times angegeben werden. Da aktuell noch kein vollständiger Lasttest vorhanden ist, muss dieser auf Basis des Faban-Frameworks (Faban, 2015) erweitert werden. 1.5 Nutzen der Arbeit Die aus der ersten Forschungsfrage resultierende Übersicht über die Methodik und dazugehörige Werkzeuge, um sowohl Memory- als auch I/O-Ressourcen zu erheben, liefert einen Ansatz, der nicht nur für die eigene Integration in die RETIT-Lösung sondern für auf Messdaten basierende Performance-Modelle allgemein interessant ist. Die Integrationsmöglichkeit von Memory- und I/O-Messdaten in die RETIT-Monitoring- Lösung generalisiert das Framework. Dadurch, dass weitere Messdatenarten integriert werden, ist besonders von einer besseren Performance-Vorhersage für Applikationen auszugehen, die nicht maßgeblich von der CPU-Ressource abhängig sind. Zudem können Anpassungen der generierten Modelle (beispielsweise durch eine realistischere Abbildung des Speichermanagements der MEM-Ressource) die Performance- Vorhersage weiter verbessern. Die Arbeit leistet zudem einen Beitrag dazu, die Verwendung von Performance-Modellen in der Praxis attraktiver machen. Durch die Integration weiterer Messdatenarten auf Basis verschiedener Deployment Units haben Unternehmen die Möglichkeit, Teile ihres IT- Kapazitätsmanagements weiter zu verbessern und die Ressourcennutzung detaillierter zu analysieren. 4

15 2 Grundlagen Dieses Kapitel legt den Grundbaustein zum Verständnis der Arbeit. Abschnitt 2.1 dient dazu, wichtige Begriffe aus dem Umfeld von verteilten betrieblichen Anwendungssystemen zu erläutern. Insbesondere die Architektur auf Basis der heute oft verwendeten komponentenbasierten Software-Entwicklung (Jifeng, Li, & Liu, 2005) und die Verteilung der Anwendung auf verschiedene Deployment Units spielt hierbei eine wichtige Rolle. Da für die Performance-Vorhersage nicht nur die Software allein sondern auch immer die Hardware eine Rolle spielt, werden auch die von einem AwS gebräuchlichsten Hardware- Ressourcen dargestellt. Hierbei wird insbesondere auf die in der Arbeit fokussierte Memoryund HDD-Ressource eingegangen. Für erstere wird ein oft verwendetes Ressourcen- Management zur Laufzeit beschrieben. Für die Performance-Vorhersage wird in dieser Arbeit ein Ressourcen-Profil auf Basis des PCM-Performancemodells verwendet. Dies wird in Abschnitt 2.4 vorgestellt. Dabei wird anschließend auch auf das hierfür verwendete RETIT-Framework eingegangen (Abschnitt 2.5) sowie auf wichtige in dieser Arbeit verwendete Technologien (Abschnitt 2.6). 2.1 Betriebliche Anwendungssysteme Anwendungssystem und Anwendungssoftware In der Literatur werden die Begriffe Anwendungssystem und Anwendungssoftware unterschieden (Schwarzer & Krcmar, 2010). Anwendungssoftware (oft auch als Anwendung oder Applikation bezeichnet) bezeichnet hierbei das eigentliche Programm, welches für einen bestimmten Anwendungszweck geschrieben wurde. Ein Anwendungssystem hingegen Abbildung 1: Beispielhafte Architektur eines verteilten Anwendungssystems Quelle: Wischer (2014) 5

16 inkludiert die für die Anwendungssoftware nötige Gesamtheit an Hard- und Software. Bei Anwendungssystemen im betrieblichen Kontext handelt es sich oft um verteilte Anwendungen. Sie werden von mehreren Nutzern oft parallel mithilfe von Webtechnologien genutzt und kommunizieren bzw. tauschen Daten über Netzwerkverbindungen aus. Die verteilten Anwendungen werden hierbei oft in Form von drei Schichten (Leff & Rayfield, 2001) kategorisiert: Die Präsentations-, die Geschäftslogik- und die Datenhaltungsschicht. Während die primäre Aufgabe der Systeme der Datenhaltungsschicht die (langfristige) Speicherung von Daten ist, stecken in der Geschäftslogikschicht die nötigen Systeme für die Prozessierung von diesen Daten, dem Anwendungszweck dienen. Die Präsentationsschicht dient den Nutzern als Interaktionsschnittstelle für das Anwendungssystem und bereitet die von der Geschäftslogik prozessierten Informationen auf. Um die Skalierbarkeit (z.b. in Bezug auf die Anzahl der gleichzeitigen Nutzer des Systems) zu gewährleisten werden die Anwendungen oft auf verschiedenen Serversystemen betrieben. Zudem können gleiche Anwendungen redundant auf verschiedenen Servern betrieben werden. Mittels eines Load Balancers kann so beispielsweise die Last der Nutzeranfragen auf das System gleichmäßig verteilt werden, um Flaschenhälse zu vermeiden. Abbildung 1 zeigt beispielhaft ein hier beschriebenes Anwendungssystem. Anwendungssysteme bestehen aus einer Menge an Operationen, welche in der Systementwicklung Methode genannt werden. Operationen implementieren hierbei immer eine kleine Funktionalität, welche zur Lösung einer bestimmten Teilaufgabe des Systems nötig ist. Diese Aufteilung der für die Lösung einer Aufgabe nötigen Elemente wird oft als Separation of Concerns bezeichnet. Abbildung 2: Transaktionen eines verteilten Anwendungssystems Quelle: Angelehnt an Brunnert und Krcmar (2015) Operationen müssen sich deshalb auch gegenseitig bzw. verschachtelt aufrufen können, um komplexere Aufgaben zu lösen. Die Abfolge an Operationen, die von der Anfrage einer 6

17 Lösung bis zu ihrer Antwort aufgerufen werden, bezeichnet man deshalb ferner als sogenannten Kontrollfluss. Eintreffenden Nutzeranfragen können somit zum Beispiel über die Abfolge an Operationsaufrufen unterschieden bzw. definiert werden. Man subsummiert diese logisch/programmatisch zusammenhängenden Operationen dann zu einer Transaktion. Somit wird die vom Anwendungssystem bereitgestellte Funktionalität immer über die Ausführung einer oder mehrerer Transaktionen durchgeführt (Smith, 2007). Abbildung 2 veranschaulicht, wie sich der Kontrollfluss verschiedener Transaktionen (T) in einem verteilen Anwendungssystem über Servergrenzen zusammensetzen könnte. Hierbei wurden mehrfache Operationsaufrufe einer Transaktion auf denselben Server abstrahiert. Komponenten und Deployment Units Der Sytementwicklungsprozess heutiger Anwendungssoftware ist sehr komplex und bedarf deswegen einer Unterteilung in sogenannte Software-Komponenten. Hierbei wird ausgenutzt, dass verschiedene Funktionalitäten bzw. Operationen des Systems logische Einheiten bilden. Diese logischen Einheiten werden als Komponente aggregiert und können getrennt entwickelt werden, was man in der Literatur oft aus Component Based Software Engineering (CBSE) (Jifeng et al., 2005) bezeichnet. Definierte Schnittstellen zwischen den Komponenten garantieren die Interaktion beziehungsweise Abhängigkeit zu anderen Komponenten, die für den Betrieb des Anwendungssystems notwendig ist. Insbesondere in einer verteilten Umgebung wie in Abbildung 1 können Abhängigkeiten über Servergrenzen hinweg bestehen, sodass Komponenten unabhängig einer konkreten Hardwareumgebung entwickelt werden können. Ti Component c1 Operation o1 Component c1 Operation o2 Component c2 Operation o1 Abbildung 3: Komponenten und Operationen einer Transaktion Quelle: Angelehnt an Brunnert und Krcmar (2015) Neben einer besseren Skalierbar des Systems aufgrund von Komponenten können sich Entwickler auf die Implementierung einzelner Komponenten spezialisieren, was die Komplexität im Entwicklungsprozess reduziert. Zudem kann die Aufteilung in Komponenten auch weitere Kosten sparen, da Programmcode für die Realisierung einer Funktionalität nicht neu geschrieben werden muss, sondern einfach eine bestehende Komponente 7

18 wiederverwendet werden kann. Abbildung 3 zeigt beispielhaft wie sich eine Transaktion i aus den Operationsaufrufen verschiedener Komponenten zusammensetzen kann. Ein komplexes Anwendungssystem, welches auf Basis des CBSE entwickelt wurde, besteht sodann aus sehr vielen (kleinen) Komponenten. Bei Inbetriebnahme des Anwendungssystems würde hierdurch beispielsweise die Zuordnung der vielen Komponenten auf eine Hardwareumgebung/Server schwierig und unübersichtlich. Als Lösung wird deswegen eine weitere Aggregationsstruktur benutzt. Hierbei werden einzelne Komponenten zu sogenannten Deployment Units gebündelt (vgl. Abbildung 4). Auf einer Hardwareumgebung/Server werden so immer Deployment Units in Betrieb genommen und nicht einzelne Komponenten direkt. Deployment Unit 1 Deployment Unit 2 Component c1 Component c3 Component c2 Deployment Unit i Component cj Component cl Component ck Component cm Abbildung 4: Schematische Darstellung von Komponenten und Deployment Units Quelle: Angelehnt an Brunnert und Krcmar (2015); Wischer (2014) Mehrere verschiedene Deployment Units können hierbei schlussendlich auf denselben Hardwareumgebungen/Server in Betrieb genommen werden. Oft würde man aber beispielsweise in der Praxis die in Abbildung 1 dargestellte Unterscheidung von Präsentations-, Geschäftslogik- und Datenhaltungsschicht in mindestens drei verschiedenen Deployment Units bündeln und auf verschiedenen Servern in Betrieb nehmen. 2.2 Hardware-Ressourcen Für den Betrieb einer Anwendungssoftware sind in der Regel mehrere verschiedene Hardware-Ressourcen notwendig. Beispiele für weitläufig eingesetzte Hardware-Ressourcen sind der Prozessor (CPU), der Arbeitsspeicher/Memory (MEM), die Netzwerkverbindung (NET) und die Festplatte (HDD). Hardware-Ressourcen bieten jeweils eine Leistungserbringung an, die von Systemelementen nachgefragt wird (Woodside, Franks, & Petriu, 2007). Konkret benötigt beispielsweise die Operation eines Sortieralgorithmus eine gewisse Zeiteinheit der CPU-Ressource zur Berechnung einer mathematischen Funktion. 8

19 Des Weiteren werden für die Abarbeitung einer Operation oft verschiedene Ressourcen gemeinsam und nicht einzeln genutzt. Wenn für den Sortieralgorithmus beispielsweise zwei Zahlen verglichen werden, müssen diese in den Registern/Caches der CPU vorliegen. Andernfalls muss auf den Arbeitsspeicher zugegriffen werden, der die Zahlen beispielsweise durch eine Leseoperation auf der Festplatte erhalten hat (Tanenbaum, 2001, S. 189). Ebenso kann eine Operation auf die vollständige Übertragung von Informationen der Netzwerk- Ressource warten müssen, bevor die CPU diese Informationen prozessieren kann CPU-Ressource Wenn eine Operation die CPU-Ressource nutzt, ist damit die Anzahl der Taktzyklen gemeint, die die CPU für die Prozessierung der Operation benötigt. Diese kann man in eine gebräuchliche Zeiteinheit umrechnen. Beispielsweise ist ein Taktzyklus bei einer CPU mit 1 GHz genau 1 Nanosekunde lang. Die Auslastung der CPU-Ressource wird ferner immer in Bezug auf ein Zeitintervall (zum Beispiel 1s) angegeben. Bei einem Doppelkernprozessor, bei dem ein Kern 1s lang durch genau eine Operation belegt ist, beträgt die Auslastung in diesem Zeitintervall 50% MEM-Ressource Operationen nutzen oft viele (temporäre) Variablen und Datenstrukturen, um Informationen/Ergebnisse zwischen zu speichern oder zu verwalten. Die Memory-Ressource hat eine gewisse Kapazität an Speicher, die dafür genutzt werden können. Da viele Operationen den Speicher nutzen, ist es wichtig, dass dieser frei gegeben wird, wenn die Operation abgearbeitet ist und Teile des Speichers deswegen nicht mehr benötigt werden. Für dieses sogenannte Speichermanagement gibt es verschiedene (automatische) Techniken. Einmal kann zum Beispiel ein zusätzliches Werkzeug zur Laufzeit nach nicht-genutzten Speicher suchen und diesen freigeben, andererseits kann man die Allokation und De- Allokation von Speicher auch manuell vom Programmierer vornehmen lassen. Da bei einer zu hohen Auslastung der Memory-Ressource die Anwendungssoftware abstürzen kann, ist es wichtig, deren Auslastung gründlich für einen stabilen Betrieb hin zu überprüfen. Da diese Arbeit die Java-Technologie verwendet, wird immer folgenden das dort verwendete Laufzeit-Speichermanagement genauer vorgestellt. Java-Speichermanagement: Heap und Garbage Collection Beim Starten der JVM wird die MEM-Ressource in drei Bereiche eingeteilt (Subraya, 2006, S. 251): - Heap: Dieser Speicherbereich wird zur Laufzeit genutzt, wenn die JVM Speicher allokiert (beispielsweise um Objekte oder Arrays zu erzeugen). Die Größe des Heaps kann fix sein oder zur Laufzeit variabel (je nach Einstellung/Algorithmus). - Non-Heap: Dieser Bereich speichert geladene Klassenstrukturen und Metadaten, die von mehreren Threads gemeinsam genutzt werden können. Beispiele sind Klassenvariablen. 9

20 - Eigener JVM-Code: Die JVM selbst benötigt Speicher. Wenn zum Beispiel Laufzeitoptimierungen vorgenommen werden und nativer Maschinencode erzeugt wird, liegt dieser hier vor. Da der Heap in der Praxis deutlich größer als die beiden anderen Verwendeten Speicherbereiche ist, wird im Folgenden MEM mit Heap gleichgesetzt. Anders als beispielsweise in C geben Java-Entwickler Speicher nicht explizit frei. Für die direkte Freigabe eines gezielten Speicherbereichs existieren hierfür auch gar keine Methoden. Das Setzen einer Objektreferenz auch null bewirkt keine direkte Freigabe auf dem Heap. Java verwendet für das Speichermanagement die sogenannte Garbage Collection (GC) (Oracle, 2015a). Hierbei wird mittels Algorithmen nach nicht mehr genutzten Allokationen im Speicher gesucht und dieser dann automatisch freigegeben. Im Folgenden werden die Techniken der oft verwendeten HopSpot VM (Oracle, 2015a, 2015k) untersucht. Ausgangsbasis ist die Unterteilung des Heaps in mehrere Teilbereiche (Generations). Als Kriterium, welche Objekte zu welcher Generation zugeordnet werden, entscheidet die Lebensdauer der dortigen Objekte (Oracle, 2015a). Hierbei liegt die These zu Grunde, dass viele Objekte schnell freigegeben werden können und es wenig Verbindungen zwischen langlebigen und kurzlebigen Objekten gibt. Die Generations der HotSpot-Heapstruktur sind in Abbildung 5 dargestellt. Die Aufteilung der Objekte in Generations hat den Vorteil, dass separat eine Garbage Collection für einzelne Generations stattfinden kann. So kann die durchschnittliche Zeit einer Garbage Collection zum Beispiel gesenkt werden, weil nicht der gesamte Heap betrachtet wird. Ebenso ist es so möglich, für jede der Generations eigene (Teil-)Algorithmen zu verwenden. Nachteile können hingegen dadurch auftreten, dass die Objekte eventuell verschoben werden müssen, wenn sie einer neuen Generation zugeordnet werden (Oracle, 2015a) oder dass zwar die durchschnittliche Zeit für eine GC kleiner wird, aber insgesamt mehr GC Events auftreten. Die Aufteilung der Lebensdauer ist in Abbildung 5 von links nach rechts steigend außer für S0 und S1. In der Young Generation (genauer: im Eden Space) werden neue Objekte allokiert. Wenn dieser Speicherbereich voll wird, findet eine sogenannte minor garbage collection statt. Alle nicht-referenziert Objekte der Young Generation werden entfernt und die Lebensdauer-Zähler inkrementiert. Der Eden Space ist nach einer Young Generation immer leer, da alle im Eden Space überlebenden Objekte in einen der beiden Survivor Spaces Abbildung 5: Heap-Generationen Quelle: Oracle (2015a) 10

21 verschoben werden. Aus Performance-Gründen existieren hierbei zwei Survivor Spaces, die sich in ihrer Funktion abwechseln. S1 ist also kein Space, der nur Objekte mit einem höheren Lebensdauer-Zähler umfasst. Überleben Objekte GCs im Survivor Space, werden sie eventuell in die Old Generation verschoben, wenn ihre Lebensdauer-Zähler groß genug sind (Oracle, 2015a). Analog zur minor garbage collection wird die Old Generation im Rahmen einer major garbage collection aufgeräumt. Da sich hier sehr langfristige Objekte aufhalten, wird die Generation weniger oft bereinigt. Die Permanent Generation gehört nicht zum Heap sondern zum sogenannten Non-Heap Speicherbereich (vgl. den Anfang dieses Abschnittes) (Oracle, 2015m). Permanent Generation wurde allerdings in der Java-Version 8 entfernt (Oracle, 2015n), um insbesondere Probleme mit ihrem Sizing zu umgehen. Die Objekte werden infolgedessen auf dem Heap oder dem eigenen JVM-Speicherbereich allokiert. Die auf den Generations angewandten Algorithmen zum Freigeben nicht mehr benötigter Speicherbereiche werden von Garbage Collectors implementiert. In HotSpot kann durch die Nutzung von JVM-Optionen aus vier Collectors ausgewählt werden (Oracle, 2015a): Serial GC, Parallel GC, Concurrent Mark Sweep (CMS) und G1. Für verschiedene Anwendungsfällen haben einige Collectors jeweils Vor- oder Nachteile. Welchen Collector die JVM standardmäßig auswählt, wird auf Basis von Heuristiken getroffen. Beim Feststellen, dass es sich um eine server-class machine (Oracle, 2015r) handelt, wird beispielsweise der Parallel GC ausgewählt (Oracle, 2015b) HDD-Ressource Wie die Memory-Ressource, hat auch die HDD-Ressource eine Kapazität an Speicher. Da die HDD-Ressource in der Speicherhierarchie (Tanenbaum, S. 189) jedoch auf tiefer Ebene zu finden ist, spielt die Auslastung Speicher-Kapazität der HDD-Ressource in Anwendungssystemen oft nicht die entscheidende Rolle. Vielmehr versucht man in der Praxis Lese- und Schreibzugriffe möglichst durch Caching- Mechanismen zu minimieren, da diese Zugriffe ein Vielfaches länger dauern als die Zugriffe auf die Memory-Ressource. Linux-Systeme versuchen deshalb beispielsweise die HDD- Ressourcenauslastung zu minimieren, indem Dateien (oder Teile davon) im Arbeitsspeicher vorgehalten werden (Love, 2005, S. 344). Anstatt der Gesamtspeicherkapazität einer Festplatte spricht man im Rahmen ihrer Auslastung oft von der aktuellen Transferrate (oder ihrem Durchsatz/Bandbreite). Die Transferrate unterscheidet sich technisch bedingt in Lese- und Schreibzugriffe und wird in Speichereinheiten pro Zeiteinheit (zum Beispiel Bytes/s) gemessen. Die Anzahl an gelesenen oder geschriebenen Bytes wird im Folgenden mit HDDread respektive HDDwrite abgekürzt. Bei der Organisation des Speichers der HDD-Ressource durch das Betriebssystem ist ferner noch die Blockstruktur zu beachten. Daten lassen sich auf diesen Block devices (hierzu zählen neben der HDD auch zum Beispiel auch CDs) nur als Folge ganzer Blöcke lesen oder schreiben. Die Blockgröße beträgt in der Regel 4096 Bytes bei Festplatten, sodass selbst das 11

22 Lesen einer nur 100 Bytes großen Datei mindestens zu einem Lesezugriff in Höhe der Blockgröße führt NET-Ressource Durch die NET-Ressource kann ein verteiltes Anwendungssystem untereinander kommunizieren und Informationen austauschen. Zudem wird die Ressource von den Anwendern des Systems genutzt, da diese oft auf Basis von Webtechnologien mit dem System interagieren. Ähnlich wie bei der HDD-Ressource wird auch die NET-Ressource von der Transferrate eingeschränkt, welche in Speichereinheiten pro Zeiteinheit (oft zum Beispiel Mbit/s) angegeben wird. Da es sich um entfernte Verbindungen handelt, hat jedoch auch die Latenz einen Einfluss. Diese wird in Zeiteinheiten gemessen und gibt an, wie lange der Transfer eines Netzwerkpakets zur Übertragung vom Sender zum Empfänger benötigt. Anwendungssysteme verwenden als Netzwerkprotokoll in der Regel TCP (Information Sciences Institute, 1981) als Übertragungsprotokoll. Dieses garantiert die zuverlässige Übertragung anhand von Sequenznummern in den Paketen und Bestätigungen, die der Empfänger an den Sender zurückschickt. Da für den TCP-Verbindungsaufbau ein sogenannter Handshake notwendig ist (Sender und Empfänger initialisieren einen Verbindungskanal), kann ein Paket nicht direkt verschickt werden und verzögert sich so immer etwas. Diese Verzögerung hat neben der physischen Verzögerung (zum Beispiel durch die Übertragung über ein Kabel) auch Einfluss auf die Latenz. Da TCP-Verbindungen oft schon direkt nach dem Senden und Empfangen einer Antwort wieder geschlossen werden (Zustandslosigkeit), ist die Latenz ein großer Einflussfaktor auf die Geschwindigkeit der NET-Ressource Queuing und Scheduling von Hardware-Ressourcen Durch den Aufruf von Operationen werden Ressourcen der Hardwareumgebung des Anwendungssystems benutzt bzw. belegt. Durch den Aufruf von sehr vielen Ressourcen gleichzeitig, kann die Auslastung einzelner Ressourcen bis auf 100% steigen. Dadurch kann es passieren, dass das Anwendungssystem abstürzt (MEM-Ressource) oder sogenanntes Queueing auftritt, also das Warten einer Operation auf eine Ressource. Ebenso verwalten beispielsweise Linuxsysteme antreffende Anfragen nach Ressourcen mit Scheduling-Algorithmen (Linux Programmer's Manual, 2015). Hierdurch kann zum Beispiel gewährleistet werden, dass eine einzelne Operation mit einem großen CPU-Ressourcenbedarf nicht das gesamte System blockiert, weil der Scheduling-Algorithmus der Operation die Ressource wieder entziehen kann, sodass sich diese erneut um die Ressource bemühen muss. Auch existieren Scheduling-Algorithmen speziell für die HDD. Mit diesen können Anfragen an Speicherbereiche der Festplatte innerhalb der Warteschlange zusammengefasst werden, damit sich der Lesekopf der Festplatte nicht so häufig bewegen muss. Als konkrete Scheduling werden in dieser Arbeit Processor-Sharing für die CPU und First- Come-First-Served (FCFS) für die HDD betrachtet. Processor-Sharing ist eine Round-Robin- Scheduling-Strategie (Brause, 2004, S. 32) mit infinitesimal-kleinen Zeitperioden (Spinner et 12

23 al., 2014). First-Come-First-Served (Brause, 2004, S. 32) bearbeitet alle Anfragen vollständig in Reihenfolge ihrer Ankunft. 2.3 Performance und Metriken Auslastung Die Auslastung (Utilization) ist ein Maß welches angibt, wie stark eine Hardware-Ressource benutzt wird. Sie wird deswegen oft in Prozent angegeben und bezieht sich immer auf ein zu definierendes Zeitintervall (zum Beispiel t=1s). Tabelle 1 fasst die Definitionen bezüglich der Auslastung der verschiedenen Ressourcen zusammen wie sie in dieser Arbeit im Folgenden verwendet werden. Ressource Definition von Auslastung CPU MEM HDD NET Anzahl der Taktzyklen zur Bearbeitung der Operation(en) Anzahl der maximal verfügbaren Taktzyklen + Durchschnittlich allokierter Speicher (Bytes) Speicherkapazität (Bytes) Gelesene Einheiten (Bytes) Bytes Max. Lesetransferrate ( Zeiteinheit ) Geschriebene Einheiten (Bytes) Max. Schreibtransferrate (Bytes/Zeiteinheit) Gesendete + Empfangene Einheiten (Bytes) Bandbreite (Bytes/Zeiteinheit) Tabelle 1: Definition der Auslastungen von Hardware-Ressourcen Quelle: Eigene Darstellung Service Time und Service Demand Bei ihrer Prozessierung belegen Operationen verschiedene Hardware-Ressourcen. Die einzelnen Zeitintervalle, vom Start einer einzelnen Allokation einer Ressource bis zum Freilassen dieser Ressource bezeichnet man als Service Time. Die jeweils pro Ressource summierte Service Time von einer Operation ist als Service Demand (oder kurz: Demand) gebräuchlich. Abbildung 6 veranschaulicht vereinfacht hierfür die zeitliche Dimension eines Operationsaufrufes, der die vier vorgestellten Hardware-Ressourcen nutzt. Direkt beim Start erhält die Operation die CPU-Ressource. Zudem wird Speicher auf der MEM-Ressource allokiert. Es wird dann von der Operation ein HDD-Zugriff vorgenommen. Da die HDD- Ressource noch vollständig ausgelastet ist, tritt eine Wartezeit auf (Queueing Time). Hierbei 13

24 werden Scheduling-Algorithmen verwendet. Für die HDD-Ressource ist das in dieser Arbeit immer First-Come-First-Served (vgl. Abschnitt 2.2.3) verwendet. Die Operation nutzt danach nutzt ferner noch die CPU- und die NET-Ressource bevor der Kontrollfluss endet. Je nach der verwendeten Technik für das Speichermanagement würde die Speicherallokation der MEM-Ressource direkt freigegeben werden oder automatisch zu einem späteren Zeitpunkt. Start Ende CPU HDD NET MEM Speicherallokation Wartezeit Service Time Es sei angemerkt, dass es sich bei Abbildung 6 bereits um eine bewusste Abstraktion von dem Realsystem handelt. Wann immer die MEM-, HDD- oder die NET-Ressource benutzt wird, ist in der Regel auch eine Prozessierung durch die CPU nötig. Beispielsweise werden ankommende Netzwerkpakete im Betriebssystem durch einen Netzwerkstack geführt, bevor sie in der Applikation selber weiter verarbeitet werden können. Für die Prozessierung durch den Netzwerkstack (beispielsweise um Routing-Entscheidungen zu treffen) wird so auch die CPU-Ressource belastet. Response Time Abbildung 6: Schematische Abbildung der Nutzung von Hardware-Ressource Quelle: Angelehnt an Menasce, Dowdy, und Almeida (2004) Der in Abbildung 6 dargestellte Zeitraum von Start bis Ende wird als Response Time (RT) oder Antwortzeit der Operation bezeichnet. Response Times können nicht nur für Operationen sondern auch für Transaktionen angegeben werden, indem die zur Transkation gehörenden RTs der Operationen addiert werden. Es ist ferner möglich zwischen Client- und Serverseitigen Response Times zu unterscheiden. Während die Serverseitige RT ein Maß für die Geschwindigkeit der Prozessierung durch den Server ist, schließt die Clientseitige RT insbesondere noch die Netzwerkverbindung zwischen Benutzer und Server mit ein. Die Clientseitige RT ist deswegen ein wichtiges Maß, wenn es 14

25 um eine ganzheitliche Betrachtung der User Experience geht (Gomez, 2015). Sie ist häufig aufgrund der Verwendung des Internets und der damit einhergehenden Schwankung bezüglich Latenz und Bandbreite schwierig zu prognostizieren. Durchsatz Neben der Response Time ist der Durchsatz (Throughput) eine weitere wichtige Performance- Metrik. Für ein zu definierendes Zeitintervall t wird hierbei die Anzahl der vollständig prozessierten Arbeitseinheiten (zum Beispiel Operationen, Transaktionen oder zu lesende/schreibende Speichereinheiten) gemessen (Menascé, 2002, S. 13). Somit ist der Durchsatz sehr abhängig vom Zeitintervall und vom Workload durch die Benutzer. Ebenso kann der Durchsatz deswegen indirekt von der Latenz einer Hardware-Ressource beeinflusst werden, beispielsweise wenn wie in Abschnitt beschrieben für die NET-Ressource sehr viele einzelne Verbindungen aufgebaut werden. Können Service Demands (D) von Ressourcen nicht direkt je Operation gemessen werden, so eignet sich der Durchsatz (X) für eine Approximation. Hierfür muss die Gesamtauslastung der Ressource (U) zur Verfügung stehen, welche sich in der Regel einfacher messen lässt. Der Zusammenhang ist als Service Demand Law bekannt (Menasce et al., 2004): D = U X. Ebenso existieren Werkzeuge, um anhand der Auslastung und der Response Time auf die Demands der Ressourcen zu schließen (LibReDE, 2015). Auf die mathematische Darstellung wird an dieser Stelle verzichtet, da es sich hierbei um statistische Verfahren wie Kalman Filter oder Lineare Regressionen handelt. Willnecker, Brunnert, et al. (2015) zeigen an einem Fallbeispiel, dass diese indirekte Resource-Demand-Berechnung eine hohe Güte in Bezug auf eine Performance-Vorhersage liefert. 2.4 Das Palladio Component Model als Ressourcen-Profil Mit Ressourcen-Profilen kann ein AwS abstrahiert modelliert werden, um an wichtige Performance-Metriken gelangen. In der Literatur existieren viele Methoden und Werkzeuge (Cortellessa, Di Marco, & Inverardi, 2011), aber oft betrachten diese nur Teilaspekte des AwS. Brunnert und Krcmar (2014) schlagen das PCM-Performancemodell als Ressourcen- Profil vor, da es aufgrund der verschiedenen Teilmodelle die obigen Nachteile nicht aufweist Ressourcen-Profil Um Aussagen über Performance-Metriken wie Response Times oder die Auslastung von Ressourcen treffen zu können, ist eine Gesamtbetrachtung der Hard- und Software des Anwendungssystems notwendig. Ressourcen-Profile sind ein Modell eines solchen Anwendungssystems und dienen der Vorhersage dieser Aussagen. Aufgrund der leichten Änderung/Erweiterung von Software-Komponenten, Hardwareumgebungen oder dem Nutzungsverhalten des AwS müssen Ressourcen-Profile parametrisierbar sein, um die Wiederverwendbarkeit zu gewährleisten. Im betrieblichen Kontext soll ein Ressourcen-Profil beispielsweise von einem Software-Hersteller für das 15

26 entwickelte System erstellt werden können. Kunden sollen dann anhand des Ressourcen- Profils und unter dessen Anpassung (beispielsweise der Anzahl der CPU-Kerne und das Nutzungsverhalten) auf Performance-Metriken und Ressourcen-Auslastungen schließen können (vgl. Abbildung 7). Ebenso dienen Ressourcen-Profile als Werkzeug für eine engere Zusammenarbeit von Systementwicklung und IT-Betrieb. Beim Hinzufügen von neuen Features in der Entwicklung können früher als sonst Aussagen bezüglich einer Kapazitätsplanung getroffen werden, die dem IT-Betrieb dienen, die Software früher produktiv einzusetzen. - Nutzerzahl - Nutzerverhalten - Hardwareumgebung - Response Time - Durchsatz - Ressourcen-Auslastung - Energieverbrauch Brunnert und Krcmar (2015) beschreiben, wie Ressourcen-Profile in der Literatur vornehmlich einige der typischen Hardware-Ressourcen wie CPU, MEM, HDD und NET (vgl. Abschnitt 2.2) und ihre Ressource Demands auf Basis von Transaktionen beschreiben. Hiermit ist zwar bereits eine Vorhersage von Performance-Metriken möglich, allerdings werden wichtige Informationen wie die Architektur des AwS nicht hinreichend betrachtet. Wie in Abschnitt 2.1 dargestellt, ist die Architektur ein großer Einflussfaktor für die Performance des Systems. Insbesondere, wenn beispielsweise ganze Deployment Units verändert werden, muss ein Ressourcen-Profil diese Architekturänderungen abbilden können, um verlässliche Vorhersagen über die Metriken machen zu können. Brunnert und Krcmar (2015) schlagen als Folge das Palladio Component Model (Becker et al., 2009) als Modellierungssprache für ein Ressourcen-Profil vor. Dieses wurde anders als Queueing Networks, Layered Queueing Networks oder Queuing Petri Nets (vgl. Cortellessa et al. (2011) nicht monolithisch entwickelt, sondern verwendet verschiedene Teilmodelle zur Abbildung der Architekturschichten Das Palladio Component Model Abbildung 7: Ressourcen-Profil Quelle: Angelehnt an Brunnert, Wischer, und Krcmar (2014) Das Palladio Component Model (PCM) ist ein Performance-Metamodell, welches von Becker et al. (2009) vorgestellt wurde. Es besteht aus fünf Teilmodellen, welche einander referenzieren (vgl. Abbildung 8): 1. Im Resource Environment werden die Server und ihre Netzwerkverbindungen definiert. 16

27 2. Das Repository Model dient der Darstellung der Komponenten und ihrer verwendeten oder zur Verfügung gestellten Schnittstellen. Außerdem werden hier die Operationen der Komponenten modelliert. Hierzu gehören die genauen Kontrollflüsse der Operationen und der Quantität der verwendeten Hardware-Ressourcen. 3. Komponenten können Schnittstellen bereitstellen oder nutzen. Da mehrere Komponenten eine gleiche Schnittstelle anbieten können, wird im System Model die genaue Zuordnung der Komponenten definiert. Des Weiteren können hier die von Komponenten zur Verfügung gestellten Schnittstellen als System-Eintrittspunkte (System Entry Calls) definiert werden. Diese Eintrittspunkte stellen die Transaktionen dar, mit denen die Nutzer mit dem System interagieren (vgl. Abbildung 2). 4. Im Allocation Model können einzelne Komponenten oder ganze Deployment Units einem Server aus dem Resource Environment zugeordnet werden. 5. Das Usage Model spezifiziert den Workload, mit dem das System genutzt wird. Abbildung 8: Das Palladio Component Model Quelle: Angelehnt an Becker, Koziolek, und Reussner (2009); Wischer (2014) Um die Modellierung mit der PCM-Modellnotation zu unterstützen, existieren verschiedene Werkzeuge (Palladio, 2015a). Ebenso existieren Lösungen zur Auswertung der PCM-Modelle (sogenannte Solver), um Performance-Vorhersagen treffen zu können. Solver lassen sich in zwei Kategorien einteilen: Analytische und simulationsbasierte Ansätze. Analytische Verfahren errechnen die gewünschten Performance-Metriken hierbei in der Regel deutlich schneller. Aufgrund der Komplexität der Modelle stoßen sie jedoch oft an Grenzen, sodass simulationsbasierte Verfahren in Fallstudien Verwendung finden (Brunnert, Wischer, et al., 2014; Koziolek et al., 2011). Zudem bietet die von PCM bereitgestellte Simulationsengine SimuCom die Unterstützung für alle spezifischen Notationen des Metamodells während andere Solver Teilaspekte auslassen (Brunnert & Krcmar, 2015). 17

28 2.5 RETIT-Framework Das in dieser Arbeit verwendete RETIT-Framework besteht aus drei Software-Lösungen, die der Performance-Vorhersage und Analyse dienen. Das Framework stellt eine Weiterentwicklung der Performance Management Working Tools (fortiss, 2015b) dar, welche bereits in zahlreichen Fallstudien für die Performance-Evaluation genutzt wurden (Brunnert, Neubig, et al., 2014; Brunnert et al., 2013; Willnecker, Brunnert, et al., 2015). RETIT Java Enterprise Edition Die RETIT Java Enterprise Edition ist ein Application-Performance-Management-Werkzeug (APM) für die Java-EE-Technologie. Im Vergleich zu anderen APM-Lösungen wie Dynatrace (Dynatrace LLC, 2015) liegt der Schwerpunkt vor allem in der eigentlichen Erhebung von Messdaten für eine Performance-Vorhersage und beispielsweise nicht in einer (grafischen) Repräsentation/Aufbereitung der Daten. Ebenso ist die Lösung auf die Erhebung von speziellen/relevanten Messdaten optimiert und belastet so die Ressourcen eines laufenden Systems weniger (Koch-Kemper, 2015). RETIT Capacity Manager Mit dem RETIT Capacity Manager ist es möglich, automatisiert (auf Basis von Messdaten) PCM-Performance-Modelle zu generieren. Diese Modelle können ferner noch ausgewertet werden und dienen so der Performance-Vorhersage, IT-Kapazitätsplanung bzw. dem IT- Kapazitätsmanagement. Das Werkzeug nutzt die Palladio-Bench (Palladio, 2015a) und basiert deshalb ebenso auf dem Eclipse Modeling Framework (Eclipse, 2015). Somit kann der Generierungsprozess und die Simulation auch grafisch vorgenommen werden. Obwohl das RETIT-Framework eine eigene APM-Lösung zur Verfügung stellt, ist auch die Nutzung von Dynatrace-Messdaten möglich (vgl. Willnecker, Brunnert, et al. (2015)). RETIT Continuous Delivery Als dritte Lösung stellt das Framework mit RETIT Continuous Delivery ein Plug-In für den Jenkins-Buildserver (Jenkins, 2015) bereit. Dieses kann genutzt werden, um Performance- Risiken zwischen Release-Zyklen zu minimieren. Hierfür wird nach dem Buildprozess eine Performance-Vorhersage mit dem RETIT Capacity Manager durchgeführt, um so frühzeitig signifikante Performance-Änderungen aufzuspüren (vgl. Brunnert und Krcmar (2014)). 2.6 Java-EE-Technologien Da in dieser Arbeit verschiedene Software-Technologien verwendet werden, sollen die wichtigsten im Folgenden noch näher beschreiben werden. Java Platform, Enterprise Edition Die Java Platform, Enterprise Edition (kurz Java EE) (Oracle, 2015j) spezifiziert eine Middleware-Software-Architektur für Java-Anwendungen. Durch den modularen Aufbau unterstützt die Middleware die in Abbildung 1 beschriebene Teilung der Präsentations-, Geschäftslogik- und Datenhaltungsschicht. Der Fokus der Spezifikation liegt ferne insbesondere auf (verteilten) Webanwendungen. 18

29 Die von der Spezifikation definierten Systeme und Dienste benötigen eine eigene Laufzeitumgebung. Diese wird als Java EE Application Server 1 bezeichnet und teilt sich in verschiedene Container auf. Im Folgenden wird auf den Web-Container und Enterprise-Java- Beans-Container (EJB) eingegangen. Abbildung 9: Java EE Web Container Quelle: Oracle (2015j) Der Web Container (Abbildung 9) beinhaltet als Hauptkomponenten Java Servlets und JavaServer Pages (JSP). Servlets nehmen vom Client Anfragen entgegen und können dieses beantworten. Der Inhalt kann hierbei dynamisch erzeugt werden (Servlets sind Java-Klassen). Servlet sind somit universeller als JSPs, welche primär der Präsentationsschicht zugeordnet werden. JSPs definieren hierbei eine eigene Syntax, mit der statische XML- oder HTML- Seiten dynamisch mit Informationen angereichert werden können. JSPs werden wie Servlets zur Laufzeit kompiliert und dann in der Laufzeitumgebung ausgeführt. EJBs werden vom Application Server im EJB Container verwaltet (vgl. Abbildung 10). Sie sind primär für Aufgaben der Geschäftslogik zuständig. Unterteilt werden kann zwischen Session Beans und Message Driven Beans. Erstere werden durch Methodenaufrufe angesprochen. Letztere reagieren auf ankommende Nachrichten, die über die Java Message Service API (JMS) (Oracle, 2015g) getriggert werden. 1 Eine Beispiel-Lösung ist die Open-Source-Implementierung WildFly Application Server (Red Hat, 2015), welche früher unter dem Namen JBoss bekannt war. 19

30 Wie in Abbildung 9 und Abbildung 10 zu sehen ist, können die Java-EE-Komponenten auf viele verschiedene weitere APIs zugreifen. Im Folgenden wird auf JavaServer Faces (JSF) und die Java API for RESTful Web Services (JAX-RS) genauer eingegangen. JavaServer Faces (JSF) Abbildung 10: Java EE EJB Container Quelle: Oracle (2015j) JSF wurden mit dem Ziel entwickelt, Server-seitige grafische Benutzerschnittstellen in Webanwendungen zu ermöglichen. Beim Antreffen einer Anfrage durchläuft jede JSF- Applikation einen mehrstufigen Lebenszyklus (Oracle, 2015p). Hierbei wird zwischen dem initial request und dem postback request unterschieden. Initial requests durchlaufen hierbei immer nur zwei Lebenszyklusphasen und treten genau dann auf, wenn der Benutzer die Seite das erste Mal über die HTTP-Technologie aufruft. Hierbei wird zuerst eine der Anfrage entsprechende Sicht (View) ausgewählt, welche die darin definierten weiteren JSF-Komponenten in einer Baumstruktur aufbaut und verwaltet. Die Komponenten der View werden danach in der nächsten Phase sofort gerendert. Hierbei wird Kontrollfluss von der JSF-Implementierung an die JSP-Komponente übergeben (Oracle, 2015p). Der Nutzer erhält so beispielsweise auf eine Anfrage eine HTML-Seite zurück. Postback requests treten immer nach initial requests auf. Hierbei wird am Anfang ebenfalls die zutreffende View ausgewählt. Anders als beim initial request muss die Baumstruktur jedoch nicht neu geladen werden, sondern kann auf Basis des initial requests wiederhergestellt werden. Der Anfrage diesmal mitübergebene Werte (beispielsweise HTTP- Parameter) können den Komponenten danach zugewiesen werden. Diese Zuweisungen werden in einer folgenden Phase validiert und danach erst den Server-seitigen Objekten zugewiesen. Wenn der Nutzer ein Element (zum Beispiel einen Button) getriggert hat (die Oberklasse dieser Elemente heißt UICommand), wird sodann die zugehörige Operation (einer 20

31 Bean) aufgerufen (Invoke Application Phase). Am Ende werden die Komponenten in der Baumstruktur in der letzten Phase wieder wie beim Initial request gerendert. Um die vom Benutzer wahrgenommene Antwortzeit von Webanwendungen zu erhöhen, werden Technologien wie Asynchronous JavaScript and XML (AJAX) verwendet. Klassischerweise werden statische Webseiten bei einer Veränderung komplett neu geladen. Mit AJAX können HTTP-Anfragen durchgeführt werden, während die Webseite durchgängig angezeigt wird. Auf Basis der HTTP-Antworten kann die Webseite mittels einer Clientseitigen Engine dann verändert werden, ohne die ganze Webseite neu zu laden. JSF unterstützt die AJAX-Technologie, indem beispielsweise bei der Interaktion von UI- Komponenten AJAX-Anfragen erzeugt werden können. Hierbei werden oft AJAX-Listener verwendet, die beispielsweise eine Operation auf einer Bean aufrufen (Oracle, 2015s). Java API for RESTful Web Services (JAX-RS) JAX-RS ist eine Programmierschnittstelle, die die Verwendung von Webservices über Representational State Transfer (REST) (Fielding, 2000) ermöglicht. REST bezeichnet hierbei ein Programmier-Paradigma für verteilte Systeme. Es verwendet in der Regel das HTTP- Protokoll und ist aus Gründen der Skalierbarkeit Zustandslos entworfen 1, was unter anderem Caching-Techniken unterstützt. REST-Anfragen nutzen HTTP-Methoden (GET, DELETE, PUT etc.) (W3C, 2015) und die Uniform-Resource-Locator-Adresse (URL) als Operationen, um Informationen auszuliefern oder zu verändern. Als Beispiel könnte ein REST-Service, der zurückliefert, ob ein übergebenes Datum einem Werktag entspricht, folgendermaßen aufgerufen werden: GET /isworkingday/14/09/2015. Als Antwort könnte man darauf eine Webseite mit dem Text-Inhalt true erhalten. 1 Durch die Verwendung von beispielsweise HTTP-Cookies ist dies in der Praxis oft nicht zutreffend/gewünscht. 21

32 3 Übersicht relevanter Messwerkzeuge für Memory- und HDD- Ressourcen Dieses Kapitel dient dazu, einen Überblick über die Messwerkzeuge für die MEM- und HDD- Ressourcen zu bekommen. Merkmale geeigneter Werkzeuge sind hierbei: - Die Messerhebung der Ressource-Demands auf Operationsgranularität möglichst ohne eine indirekte Approximation (vgl. das Service Demand Law aus Abschnitt 2.3). - Eine universelle Einsatzfähigkeit der Werkzeuge ohne von speziellen Technologien abhängig zu sein. - Ein möglichst geringer Overhead durch die Instrumentierung. - Eine geeignete Extraktion der Messdaten, um sie in das RETIT-Framework integrieren zu können. In Abschnitt 3.1 werden dafür Publikationen untersucht, die sich mit der Performance- Modellgenerierung beschäftigen und mindestens eine der beiden zu untersuchenden Ressourcen (MEM und HDD) betrachten. Abschnitt 3.2 dient der weiteren Recherche nach Werkzeugen und deren Untersuchung auf die hier beschriebenen wichtigen Merkmale, die diese aufweisen sollten. 3.1 Verwendete Messwerkzeuge für Memory- und HDD-Ressourcen in der Literatur In diesem Abschnitt werden Ansätze aus der Literatur untersucht, die Memory- oder HDD- Ressourcen für die Performance-Modellierung verwenden. Aus Grundlage wurde hierzu eine bereits erstellte Übersicht verwendet (Koch-Kemper, 2015). Diese wurde gezielt nach den Ansätzen durchsucht, die Memory- oder HDD-Ressourcen verwenden. Zudem wurde die Übersicht erweitert, indem in den angegebenen Literatur-Datenbanken noch nach Garbage Collection Simulation gesucht wurde, um dem Java-Speichermanagement Rechnung zu tragen. A1. Kounev und Buchmann (2003a) sowie Kounev und Buchmann (2003b) erstellen Performance-Modelle unter Berücksichtigung der CPU- und HDD-Ressource. Sie verwenden als Fallbeispiel die SPECjAPPServer2001-Benchmarkapplikation (SPEC, 2015a). In ihrer Testumgebung nutzen die Autoren ein Cluster von WebLogic-Applikationservern (Oracle, 2015q) und einen Oracle-9i-Datenbankserver. Für die WebLogic-Server wird die Auslastung der CPU mit nicht näher beschriebenen operating systems tools gemessen. Da es sich hier um eine Messung der Auslastung handelt, werden die eigentlichen Resource Demands der Operationen mit dem Service Demand Law errechnet (vgl. Abschnitt 2.3). Für das Monitoring der Datenbank nutzen die Autoren ein dieser mitgeliefertes Oracle- Werkzeug. Hiermit werden CPU Demands und Wartezeiten aufgrund von I/O gemessen. Eine höhere Granularität in Form einer Unterteilung in gelesene und geschriebene Bytes findet 22

33 nicht statt. So wird in der Evaluation auch nicht eine HDD- sondern nur die CPU-Auslastung als Auslastungsmetrik der Hardware-Ressourcen verwendet. A2. Kounev (2006) nutzt in diesem Ansatz die aktualisierte Benchmark-Applikation SPECjAppServer2004 (SPEC, 2015a). Die verwendeten Technologien der Testumgebung sind identisch geblieben im Vergleich zu Ansatz A1. Als CPU-Messwerkzeug wird diesmal explizit vmstat (Oracle, 2015t) genannt. A3. Sachs, Kounev, und Buchmann (2013) verwenden den SPECjms2007 (Oracle, 2015g) als Benchmark-Applikation. Die Methode der Messerhebung für CPU und HDD bleibt identisch zu A1 und A2. A4. Tiwari und Kashyap (2011) erstellen für ein Industrie-Fallbeispiel ein Performance- Modell. Mit dem verwendeten Werkzeug Perfmon (Microsoft, 2015) erheben sie processor, memory, disk utilizations etc.. In dem erstellten Modell selbst werden jedoch nur CPU, HDD und nicht die MEM-Ressource abgebildet. Zudem wird in der Evaluation die HDD-Ressource herausgelassen, da die Autoren feststellen, dass die Service Demands in ihrer Umgebung sehr niedrig sind und somit keinen Einfluss auf die Response Times haben. A5. Rathfelder, Becker, Krogmann, und Reussner (2012) erstellen ein Performance-Modell für die Hardwarumgebung eines providers. Die verwendeten Monitoring-Werkzeuge werden hierbei nicht genannt. Für die Evaluation werden die Modellvorhersagen mit den echten Auslastungen für die Ressourcen CPU, NET, und HDDwrite verglichen. Da sie im Rahmen der Modellkalibrierung von amount of data written to disk sprechen, müssen sie folglich noch eine Umrechnung über die Schreibtransferrate der Festplatte durchführen. Die HDD-Auslastung ist in ihrer Fallstudie mit weniger als 0,4% sehr gering. A6. Brunnert, Neubig, et al. (2014) generieren automatisiert Performance-Modelle mit Monitoringdaten des PMWT-Frameworks (fortiss, 2015b) (vlg. hierzu auch den Abschnitt 2.5 zum RETIT-Framework). Hierbei erheben sie für die Fallstudie auf Basis der Java-EE- Technologie Messdaten für die CPU- und die MEM-Ressource auf Operations-Level. Als Technik zur Erhebung der CPU- und MEM-Messdaten wird die von der JVM bereitgestellte ThreadMXBean-Schnittstelle genutzt. Ferner nutzen die Autoren dann ServletFilter und EJB Interceptors, um Messwerte am Anfang und am Ende einer Operation zu erheben. Für die MEM-Ressource kann somit beispielsweise ein Delta berechnet werden aus den am Ende der Operation allokierten Bytes minus den am Anfang der Operation allokierten Bytes. Somit erhält man Messwerte für die allokierten Bytes der Operation selbst. Anders als bei der CPU-Ressource zeigen die Autoren, dass ihre Instrumentierung von MEM auf Operations-Level einen erheblichen Overhead verursacht. Des Weiteren wird eine Instrumentierung beider Ressourcen auf Transaktion-Level untersucht. Hierbei ist der signifikante Overhead durch die MEM-Instrumentierung nicht mehr feststellbar. Für die Evaluation wird am Ende eine CPU-Instrumentierung auf Operations-Level verwendet bei der die MEM-Ressource nicht betrachtet wird. A7. Libič, Tůma, und Bulej (2009) untersuchen Probleme bei der Abbildung von Garbage Collection im Rahmen von Performance-Modellen. Hierbei stellen sie fest, dass der GC 23

34 Overhead (gemessen als Anteil an der Response Time) in der Literatur oft nur indirekt als konstanter Faktor und nicht explizit modelliert wird, was zu einem signifikanten Fehler bei der Vorhersage von Performance-Metriken führen kann. Neben der Anzahl von sich unterschiedlich verhaltenden GC-Algorithmen und deren komplexen Implementierungen ist auch die Übertragbarkeit von ermittelten GC-Metriken ein Problem. In der Performance- Modellierung werden Komponenten/Operationen oft separat und ihre Resource Demands möglichst unabhängig von einer speziellen Testumgebung ermittelt. Dieses Vorgehen stößt bei GC auf Probleme, da sich die GC-Metriken für eine Komponente in einer Testumgebung beispielsweise deutlich unterscheiden kann von den GC-Metriken, die diese Komponente im Einsatz eines Produktivsystems hat. Die Autoren untersuchen als Folge grundlegende Parameter von denen der Garbage Collection Overhead im System abhängt. Als Werkzeuge verwenden sie hierfür den diagnostic output of the GC implementation. Sie kommen zu dem Schluss, dass Performance-Modelle den allocation speed (gemessen in Objekten pro Sekunde) und die object lifetimes bei der Modellierung von Komponenten berücksichtigen sollten, um GC Overhead Rechnung zu tragen. A8. Libič, Bulej, Horky, und Tůma (2014) stellen zwei Ansätze zur Modellierung von GC vor. Einmal mit einem sehr vereinfachten Modell auf Basis von nur einer Generation und einmal mit einer Modellierung auf Basis von zwei Generations. Da die Autoren anmerken, dass sich das erste Modell aufgrund der extremen Vereinfachung nicht zur Performance- Modellierung eignet, wird im Folgenden nur das zweite Modell betrachtet. Zur Messdatenerhebung verwenden sie ein eigenes Werkzeug, welches das JVM Tool Interface nutzt (Oracle, 2015o). Der Umfang, der von den Autoren genutzten Messdaten, ist sehr hoch. Sie geben an, dass die Messdatenmenge sich leicht im Gigabyte-Bereich befindet, für wenige Minuten einer Instrumentierung. Der Grund ist, dass sie sehr feingranular instrumentieren und an Messdaten beispielsweise die Lebenszeiten der Objekte, die Objektgrößen und die Veränderung von Referenzen erheben. Ebenso ist die auf den Messdaten aufbauende implementierte Simulation auch rechenaufwändig, sodass die praktische Umsetzung schwierig oder teilweise unmöglich sei. In ihrer Evaluation betrachten die Autoren deswegen auch verschiedene Techniken bei denen sie Messdaten auslassen oder aggregieren. Der Simulator hat das Ziel, die Aufruffrequenzen von GC Events vorherzusagen. Bei Verwendung nahezu aller Messdaten können die Autoren mit der Simulation die Aufruffrequenz der Minor GC Events gut vorhersagen 1. Für die Major GC Events schwankt der Fehler zwischen 14 % und 131 %. Bei einer Aggregation oder dem Weglassen einiger Messdaten steigt der Fehler tendenziell. Die Autoren benennen ferner noch einige Probleme, bei der Vorhersage von GC Events. Beispielsweise hatte eine Reduzierung der Objektgröße um 20 % keinen Einfluss während eine Steigerung der Objektgröße um 10 % die Anzahl der GC Events verdoppelt hat. Eine weitere Steigerung auf 40 % hatte danach wieder keinen Einfluss mehr. 1 Es wird hierbei kein Fehlerwert in Prozent ermitteln. Die gute Vorhersage lässt sich jedoch an den Grafiken ablesen. 24

35 Für die Modellierung der Dauer einer GC stellen sie approximativ einen linearen Zusammenhang fest zu der Anzahl der Objekte, die die GC überleben. Dies soll in zukünftigen Arbeiten noch näher untersucht werden. 3.2 Weitere HDD-Messwerkzeuge Das /proc-dateisystem Das /proc-dateisystem 1 ist ein von vielen Linux-Distributionen standardmäßig integriertes Werkzeug, um Systeminformationen bereitzustellen (Killian, 1984; Linux Kernel, 2015c; Shotts Jr, 2012, S. xvii). Die Nutzung des Werkzeugs folgt der Philosophie Everything is a file (Shotts Jr, 2012, S. 17), welche besagt, dass möglichst viele Ein- und Ausgabe-Ressourcen wie Festplatten, Drucker, Tastaturen oder Netzwerkverbindungen über das Dateisystem verfügbar gemacht werden sollen, damit Werkzeuge für den Zugriff auf diese Ressourcen möglichst wiederverwendet werden können. Da es sich bei den vom /proc-dateisystem bereitgestellten Systeminformationen um hierarchische Daten handelt, lassen sich diese außerdem gut in Form von Ordnern und Dateien organisieren. Die Informationen sind dann zum Beispiel sehr leicht mit einfachen Texteditoren oder Dateioperationen auslesbar. Um für die Bereitstellung der Daten möglichst wenig Ressourcen zu verbrauchen, handelt es sich bei /proc um kein echtes Dateisystem, welches auf der Festplatte gespeichert und aktualisiert wird, sondern um ein virtuelles Dateisystem (Shotts Jr, 2012, S. 22), welches standardmäßig vom Betriebssystem-Kernel beim Bootvorgang im Arbeitsspeicher vorgehalten wird. Beim Lesezugriff auf eine der Dateien werden die Informationen vom Betriebssystem-Kernel stets dynamisch zur Laufzeit generiert. Wenn Informationen aus dem /proc-dateisystem angefragt werden, stellt das Betriebssystem diese zusammen und liefert einen Filehandler, also eine Referenz auf eine Datei, zurück. Diese Referenz zeigt auf eine virtuelle Datei im Arbeitsspeicher, in der an die angefragten Informationen stehen. Werte, die über diese Dateireferenz zur Verfügung stehen, werden vom Betriebsystem nicht automatisch aktualisiert, auch wenn es sich um volatile Daten mit Zeitbezug handelt. Stattdessen kann man die Datei mithilfe eines neuen Filehandler ein weiteres Mal auslesen. Zudem existieren in Linux die beiden Syscalls 2 lseek(), welche (auf den Filehandler ausgeführt) ebenfalls das Aktualisieren der Daten anstoßen. Verzeichnisstruktur Die von /proc bereitgestellten Daten lassen sich in zwei Kategorien einteilen: Prozess- und Nicht-Prozess-abhängige Systeminformationen (Linux Kernel, 2015c). 1 Das /proc-dateisystem wird oft als procfs abgekürzt. 2 Linux system calls (kurz Syscalls) stellen die grundlegendste Schnittstelle zwischen einer Applikation und dem Betriebssystem-Kernel selbst dar (Linux Man Page, 2015). 25

36 Nicht-Prozess-abhängige Daten liegen hierbei direkt im Ordner /proc selbst. Beispieldateien sind: - /proc/cpuinfo: Hierüber können Informationen über die CPU ausgelesen werden wie zum Beispiel die aktuelle Taktfrequenz oder der Hardware-Hersteller. - /proc/uptime: Gibt die Zeit in Sekunden an, die seit dem letzten booten des Betriebssystem-Kernel vergangen sind. - /proc/net: Listet unter anderem die aktiven Netzwerkverbindungen auf. Informationen zu Prozess-abhängigen Daten sind nach der jeweiligen Prozess ID (PID) aufgeteilt. Hierbei übergibt man die PID als Parameter im Pfad: - /proc/<pid>/status: Liefert allgemeine Informationen über den Prozess wie beispielsweise den Namen, State oder Anzahl an Threads. - /proc/<pid>/tasks: Listet die Threads von dem Prozess jeweils als eigenen Ordner auf. Dadurch kann man tiefer in die Verzeichnisstruktur von /proc und so auch an Informationen der einzelnen Threads, identifiziert mit ihrer Thread ID (TID), gelangen. Ein Beispielpfad, um an allgemeine Informationen eines Threads zu gelangen, setzt sich deshalb folgendermaßen zusammen: /proc/<pid>/tasks/<tid>/status. Des Weiteren sei an dieser Stelle angemerkt, dass ein direkter Aufruf von /proc/<tid> zwar möglich ist, aber dass trotzdem keine Informationen des Threads sondern des zugehörigen Prozesses aufgelistet werden. Es handelt hierbei also um einen Dateiverweis. Auslesen von HDD-Messdaten in /proc Informationen über die Nutzung der Festplatten stehen in /proc sowohl für den Prozess als auch für die Threads im Unterverzeichnis /io zur Verfügung. Beispielhaft werden hier die HDD-Informationen eines Threads mit TID beschrieben, der zum Prozess gehört und dessen Daten man somit in der Datei /proc/13200/taks/13300/io abrufen kann: rchar: wchar: 8192 syscr: 1 syscw: 1 read_bytes: 4096 write_bytes: 8192 cancelled_write_bytes: 0 Tabelle 2: Beispielausgabe von /proc/pid/tasks/tid/io Quelle: Eigene Darstellung Overheadanalyse für die Erhebung von procfs-messwerten Um die Leistungsfähigkeit des /proc-dateisystems zu testen, wurde ein kleiner Benchmark geschrieben. Hierbei wurden in einem Intervall von 5ms Aufrufe auf das Dateisystem gestartet. Die ausgelesenen Werte wurden ferner in eine temporäre Variable gespeichert. Vor dem procfs- 26

37 Aufruf und nachdem die Ausgabe in die temporäre Variable gespeichert wurde, wurden Zeitstempel gesetzt. Auf Basis des Deltas dieser Zeitstempel kann gemessen werden, wie viel Overhead ein procfs-aufruf erzeugen würde, wenn er in einem Monitoring-Framework eingesetzt wird. Des Weiteren sollte verglichen werden, inwieweit sich der Overhead zwischen den beiden Programmiersprachen C und Java unterscheidet. Für die Gesamtmessdauer wurde eine Benchmark-Länge von 20min verwendet. Beim Betrachten der Messwerte in einer Zeitreihe fiel auf, dass der Overhead für die Java-Implementierung nach rund 75s um einen relativ konstanten Faktor sank im Vergleich zu den Messwerten davor. Eine Begründung hierfür ist die Just-in-time-Kompilierung der JVM. Es wurde deshalb eine sogenannte Ramp-Up-Phase von 3min definiert, Berechnung der Mittelwerte die Messdaten der ersten 3min nicht berücksichtigt. Folgende Werte für den Overhead wurden so ermittelt (Einheit in Nanosekunden) Aufruf-Intervall 5ms Mittelwert in ns (C) Mittelwert in ns (Java) Tabelle 3: Overheadanalyse des /proc-dateisystems Quelle: Eigene Darstellung Während die ersten /proc-aufrufe in Java noch rund ns dauern, sinkt der Overhead durch die JIT deutlich und ist auf einem Niveau mit der C-Implementierung Per-Task Statistics Interface Ähnlich wie das /proc-dateisystem (vgl ) ist das Per-Task Statistics Interface 1 ebenfalls ein von den meisten Linux-Distributionen bereitgestelltes Werkzeug, um Systeminformationen auszulesen (Linux Kernel, 2015b). Das Ziel der Entwicklung dieses Werkzeugs ist es, ein effizientes Auslesen von Statistiken eines Prozesses zu ermöglichen. Somit gibt es eine direkte Überschneidung an Funktionalität mit dem /proc-dateisystem. Technisch sind die Unterschiede beider Werkzeuge größer, da das Per-Task Statistics Interface eine bidirektionale Socket-Verbindung 2 für die Kommunikation mit dem Betriebssystem-Kernel verwendet. Die Socket-Verbindung soll hierbei eine effizientere Kommunikation ermöglichen. Führende Linux-Betriebssystemenwickler halten das Interface jedoch für schlecht entworfen und möchten die Nutzung einschränken. Als Folge wurde festgelegt, dass das Interface nur noch mit Administrator-Rechten ( root -Rechte) benutzt werden darf. Ebenso wird der langfristige Verbleib der Schnittstelle generell infrage gestellt (Linux Kernel Mailinglist, 1 Das Per-Task Statistics Interface wird oft als Taskstats abgekürzt. 2 Als Sockets bezeichnet man die Endpunkte einer Interprozesskommunikation (Haase, 2008). Protokolle definieren, wie die Verbindung zu initialisieren ist oder wie das Datenformat der auszutauschenden Informationen auszusehen hat. 27

38 2011). Dies könnte insbesondere auch ein Grund dafür sein, dass Dokumentationen oder Beispiele im Internet nur sehr spärlich vorhanden sind PostgreSQL pg_statistics Heutige Anwendungssysteme persistieren ihre Daten in der Regel in Datenbanksystemen. Ein großer Teil der Aktivitäten für das Lesen und Schreiben von Speichermedien wird somit vom Datenbanksystem hervorgerufen. Anders als Werkzeuge, die auf Betriebssystem-Ebene messen (vgl und 3.2.2) können, wird mit dem Datenbanksystem selbst folglich nur eine Teilmenge der HDD gemessen werden können. Im Folgenden wird beispielhaft die HDD- Messerhebung über die PostgreSQL-Datenbank (The PostgreSQL Global Development Group, 2015) beschrieben. Zum Messen von HDD Demands innerhalb von PostgreSQL ist eine erweiterte Softwarebibliothek notwendig, die nachinstalliert werden muss. Die Linuxdistribution OpenSUSE (OpenSUSE, 2015) stellt dies beispielsweise im Paket postgres-contrib bereit. Die Bibliothek muss dann in der Konfigurationsdatei postgresql.conf folgendermaßen gesetzt werden: shared_preload_libraries = 'pg_stat_statements. Außerdem muss der Parameter track_io_timing = on geschaltet werden. Die Messdaten speichert PostgreSQL selbst in eigenen Datenbanktabellen, die man mit bekannter SQL-Syntax auslesen kann. Für das Auslesen von HDD Demands bietet sich die vordefinierte Datenbanksicht Pg_statemns_view an. Hiermit können für jedes verarbeitete Prepared Statement 1 Statistiken ermittelt werden. Neben der Anzahl der Aufrufe eines Prepared Statements ist die gesamte Response Time auslesbar und somit folglich indirekt auch der Mittelwert für die Response Time jedes Statements. Feingranularer ist die von der Response Time subsummierte Zeiteinheit, die für das eigentliche Lesen und Schreiben von Blöcken auf das unterliegende Speichermedium benötigt wurde, auch auslesbar. Die von PostgreSQL gelesenen und geschriebenen Blöcke (vgl. Abschnitt 2.2) des zugrundeliegenden Speichermediums werden zusätzlich auch je Prepared Statements festgehalten. Analog wie bei der Response Time kann hiermit auch ein Mittelwert für die gelesenen und geschriebenen Blöcke eines Prepared Statements ermittelt werden. Bei den von PostgreSQL zur Verfügung gestellten Daten sind die vom Datenbanksystem selbst implementierten Cachemechanismen zu beachten. Zusätzlich zu Betriebssystem- und Hardware-Caches nutzt PostgreSQL weitere eigene Verfahren (beispielsweise shared_buffers). Somit können die bereitgestellten Statistiken von der realen Auslastung der HDD Ressource abweichen, da auch vom Datenbanksystem zu schreibende Daten erst gesammelt und danach in Form einer Batchverarbeitung prozessiert werden. 1 Prepared Statements sind Datenbankanweisungen, die anstelle konkreter Parameter Platzhalter beinhalten. Dadurch können Prepared Statements Performance-Vorteile bringen, da Teile der Anweisung schon vorübersetzt im Datenbanksystem vorgehalten werden können. Zudem kann das System effektiver gegen Angriffe geschützt werden, da die dem Prepared Statement später anzureichernden Parameter zur Laufzeit auf Gültigkeit überprüft werden können. 28

39 Bezüglich dem Overhead, der durch das Festhalten der Statistiken entsteht ist mit einer Verlangsamung der Ausführung von SQL-Statements von rund 15% (Lubaczewski, 2015) zu rechnen Java Mission Control Java Mission Control (JMC) ist ein Werkzeug für die HotSpot-JVM (Oracle, 2015k), um detaillierte Informationen über das Verhalten der JVM grafisches darzustellen. JMC setzt hierbei auf dem Java-Flight-Recorder-Werkzeug (JFR) auf. Dieses ist ein Profiling- und Ereignis-Management-Framework und ist Teil des Oracle JDKs. JMC und JFR werden somit zusammen in einer Tool-Chain genutzt. Ausgangspunkt für die Verwendung von JMC ist eine vorherige Instrumentierung des Systems mit JFR, um an die nötigen Messdaten zu gelangen. Diese werden aus Gründen des Speicherverbrauchs und der schnellen Prozessierung in einem Binärdatenformat erstellt. Mit JFR können Metriken wie die Anzahl von Dateizugriffen, die Response Time von Dateilese oder schreiboperationen sowie die von einer Operation gelesenen oder geschriebenen Bytes erhoben werden. Standardmäßig werden alle Operationen, die eine Response Time von unter 10ms ignoriert. Dieser Threshold ist jedoch anpassbar. Somit ist JFR generell als Werkzeug eignet, HDD-Demands für Operationen zu erheben. Leider existieren für das binäre Datenformat von JFR keine offiziellen Parser. Da JMC mit dem Ziel einer grafischen Analyse der Messdaten erstellt wurde, existieren keine Datenextraktionsmethoden in Form eines Standardformates. Dies ist für die Integration ins RETIT-Framework problematisch SIGAR SIGAR (Hyperic, 2015) ist ein Werkzeug, um Systeminformationen auszulesen. Es wurde mit dem Ziel entwickelt, möglichst portabel, das heißt unabhängig vom Betriebssystem zu sein. Als Folge wird das Werkzeug mit sehr vielen unterschiedlichen Librarys für alle großen Betriebssysteme ausgeliefert (Linux, Windows, Solaris, Mac OS, FreeBSD etc.). Für die Erhebung von HDD-Messdaten existiert die Klasse DiskUsage. Zwei Arten von Messdaten sind hier extrahierbar: - Die Anzahl an lesenden und schreibenden Zugriffen und - die gelesenen und geschriebenen Bytes des Prozesses zum Messzeitpunkt. Aufgrund dieser Einschränkung eignet sich SIGAR nicht, um HDD-Demands auf Operations- Level sondern nur, um die gesamte HDD-Auslastung zu erheben Zusätzliche Betriebssystem-Werkzeuge Für Linuxsysteme existieren diverse weitere Tools, um HDD Demands zu extrahieren. Allen gemein ist jedoch, dass sie entweder das /proc-dateisystem (vgl ) oder das Taskstats Interface (vgl ) zur Erhebung der Daten nutzen. Die Werkzeuge können deshalb als einfachere Möglichkeit gesehen werden, die Messdaten zu extrahieren. Allerdings muss für 29

40 die Extraktion der Daten dann auch ein zusätzlicher Overhead durch das Werkzeug einkalkuliert werden. Iotop Iotop (Chazarain, 2015) ist ein Python-Werkzeug, welches das Taskstats Interface nutzt, um gelesene und geschriebene Bytes auf Thread- oder Prozess-Level darzustellen. Ebenso wie Taskstats ist es deshalb nur mit Administratorrechten ausführbar und die langfristige Verfügbarkeit des Werkzeugs unsicher. Bei Start erhebt Iotop HDD Demands für Zeitintervalle (Standardeinstellung ist 1s). Diese Zeitintervalle können zwar per Parameter verkürzt werden, eine Umrechnung auf Operationen ist so aber mit Schwierigkeiten verbunden, obwohl Iotop auf Thread-Level messen kann. Da der Start oder das Ende einer Operation nie genau auf den Start oder das Ende des Iotop- Zeitintervalls fallen, kann der HDD Demand einer Operation nämlich immer nur approximiert werden. Mit dem Parameter --pid=pid kann man die Ausgabe auf den Prozess/Thread mit Identifikation PID beschränken. Auch eine Liste an PIDs kann man übergeben. Die Ausgaben von Iotop können einfach im Textformat geschrieben werden. Ein Zeitstempel kann hierbei auch jedes Mal generiert werden. Zudem ist die Nutzung des Parameters -- kilobytes anzuraten, da die von Iotop verwendeten Messeinheiten sonst je nach Auslastung zwischen den Messintervallen variieren können. htop htop (Muhammad, 2015) besitzt eine große Ähnlichkeit zu Iotop. Es ist ebenfalls ein Werkzeug für Linuxsysteme und kann zur Messung von HDD Demands genutzt werden. Im Vergleich zu Iotop wird jedoch nicht das Taskstats Interface sondern das /proc-dateisystem als Messdatenquelle verwendet. htop ist somit ohne Adminsistratorrechte nutzbar. Da es als interaktives Programm für die Kommandozeile entwickelt wurde und sich durch terminal redraw routines aktualisiert, ist eine Extraktion der Messwerte schwierig. iostat iostat (Linux Kernel, 2015a) nutzt ebenfalls das /proc-dateisystem zur Darstellung von gelesenen und geschriebenen Bytes. Anders als htop lässt sich die Ausgabe auch gut im Textformat abspeichern zur späteren Auswertung. Allerdings ist die Erhebung der HDD Demands nur auf der Granularität einer Partition möglich. 3.3 Weitere Memory-Messwerkzeuge RETIT JMX-Logger Neben der beschriebenen Erhebung von MEM-Messdaten über JVM-ThreadMXBean- Schnittstelle (vgl. Ansatz 6 in Abschnitt 3.1) auf Operations-Level, stellt das RETIT- Framework ein kleines Hilfswerkzeug bereit, welches auf Basis der Java Management Extensions (JMX) (Oracle, 2015f) arbeitet. 30

41 Messung von CPU- und MEM-Auslastung Mit JMX ist es möglich, Informationen aus MBeans (remote) zu extrahieren. Während man über ManagementFactory.OPERATING_SYSTEM_MXBEAN_NAME beispielsweise an die CPU-Gesamtauslastung des JVM-Prozesses kommen kann, existiert mit ManagementFactory.MEMORY_MXBEAN_NAME auch eine Möglichkeit die aktuelle Heap- Gesamtauslastung zu extrahieren. Mit dem Werkzeug bzw. dem JMX-Framework ist es folglich nicht ohne weiteres möglich, den MEM Demand für Operationen direkt zu bestimmen. Hierfür müssten approximierende Verfahren wie das Service Demand Law (vgl. 2.3) verwendet werden. Garbage Collection Events Eine in dieser Arbeit implementierte Erweiterung für den JMX-Logger erlaubt auch die Messung von Garbage Collection Events. Seit Java Version 7 (Update 4) existiert hierfür die Möglichkeit, sich mittels JMX mit einer JVM zu verbinden und von dieser über GC Events benachrichtigt zu werden. Technisch wird hierfür die GarbageCollectorMXBean verwendet, an die man einen NotificationListener hängt. Die erhobenen GC Events liefern verschiedene Informationen mit. Insbesondere sind Young oder Old Gen GC leicht identifizierbar. Ebenso ist die Nutzung (in Bytes) für alle in Abbildung 5 dargestellten GC Spaces jeweils vor und nach dem GC Event auslesbar. Somit kann für Young und Old Generation die Menge an freigegebenen Bytes berechnet werden. Des Weiteren wird für jedes GC Event die Dauer angegeben. Diese wird im erstellten Werkzeug auch erhoben und kann für die Modellierung eines CPU Demands auf Grundlage GC-Prozessierung verwendet werden HeapAudit HeapAudit (Foursquare, 2015a) ist ein MEM-Messwerkzeug für die Java-Technologie. Es nutzt von der JVM bereitgestellte Hooks, welche es beispielsweise zur Analyse der Heap- Objekte oder der Garbage Collection Events gibt. Somit unterscheidet es sich von vielen anderen Profiling-Werkzeugen, die MEM auf Basis eines Sampling berechnen (Foursquare, 2015b). Ein HeapRecorder kann global für alle Threads und Prozesse oder selektiv für einzelne Operationen registriert werden. Die instrumentierten Daten/Events können beispielsweise im Textformat extrahiert werden. Zudem existieren Techniken, um die Messdaten vorher schon zu aggregieren (Foursquare, 2015a). Aufgrund der Verwendung von Hooks ist die Granularität der Messdaten sehr fein. Für ein Minimalbeispiel, bei dem in einer Schleife sukzessiv 25 Werte in einer HashMap abgelegt werden, registriert der HeapRecorder fünf Events mit Allokationen für die Klasse java.util.hashmap. Dies resultiert daraus, dass die Größe der HashMap in Zweiterpotenzen angepasst wird, sobald ein Threshold erreicht ist. Wie angesprochen existieren Möglichkeiten, nur Events von selber zu definierenden Klassen zu instrumentieren. Für nicht-instrumentierte Klassen würden die Events dann einfach nicht 31

42 beachtet und aufgezeichnet werden. Somit würden die Heap-Allokationen für nichtinstrumentiere Klassen, dann auch den Operationen einer Granularitätsstufe darüber fehlen. Würde man beispielsweise die Klasse java.util.hashmap aus dem Minimalbeispiel von oben nicht betrachten, so hätte das Beispiel gar keine Heap-Allokationen mehr. Die Entwickler nennen für ihre Server eine Erhöhung der Response Time von % (Foursquare, 2015b). Auf Basis dieser Schätzung wäre das Werkzeug als Messdatenquelle für die automatisierte Performancemodellgenerierung eher ungeeignet (vgl. Brunnert, Neubig, et al. (2014)). 3.4 Schlussbemerkungen zur Auswahl der Werkzeuge Messung der HDD Demands Für die Messung der HDD Demands stellt sich das /proc-dateisystem (Abschnitt 3.2.1) als geeignetes Werkzeug heraus. Die Messwerte sind hierbei über die Verzeichnisstruktur sehr gezielt auslesbar. Der Overhead durch die Messerhebung ist dadurch (unter anderem) gering. Das Taskstats Interface ist im Vergleich dazu nur mit Administratorrechten ausführbar. Dies ist problematisch, da diese Rechte sicherheitsbedingt im IT-Betrieb nicht selbstverständlich sind. Der langfristige Verbleib der Schnittstelle muss außerdem kritisch bewertet werden (vgl. Abschnitt 3.2.2). Ein Auslesen der HDD Demands im Datenbankmanagementsystem selbst, wie es für PostgreSQL beschrieben wurde in Abschnitt 3.2.3, hat den Nachteil, dass die Instrumentierung nur für dieses eine System funktioniert. Da es eine große Anzahl an weiteren Datenbanken gibt, müsste für jede dieser ein Werkzeug für die Instrumentierung erstellt werden zur Integration ins RETIT-Framework. Java Mission Control ist primär als grafisches Analysewerkzeug für Messdaten aus dem Java Flight Recorder geeignet (vgl. Abschnitt 3.2.4). Im Vergleich zu dem einfachen Ausleseformat vom /proc-dateisystem gibt es jedoch aktuell keine offiziell unterstützten Schnittstellen zum Parsen dieser Daten im Binärformat. Selbst wenn es einen Parser gäbe, müssten die mit Java Flight Recorder erhobenen Daten in einem Postprocessing-Schritt mit den Monitoring-Daten von RETIT angereichert werden und könnten nicht direkt ausgelesen werden wie bei der Nutzung vom /proc-dateisystem. SIGAR (vgl. Abschnitt 3.2.5) kann technisch bedingt keine Demands auf Operations-Level erheben. Aufgrund der vielen unterstützen Betriebssysteme würde es sich jedoch sehr gut zur universellen Messung der HDD-Auslastung eignen. Da das Auslesen der Daten über das /proc-dateisystem sehr einfach ist, existiert kein Grund für die Verwendung von Tools wie Iotop, htop und iostat, wenn es um die gezielte Erhebung von HDD Demands geht. 32

43 Messung der Memory Demands Ein Hilfswerkzeug wie der RETIT JMX-Logger (Abschnitt 3.3.1) eignet sich nicht zur Erhebung von Messdaten auf Operations-Level. Der Logger eignet sich somit nur für die Nutzung von approximativen Verfahren. HeapAudit kann hingegen sehr feingranular MEM Demands erheben. Allerdings ist der von den HeapAudit-Entwicklern angegebene Response-Time Erhöhung durch den Messoverhead (Abschnitt 3.3.2) von % zu hoch im Rahmen der Performance-Modellgenerierung. Ansatz A8 aus der Literaturübersicht von Libič et al. (2014) könnte zwar das Auftreten von GC Events vorhersagen, allerdings ist die Messerhebung und die Simulation so aufwändig, dass sie produktiv schwierig einzusetzen ist. Der von Brunnert, Neubig, et al. (2014); Brunnert et al. (2013) vorgestellte Ansatz (vgl. A6 in Abschnitt 3.1) zur MEM-Demand-Messung auf Operations-Level stellt sich als vielversprechend heraus. Die Autoren deuten auf Probleme aufgrund des Messoverheads. Dieser kann jedoch signifikant verringert werden, wenn eine Instrumentierung nur für System-Entry-Point-Operationen erfolgt. Willnecker, Dlugi, et al. (2015) zeigen eine geeignete Performance-Vorhersage von Modellen auf System-Entry-Point-Messdaten. Des Weiteren ist die Erhebung der MEM-Ressource auf Basis des obigen Ansatzes bereits im RETIT-Framework implementiert und kann somit direkt genutzt werden. Der Ansatz verwendet jedoch ein sehr einfaches Speichermanagement-Modell (vgl. 2.2). Dieses wird im Folgenden erweitert werden, um ein realistischeres Modell zu generieren und so die Vorhersage der MEM-Auslastung zu verbessern. 33

44 4 Integration und Abbildung der Memory- und HDD-Messdaten in dem RETIT-Framework In diesem Kapitel soll die Integration der HDD-Messdaten und ein angepasster Modellierungsansatz für die MEM-Ressource beschreiben werden. Hierfür wird in Abschnitt 4.1 zuerst die Architektur für die Messdatenerhebung im RETIT-Framework beschrieben. Aufbauend darauf wird die Inkludierung der HDD Demands im Monitoring- und Generierungs-Framework beschreiben, aufbauend auf den Messdaten des /proc-dateisystems (vgl. Abschnitt 3.4). Für die Memory-Ressource wird die bestehende Messdatenerhebung im RETIT-Framework nicht angepasst. Stattdessen wird ein neuer Modellierungsansatz beschrieben, der das Java-Speichermanagement besser abbildet (vgl. Bemerkungen in Abschnitt 3.4). 4.1 Architekturübersicht der Messdatenerhebung im RETIT-Framework Abbildung 11 veranschaulich schematisch die Architektur des RETIT-Monitoring- Frameworks. Diese wird im Folgenden genauer erläutert. Als maßgebliche Technik, um an die verschiedenen Resource Demands einer Java-EE- Applikation zu gelangen, verwendet das RETIT-Monitoring-Framework ServletFilter (Oracle, 2015l) und EJB Interceptors (Oracle, 2015c). Beiden Techniken ist gemein, dass man mit ihnen jeweils vor und nach der Ausführung einer Operation eigenen Programmcode ausführen lassen kann. Das Monitoring-Framework nutzt dies, um beispielsweise vor und nach einer Operation die vom Thread allokierten Bytes abzuspeichern. Sowohl der ServletFilter (PerformanceMonitoringServletFilter in Abbildung 11) als auch der EJB Interceptor (PerformanceMonitoringEJBInterceptor in Abbildung 11) erben von der gemeinsamen Klasse PerformanceMonitoringHandler. Diese Oberklasse hält beispielsweise Parameter vor, welche Hardware-Ressourcen instrumentiert werden sollen. Ebenso haben der ServletFilter und der EJB Interceptor über die Oberklasse eine Referenz auf IResourceDemandDataCollector. Dieses Interface definiert Methoden, um zu einem Zeitpunkt an Resource Demand zu gelangen. Ein Beispiel ist das bereits erwähnte Auslesen der von einem Thread allokierten Bytes ( getcurrentthreadallocatedbytes() ). Die Implementierung der Methoden um an den CPU- und den MEM Demand zu gelangen wird hierbei schon in der abstrakten Klasse CommonDemandDataCollector vorgenommen. Da es sich bei der Erhebung von CPU und MEM um Plattformunabhängige Methoden handelt, werden diese Methoden logisch von denen getrennt, die nur auf einer speziellen Plattform ausgeführt werden können. Als Beispiel wird das Auslesen der HDD Demands mit dem /proc-dateisystem eine Plattformabhängige Methode sein, die nur auf Linuxsystemen läuft. Für jede der unterschiedlichen Plattformen wird es deswegen eine eigene Klasse geben, die von CommonDemandDataCollector erbt und die fehlenden Plattformabhängige Methoden implementiert. 34

45 Für das Abspeichern der ausgelesenen Demands besitzen der PerformanceMonitoringServletFilter und der PerformanceMonitoringEJBInterceptor jeweils eine Referenz auf ein Objekt mit PersistenceService-Schnittstelle. Durch Aufruf von persistcomponentinvocation(javaeecomponentinvocation componentinvocation) kann eine Operation persistiert werden. Für diese Masterarbeit wird ausschließlich die Persistierung in CSV-Dateien verwendet. Hierbei wird für jede zu persistierende Operation eine eigene Zeile angelegt mit Feldern für die einzelnen Demands und allgemeinen Informationen wie einem Zeitstempel. PerformanceMonitoringHandler {abstract} <<Schnittstelle>> IResourceDemandDataCollector PerformanceMonitoringServletFilter PerformanceMonitoringEJBInterceptor CommonResourceDemandDataCollector {abstract} <<Schnittstelle>> PersistenceService WindowsDataCollector LinuxDataCollector Abbildung 11: Schematische Architektur des RETIT-Monitoring-Frameworks Quelle: Eigene Darstellung 4.2 HDD Integration und -Abbildung Der Folgende Abschnitt beschreibt, wie die HDD Demands auf der Granularität von Operationen mithilfe der RETIT-Monitoringlösung erhoben werden und wie sie danach unter Nutzung des RETIT Capacity Managers in einem PCM abgebildet werden können Messdatenerhebung der HDD Demands auf Operations-Granularität Damit der PerformanceMonitoringHandler die aktuellen HDD Demands eines Threads auslesen kann, stellt die IResourceDemandDataCollector-Schnittstelle die neue Methode getdiskbytesreadandwritten() zur Verfügung, die ein Long-Array bestehende aus den gelesenen und geschriebenen Bytes zurückliefert. Da es sich beim /proc-dateisystem um ein Werkzeug für Linuxsysteme (also um ein Plattform-abhängiges Werkzeug) handelt, ist die Implementierung nicht im CommonDemandDataCollector sondern im LinuxDataCollector vorzufinden. Um die HDD Demands für einen Thread aus dem /proc-dateisystem auszulesen, ist die Process ID und die Thread ID nötig (vgl ). In der Java-Laufzeitumgebung ist es zwar möglich, sich eine Process ID und eine Thread ID ausgeben zu lassen, allerdings unterscheiden sind diese IDs von denen des Betriebssystems. Java nutzt für die Identifikation 35

46 von Prozessen und Threads also eine Abstraktionsschicht, da es als Plattform-unabhängige Programmiersprache entwickelt wurde. Als Lösung bietet sich die Verwendung des Java Native Interfaces (JNI) an. Hiermit können aus der JVM heraus native, Plattformspezifische Funktionen aufgerufen werden (Ullenboom, 2011). Mit der System.loadLibrary() wird hierzu beispielsweise ein C-Programm aufgerufen. Dieses muss eine spezielle Namenskonvention beachten. So ist es auch möglich, Rückgabewerte der nativen Funktion in Java zu erhalten. Während es innerhalb der JVM indirekt möglich ist, über den Namen der RuntimeMXBean an die native Process ID zu gelangen 1, musste für die native Thread ID ein kleines C- Programm geschrieben werden. Dieses liest mittels eines Linux-Syscalls die Thread ID aus (tid = syscall( NR_gettid) und gibt den Ganzzahl-Wert zurück. Somit ist der gesamte Dateipfad für einen Thread im /proc-dateisystem ermittelbar und die gelesenden und geschriebenen Bytes können ausgelesen werden. Für das Auslesen wurde Java NIO (Oracle, 2015h) verwendet, da diese API mit dem Ziel entwickelt wurde, möglichst die low-level I/O-Operationen abzubilden und deswegen Problematiken wie Caching der /proc-dateien vermieden werden Abbildung der HDD-Ressource und Demands in PCM Zur Abbildung der HDD Demands und HDD-Ressource werden das PCM Repository Model und das PCM Resource Environment genutzt. In beiden Fällen wurde bei der Integration auf eine vollständige grafische Repräsentation verzichtet. Wie in Brunnert und Krcmar (2015) wird im Folgenden aber zur Erklärung eine schematische grafische Hilfsdarstellung auf Basis von grafischen PCM-Elementen verwendet. Abbildung im Resource Environment Abbildung 12 zeigt die vereinfachte grafische Darstellung eines ResourceContainers im PCM Resource Environment. ResourceContainer sind für die Modellierung einer konkreten Serverinstanz (diese trägt hier beispielhaft den Namen Server ) gedacht und definieren die dortigen Hardware-Ressourcen. In der Abbildung ist hierbei die Modellierung der HDD und der CPU zu sehen. Als Scheduling-Strategie wird für die HDD First-Come-First-Served (FCFS) und für die CPU Processor Sharing gewählt (vgl. Abschnitt 2.2.3). Die Werte für Read Speed und Write Speed spezifizieren die Schreib- und Lesetransferrate der Festplatte pro Zeiteinheit. Diese dort verwendete Zeiteinheit wird unter Nutzung der Processing-Rate-Variable definiert. Ein Wert von 1 bedeutet hierbei Schreib- und Lesetransferraten in der Einheit Sekunde. Die Einheiten für der Read Speed und Write Speed sollten vom Nutzer ferner in der Einheit Bytes gesetzt werden, da dies die Einheit ist, in der die HDD Demands des /proc-dateisystems angegeben werden. 1 Der Name der RuntimeMXBean liefert hierbei einen String im Folgenden Format zurück <pid>@<hostname>. pid ist die native Process ID. 36

47 Bei einem Write Speed von und eine ProcessingRate von 1 wird folglich eine Festplatte mit einer Schreibtransferrate von Bytes/s modelliert. Abbildung 12: Schematische Abbildung der HDD-Ressource im PCM Resource Environment Quelle: Eigene Darstellung Die Anzahl an HDDs und CPUs wird durch den Parameter Number of Replicas angegeben. In diesem Beispiel wird also ein Server mit einer HDD und vier CPUs modelliert. MTTF und MTTR stehen für Mean time between failure bzw. Mean time between repair. Diese Modellierungselemente werden von PCM standardmäßig für die CPU erzeugt, aber im Rahmen dieser Arbeit nicht verwendet. Abbildung im Repository Model Abbildung 13 zeigt die vereinfachte schematische Repräsentation der HDD Demands im Repository Model. Hierbei beginnt der Kontrollfluss zuerst mit einem CPU Demand. Es folgt ein Lesezugriff in der Größe von 4096 Bytes gefolgt von einem Schreibzugriff in Höhe von 8192 Bytes. Obwohl es sich in diesem Beispiel um Werte handelt, die jeweils einem Vielfachen der oft verwendeten Blockgröße von der Festplatte entsprechen, muss dies nicht immer so sein. Dadurch, dass wie bei den CPU Demands alle HDD Demands aus den Messdaten standardmäßig über ihren Mittelwert aggregiert werden, können die Demands beliebige Dezimalzahlen darstellen. 37

48 Je nach dem, auf welchem Server im Resource Environment die Komponente dieser Operation zugeordnet wird, muss der Server also in diesem Fall mindestens die Schnittstelle für die Nutzung der CPU und der HDD anbieten. Abbildung 13: Schematische Abbildung der HDD Demands im PCM Repository Model Quelle: Eigene Darstellung 4.3 Memory-Integration und -Abbildung Wie in Abschnitt 3.4 beschrieben, existiert bereits eine Implementierung zur Erhebung von MEM Demands im RETIT-Framework auf Basis der Java-Technologie. Mit dieser können auch Performance-Modelle generiert werden. Jedoch wurde für das Modell ein sehr einfaches Speichermanagement verwendet, welches es zu erweitern gilt, um einer bessere Vorhersage der Auslastung der MEM-Ressource zu überprüfen. Im Folgenden wird deswegen zuerst die Erhebung der MEM Demands unter Nutzung des RETIT-Monitoringframeworks erläutert. Die Integration und Verwendung dieser Daten im Modellgenerator wird danach beschrieben anhand von generierten PCM-Modellen. Um das Modell des Speichermanagements zu verbessert, wird das reale Speichermanagement der Java-Technologie analysiert und ein daraus resultierender abstrahierter Ansatz für die Verbesserung der Modelgenerierung umgesetzt MEM Demands und deren aktuelle Modellierung im RETIT-Framework Anders als die Hardware-Ressourcen wie CPU, NET und HDD ist es in PCM nicht möglich, MEM im Resource Environment abzubilden (vgl. Abschnitt und Brunnert, Neubig, et al. (2014)). Als Workaround wird deswegen eine Darstellung im PCM Repository Model zur Modellierung genutzt (siehe Abbildung 14). 38

49 Abbildung 14: MEM-Abbildung im PCM Repository Model Quelle: Eigene Darstellung Hierbei nutzt die Komponente die PCM PassiveResource (Palladio, 2015b). Diese definiert eine Kapazität ( ), welche in der Modellierung der MEM-Gesamtkapazität entspricht 1. Operationen können über die beiden Methoden alloc und free auf die Komponente zugreifen. Der jeweils mitübergebenen Parameter (int bytesreleased/bytesrequestes) definiert die Anzahl, die der Gesamtkapazität hinzugefügt (free) oder abgezogen (alloc) wird. Wenn in der Simulation des Modells die PassiveResource durch viele alloc-aufrufe auf null fallen sollte, so müssen alle weiteren alloc-aufrufe erst warten, bis wieder genug Ressourcen freigegeben wurden (free). Es tritt dann also ein Queueing an der Ressource auf. Die Nutzung der MEM-Komponente innerhalb einer Operation ist in Abbildung 15 dargestellt. Zu Beginn der Operation werden direkt Einheiten der PassiveResource allokiert. Danach nutzt die Operation für ~20,69 Einheiten die CPU-Ressource und gibt am Ende immer genau den gleichen Betrag der PassiveResource wieder frei. Abbildung 15: MEM-Nutzung einer Operation im PCM Repository Model Quelle: Eigene Darstellung Diese Modellierung des Speichermanagements der MEM-Ressource kann man vereinfacht als C-ähnliches Speichermanagement bezeichnen. In der C-Programmierung wird in der Regel der dynamische Speicher vom Entwickler allokiert und nach nicht mehr gegebener Nutzungsmöglichkeit wieder manuell freigegeben. 1 Da man die Zahlenwerte der Variable für die Kapazität einer PassiveResource in PCM nicht ausreichend hoch setzen kann, werden alle Variablen der MEM-Ressource vom Generator durch 10 geteilt und somit kontant skaliert. D.h., dass eine Kapazität von im Modell in Wirklichkeit die Abbildung der realen Kapazität von (Bytes) entspricht. 39

50 4.3.2 Das Java-Speichermanagement und eine darauf angepasste PCM-Modellierung Die in Abschnitt angesprochene C-ähnliche Modellierung der MEM-Ressource ist eine Vereinfachung des realen Speichermanagements von Java. Im Folgenden wird realistische Modellierung des Java-Speichermanagements als mögliche Verbesserung für das RETIT- Framework vorgeschlagen. Grundlage des Abschnitts ist die HotSpot VM (Oracle, 2015k), deren Speichermanagement in Abschnitt genauer betrachtet wurde. Angepasste Heap-Modellierung mit Garbage Collection in PCM Die Idee für die angepasste Heap-Modellierung ist es, Garbage Collection abzubilden. Als erster Schritt dafür ist nötig, dass die Operationen durch das aufrufen von free() kein Elemente der PassiveResource mehr freigeben. Der Kontrollfluss innerhalb von free() wurde deshalb entfernt. Stattdessen soll die PassiveResource mittel Major und Minor Garbage Collection Events freigegeben werden. Hierfür wurde das Heap-Interface im Respository Model angepasst (vgl. Abbildung 16). Abbildung 16: GC-Heap-Interface-Erweiterung im PCM Repository Model Quelle: Eigene Darstellung Wenn im Modell ein Garbage Collection Event ausgelöst wird, soll dieses neben dem Freigeben einer gewissen Quantität der PassiveResource auch einen CPU-Verbrauch verursachen. Der Hintergrund ist, dass das Ausführen der Garbage Collection durch den Collector auch die CPU-Ressource nutzt, was jedoch bisher im Modell nicht abgebildet wird, da nur der CPU-Demand der Operationen berücksichtigt wird. Abbildung 17 zeigt diese Modellierung. Anzumerken hierbei ist, dass der CPU-Demand auch abhängig von der Anzahl der freizugebenden Bytes modelliert werden kann. Im Usage Model (vgl. Abbildung 18) werden die Inter-Arrival-Zeiten für die Garbage Collection Events und die Anzahl an Bytes definiert, welche von der PassiveResource freizugeben sind. Im Beispiel wird alle 150s ein Major-GC-Collection-Event ausgelöst. Dieses übergibt Bytes frei, die nach Nutzung der CPU-Ressource freigegeben werden (vgl. Kontrollfluss in Abbildung 17). 40