Evaluatie van DVFS met behulp van synthetische webbenchmarks

Evaluatie van DVFS met behulp van synthetische webbenchmarks Jasper Vanlerberghe

Promotor: prof. dr. ir. Lieven Eeckhout Begeleiders: Stijn Polfliet, Frederick Ryckbosch Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2011-2012

Evaluatie van DVFS met behulp van synthetische webbenchmarks Jasper Vanlerberghe

Promotor: prof. dr. ir. Lieven Eeckhout Begeleiders: Stijn Polfliet, Frederick Ryckbosch Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2011-2012

Toelating tot bruikleen De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

Jasper Vanlerberghe, juni 2012

Voorwoord Hier wil ik graag even plaats maken om enkele mensen te bedanken. Allereerst wil ik mijn familie, in het bijzonder mijn ouders, bedanken voor de kansen die ze mij gegeven hebben. Jullie hebben mij altijd gesteund in alles wat ik deed en me mee gemaakt tot wie ik geworden ben. Bedankt! Daarnaast wil ik ook mijn vrienden en alle chirovrijwilligers bedanken. Jullie zorgden dat ik op tijd en stond een uitlaatklep vond. Ik heb veel van jullie geleerd en hoop in de toekomst deze kennis en vaardigheden door te geven. Bedankt! Verder wil ik nog mijn promotor prof. dr. ir. Lieven Eeckhout bedanken voor het aanbieden van het onderwerp van deze masterproef. Ook Stijn Polfliet en Frederick Ryckbosch die de dagelijkse begeleiding op zich namen: bedankt voor de nuttige feedback. Last but not least wens ik nog mijn moeder en Ine te bedanken om alles grondig na te lezen en al mijn taalfouten te corrigeren. Bedankt dat jullie tot op de laatste minuut klaar stonden!

Evaluatie van DVFS met behulp van synthetische webbenchmarks door Jasper Vanlerberghe Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2011–2012 Promotor: prof. dr. ir. Lieven Eeckhout Begeleiders: ir. Stijn Polfliet, ir. Frederick Ryckbosch Faculteit Ingenieurswetenschappen en Architectuur Universiteit Gent Vakgroep Electronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout

Samenvatting Deze masterproef onderzoekt de invloed op het vermogenverbruik van verschillende werklasten in webapplicaties. Hieruit leiden we een methode af om DVFS toe te passen in datacenters, terwijl we een gewenst niveau voor de prestatie van de applicatie behouden. Met een zelfontwikkelde synthetische webbenchmarkgenerator genereren we pagina’s om deze verschillende werklasten te modelleren. Voor een processorintensieve werklast en een dagverloop van een reëel datacenter kunnen we met onze methode tot 10% energie besparen als we toelaten dat de responstijd verviervoudigd. Willen we dat de responstijd maximaal verdubbeld dan kunnen we nog steeds 5,7% besparen. We stellen ook vast dat het toepassen van DVFS geen nut heeft wanneer de request geen dynamische verwerking vergt op de server of de processor voortdurend geblokkeerd staat te wachten hetzij op I/O, hetzij op het antwoord op een externe aanvraag. We besluiten dat onze methode te verkiezen blijft ten opzichte van het uitschalen van meerdere servers ingesteld op de laagste klokfrequentie, zelfs als in de toekomst het statisch vermogen van servers tot 96% afneemt.

Trefwoorden Energiebesparing, datacenter, webapplicatie, Dynamic Voltage Frequency Scaling, synthetische webbenchmark

Evaluation of DVFS using Synthetic Webbenchmarks Jasper Vanlerberghe Supervisors: Stijn Polfliet, Frederick Ryckbosch Promoter: Lieven Eeckhout Abstract— Energy saving in data centers is a very popular topic nowadays. Several methods using Dynamic Voltage and Frequency Scaling (DVFS) have been developed. This article explores the influence of using DVFS on the power usage and performance of web applications. Keywords— Data center, energy saving, web application, Dynamic Voltage and Frequency Scaling, synthetic webbenchmarks

I. Introduction There is an increasing demand to make server systems energy-proportional [1]. This way servers consume energy proportional to the amount of work they perform. In embedded systems this has been a design constraint for years and now it is becoming more important in server systems. Servers are heavily underused, they seldom operate near their maximum utilization. On the other hand they are also seldomly completely idle [1]. Dynamic Voltage and Frequency Scaling (DVFS) is a technique that can be used to make these servers more energy-proportional. Several methodes using DVFS have been developed for data centers hosting web applications [2], [3]. These techniques however did not address the influence on the energy usage and response time of different workloads in the web application spectrum. Also the influence of setting a maximum threshold on the possible energy savings with DVFS where not the center of these papers. This article aims at filling in this gap. We have specifically examened the influence of different possible workloads on the energy usage and response time when using DVFS. To generate these different workloads we developed a synthetic webbenchmark generator. From these findings we have derived a method to use DVFS that can save 10% energy provided that the response time is allowed to multiply by four. This paper also covers the influence of the setting of this threshold. II. Generating workloads In order to be able to generate different workloads for a webserver, we built a synthetic webbenchmark generator. With this generator it is possible to generate several PHP pages representative for some kind of web application. We based the architecture of our generator on an existing synthetic C benchmark generator [4]. Our benchmarkgenerator works as follows. First the user has to create a configuration file containing the form and the properties of the desired benchmarks. This file is subsequently fed to the generator together with the required number of benchmarks. The generator subsequently outputs this number of PHP pages according tot the data in the supplied configuration file.

The generated PHP pages consist of several building blocks. Each building block models a certain kind of behaviour of a web application. For web applications we identified five kinds of building blocks: CPU intensive blocks, memory intensive blocks, output intensive blocks, I/O intensive blocks and external requests. III. Experimental setup For the experiments in this article we used a stateof-the-art server with an Intel Xeon E3-1230 processor. This server has an idle power use of 39W. We measure the power usage of this server at the plug using a Rackativity EnergySwitch. The server uses Linux 2.6 as operating system. We installed the Apache 2.2 webserver and PHP 5.3. We used the cpufrequtils-package to switch between different clock frequencies for the processor. Using Tsung 1.4 on a separate server we conducted several five minute long experiments. Tsung generated requests for the webserver according to a set request rate. The interarrival times for these requests are generated from an exponential distribution. During these experiments we measured the power usage of the webserver and the CPU utilization (using vmstat). We conducted these experiments for varying clock frequencies, request rates and pages. Each experiment was repeated five times to rule out random deviations. IV. Experimental results For a CPU intensive page the results are shown in Fig. 1. The top graph shows the relative response time versus the request rate for different clock frequency settings. The relative response time is calculated by dividing the response time by the response time obtained for the highest clock frequency and the lowest request rate. The bottom graph shows the power usage versus the request rate for various clock frequencies. We can see in the figure that the power usage grows when the request rate increases. For a higher clock frequency and the same request rate the server will use more power. So in terms of energy it is best to leave the server at the lowest clock frequency. However for web applications performance is a key requirement. The user only has a limited amount of patience before he gives up waiting for your application to respond. In the top half of the figure we can see that the lowest clock frequency can only handle a limited request rate before the response time explodes. So setting the clock frequency is finding the correct balance between the energy consumption and the response time. From the data and the charts obtained for this page we can deduct a DVFS scheme. First we have to set a maximum threshold for the response time. If we want to indicate this threshold in the chart we have

Load of data center Threshold: 5 Threshold: 3 Threshold: 2

Request rate (requests/s)

14

3,2

12 10 2,4

8 6 4

Clock frequency (GHz)

16

2 1,6 0

2

4

6

8

10

12

14

16

18

20

22

24

Hour of the day

Fig. 2: Request rate changes during the day and DVFS schemes for a real life data center

Fig. 1: Results for processor intensive pages and example of a derivation of a DVFS scheme

to calculate the relative threshold. This threshold will thus depend on the standard response time of the page. For pages having small response times there will be more margin for increasing the response time than for pages that already take a long time to load. Suppose we take three as the threshold for the maximum relative response time. This means we allow the response time of the page to triple. With this threshold we can use the lowest clock frequency up to a request rate of 7 req/s. From that point on we have to switch to 2.4GHz until the request rate increases to 12.5 req/s when there should be switched to the highest clock frequency. This scheme is indicated in the top chart with the thick black line. Implementing this scheme we save the amount of power indicated by the gray areas in the bottom graph. In a real life data center the request rate changes during the day. So we can use the knowledge of these request rate changes during the day to switch the data center to the most energy efficient clock frequency each time of the day. We have rescaled the request rate course of a real data center to match the capacity of our server. So at the busiest moment of the day the server gets 16 req/s. This is indicated in Fig 2 using the left y-axis. In the same figure DVFS schemes for different thresholds for the maximum response time are also shown using the right y-axis. Using a threshold of four or five we can save up to 10% on the energy bill. For a threshold of three this is 8.9%, and for a threshold of two decreases further to 5.7%. This DVFS method uses less energy than deploying more servers and configuring them to use the lowest

clock frequency. This is due to the large amount of static power use of the servers. We did simulations for decreasing amounts of static power and concluded that DVFS stays the most energy efficient even if the static power usage of servers decreases 96%. For memory intensive pages we obtained the same results, with this difference that they use more power because of the added energy consumption of the caches and the memory. One exception for this is pages using a large data structure that does not longer fit in any of the CPU caches and that is subsequently accessed using a random pattern. In this situation the CPU frequently has to wait for the main memory, this results in a smaller use of the higher clock frequencies in a DVFS scheme. For pages that do not require dynamic processing on the server, like output intensive pages, the pages do not generate enough CPU utilization to make DVFS useful. Also for pages that have to wait for other entities, like I/O intensive pages or pages with external requests, the CPU is waiting most of the time and DVFS no longer influences the power usage. V. Conclusion DVFS has the potential to save a significant amount of energy in data centers hosting web applications. This is particularly useful for CPU intensive and memory intensive workloads. Even when the static power dissipation of servers decreases this DVFS method performs better than deploying more servers using the lowest clock frequency. References [1] L. Barroso and U. Holzle, “The case for energy-proportional computing,” Computer, vol. 40, no. 12, pp. 33–37, 2007. [2] T. Horvath, T. Abdelzaher, K. Skadron, and X. Liu, “Dynamic voltage scaling in multitier web servers with end-to-end delay control,” Computers, IEEE Transactions on, vol. 56, no. 4, pp. 444–458, 2007. [3] Y. Chen, A. Das, W. Qin, A. Sivasubramaniam, Q. Wang, and N. Gautam, “Managing server energy and operational costs in hosting centers,” in ACM SIGMETRICS Performance Evaluation Review, vol. 33, pp. 303–314, ACM, 2005. [4] K. Du Bois, T. Schaeps, S. Polfliet, F. Ryckbosch, and L. Eeckhout, “SWEEP: evaluating computer system energy efficiency using synthetic workloads,” in Proceedings of the 6th International Conference on High Performance and Embedded Architectures and Compilers, pp. 159–166, ACM, 2011.

ix

Inhoudsopgave Toelating tot bruikleen

iv

Voorwoord

v

Overzicht

vi

Extended abstract

vii

Inhoudsopgave

ix

Gebruikte afkortingen

xi

1 Inleiding 1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Oplossingsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Inhoud van deze masterproef . . . . . . . . . . . . . . . . . . . . . . . 2 Literatuurstudie 2.1 Energiebesparing en toekomst voor hardwareontwerp 2.2 Energiebesparingstechnieken in servers . . . . . . . . 2.3 Energievoorziening in datacenters . . . . . . . . . . . 2.4 DVFS in webapplicaties . . . . . . . . . . . . . . . . 2.5 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . 3 Testomgeving 3.1 Overzicht . . . . . . . . . . . . . . . 3.1.1 Processor . . . . . . . . . . . 3.1.2 Andere . . . . . . . . . . . . . 3.2 Vermogenmetingen . . . . . . . . . . 3.3 Vermogenverdeling over componenten 3.3.1 Onbelaste vermogenverdeling 3.3.2 Belaste vermogenverdeling . . 3.3.3 Conclusie . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

1 1 1 2

. . . . .

4 4 5 7 9 10

. . . . . . . .

11 11 12 13 13 14 14 15 17

INHOUDSOPGAVE 4 Invloed van de werklast 4.1 Inleiding . . . . . . . . 4.2 Gekozen benchmarks . 4.3 Vermogenverbruik . . . 4.4 Uitvoeringstijd . . . . 4.5 Energieconsumptie . . 4.6 Conclusies . . . . . . .

x

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Synthetische webbenchmarks 5.1 Webapplicaties . . . . . . . . . . . . . . . . 5.2 PHP . . . . . . . . . . . . . . . . . . . . . . 5.3 Benchmarks . . . . . . . . . . . . . . . . . . 5.4 Synthetische webbenchmarks . . . . . . . . . 5.4.1 Synthetische C benchmarkgenerator . 5.4.2 Synthetische webbenchmarkgenerator 5.4.3 Processorintensieve bouwblokken . . 5.4.4 Geheugenintensieve bouwblokken . . 5.4.5 I/O-intensieve bouwblokken . . . . . 5.4.6 Outputintensieve bouwblokken . . . 5.4.7 Bouwblok met externe aanvragen . . 5.5 Conclusie . . . . . . . . . . . . . . . . . . . 6 Experimentele resultaten 6.1 Inleiding . . . . . . . . . . . . . 6.2 Meetopstelling . . . . . . . . . . 6.3 Processorintensieve werklast . . 6.4 Geheugenintensieve werklast . . 6.5 Outputintensieve werklast . . . 6.6 Werklast met externe aanvragen 6.7 I/O-intensieve werklast . . . . . 6.8 Toepassing . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . .

19 19 19 20 21 22 23

. . . . . . . . . . . .

25 25 27 27 29 29 30 30 34 37 39 39 39

. . . . . . . .

41 41 41 42 46 49 51 53 55

7 Conclusies

59

Bibliografie

61

Lijst van figuren

64

Lijst van tabellen

66

xi

Gebruikte afkortingen ACPI APC ASP BIOS CMOS CPU DDR RAM DRPM DVFS GPHT HT HTML IIDD ILP I/O IP IPC IT JSP LAN PARSEC PDU PHP RTT SLA SOAP TB TCP SWEEP TDP

Advanced Configuration and Power Interface Alternative PHP Cache Active Server Pages Basic Input Output System Complementary Metal Oxide Semiconductor Central Processing Unit Double Data Rate Random Access Memory Dynamic Rotations Per Minute Dynamic Voltage and Frequency Scaling Global Phase History Table Hypertreading Hypertext Markup Language Inter-instruction Dependency Distance Instruction-level Parallelism Input / Output Internet Protocol Instructions Per Cycle Information Technology Java Server Pages Local Area Network Princeton Application Repository for Shared-Memory Computers Power Distribution Unit Hypertext Preprocessor Round-trip Time Service Level Agreement Simple Object Access Protocol Turboboost Transmission Control Protocol Synthetic Workloads for Energy Efficiency and Performance evaluation Termal Design Power

1

Hoofdstuk 1 Inleiding 1.1

Probleemstelling

Uit heel wat studies blijkt dat de IT-sector verantwoordelijk is voor een groot deel van de CO2 -uitstoot wereldwijd. Een studie van Gartner in 2007 [1] dicht de IT-sector 2% van de CO2 -uitstoot toe, evenveel als de luchtvaartsector. In die 2% zit enkel de gebruiksfase van PC’s, servers, koeling, printers, vaste en mobiele telefonie, LANs en kantoortelecommunicatie. De CO2 uitgestoten bij de productie van deze apparaten zorgt voor een extra milieubelasting. Een andere studie van McKinsey&Company in 2008 [2] stelt dat het energieverbruik van alle datacenters wereldwijd tussen 2000 en 2006 verdubbeld is. In 2008 verbruikten alle datacenters evenveel als 25000 huishoudens. Dit enorme verbruik leidt tot een CO2 -uitstoot die groter is dan die van Nederland en Argentinië. Volgens diezelfde studie is de gemiddelde dagelijkse belasting van de servers in een datacenter slechts 6%. Door de stijgende energieprijzen en de nood om de CO2 -uitstoot zoveel mogelijk te beperken ontstaat dus de vraag naar milieuvriendelijke en energie-efficiënte manieren om datacenters te beheren en te ontwerpen. Aangezien de gemiddelde belasting in datacenters laag is, is er zeker ruimte voor verbetering.

1.2

Oplossingsmethode

Er bestaan heel wat technieken om de prestatie en het energieverbruik van datacenters te optimaliseren. Voorbeelden van deze technieken zijn Disk Power Management, Variable Speed Fans, virtualisatie, DVFS (Dynamic Voltage Frequency Scaling), server throttling ... In deze masterproef spitsen we ons toe op datacenters voor webapplicaties en hoe DVFS, het dynamisch schalen van de klokfrequentie en voedingsspanning van de

HOOFDSTUK 1. INLEIDING

2

processor, deze datacenters zou kunnen optimaliseren. Volgens Barroso et al.[3] zijn servers zelden volledig idle of volledig belast. Hun belasting varieert meestal tussen de 10% en de 50% afhankelijk van de specifieke aangeboden service. Dit zorgt dat DVFS een stuk geschikter is dan server throttling. De techniek server throttling zet onbelaste servers in slaapstand of uit. Aangezien servers zelden volledig onbelast zijn, kunnen die daarom niet uitgezet worden. Daarnaast is het zo dat de data opgeslagen in het datacenter veelal gedistribueerd is over het volledige serverpark en het uitschakelen van servers dus zou leiden tot het onbeschikbaar worden van een deel van de data. DVFS werkt ook op een veel kleinere tijdsschaal dan server throttling, binnen enkele processorcycli kan overgeschakeld worden naar een andere klokfrequentie en voedingsspanning. Het aan of uit zetten van een server duurt typisch tientallen seconden tot een minuut. De belasting op webservers is afhankelijk van de webpagina’s die aangeboden worden. In deze masterproef proberen we zo algemeen mogelijk te werken en dus het volledige spectrum aan mogelijke webpagina’s te bestrijken. Daarom maken we gebruik van synthetische webpagina’s om verschillende aspecten te testen. Om dit gemakkelijk te kunnen doen, hebben we dan ook een synthetische webbenchmarkgenerator ontwikkeld.

1.3

Inhoud van deze masterproef

In het tweede hoofdstuk bekijken we enkele bestaande methoden om energie te besparen in datacenters en toepassingen van DVFS. We leggen de relatie tussen de literatuur en deze masterproef. Het daaropvolgende hoofdstuk handelt over het gebruikte testsysteem voor de experimenten uitgevoerd in deze masterproef. We bekijken de specifieke eigenschappen van de aanwezige hard- en software. Via een eerste set experimenten trachten we te achterhalen wat de vermogenconsumptie van elke component in het systeem is. Vervolgens spitsen we ons toe op de invloed van de werklast op de meest energieefficiënte klokfrequentie. Hiervoor gebruiken we de PARSEC benchmarks. We concluderen dat voor deze applicaties het soort werklast wel degelijk een invloed heeft op de optimale klokfrequentie. In Hoofdstuk 5 zoomen we in op het verschil tussen traditionele applicaties en webapplicaties. We leggen het verband met de PARSEC benchmarks en webbenchmarks. Dit leidt ons tot het ontwikkelen van een synthetische webbenchmarkgenerator op het einde van dat hoofdstuk. Met behulp van deze webbenchmarkgenerator onderzoeken we in het laatste hoofdstuk de invloed van verschillende werklasten op de energieconsumptie van webtoe-

HOOFDSTUK 1. INLEIDING

3

passingen. We gaan na hoe DVFS aangewend kan worden om een energiebesparing te bekomen. We besluiten met een concrete toepassing op een realistisch datacenter en onderzoeken de invloed van een toekomstige daling van het statisch vermogen op de relevantie van dit werk. In het laatste hoofdstuk ten slotte herhalen we nog even kort de belangrijkste vaststellingen uit deze masterproef.

4

Hoofdstuk 2 Literatuurstudie Energiebesparing in datacenters is een actueel thema. De oorzaak hiervoor is drieledig. Ten eerste worden datacenters alsmaar groter waardoor het moeilijk wordt om deze datacenters nog van genoeg energie te voorzien. Ten tweede is er ook de vraag naar milieubewustere IT oplossingen. Als laatste zijn er ook nog de stijgende energieprijzen. In dit hoofdstuk nemen we de relevantste papers met betrekking tot het onderwerp in deze masterproef onder de loep. Eerst bekijken we hoe verschillende auteurs de huidige mogelijkheden en de toekomstige evolutie in hardwareontwerp zien. Daarna zoomen we in op een aantal energiebesparende technieken voor individuele servers. Vervolgens bekijken we enkele technieken op het niveau van een volledige datacenter. In de laatste sectie spitsen we ons specifiek toe op datacenters die webapplicaties hosten.

2.1

Energiebesparing en toekomst voor hardwareontwerp

Barosso en Hölze [3] beschrijven de nood om servers — en in het bijzonder dus ook hun individuele componenten — energieproportioneel te maken. Dit houdt in dat de hoeveelheid energie die deze servers gebruiken in gelijke verhouding moet staan met hoeveel werk ze verrichten. Als de server onbelast is, verbruikt hij idealiter geen energie. Veel componenten proberen hieraan tegemoet te komen door inactive low-power modes te implementeren. Dit zijn toestanden waarin de component weinig verbruikt maar waarin ook geen werk geleverd wordt. Veelal is ook een aanzienlijke transitietijd nodig om tussen deze toestanden te schakelen. De auteurs van dit artikel halen aan dat deze technieken minder geschikt zijn voor servers, aangezien servers zelden volledig onbelast zijn. Er is nood aan active low-power modes. Voor processoren

HOOFDSTUK 2. LITERATUURSTUDIE

5

bestaat er Dynamic Voltage and Frequency Scaling (DVFS). Op technieken voor het geheugen en de schijven is het nog even wachten. Esmaeilzadeh et al. [4] onderwierpen verschillende processoren in een periode van bijna tien jaar aan een uitgebreide set benchmarks. Hiermee testten ze het vermogenverbruik en de prestatie van deze processoren en hun verschillende features. De gebruikte set benchmarks bevatte niet enkel benchmarks in gecompileerde native code maar ook in managed languages. Programma’s in gecompileerde native code, zijn veelal geschreven in een hogere programmeertaal, zoals C of C++ die dan gecompileerd wordt naar machine-instructies die de processor rechtstreeks uitvoert. Tegenwoordig is zogenaamde ’managed code’ echter ook zeer populair, vanwege de portabiliteit en hun automatisch geheugenbeheer bijvoorbeeld. Managed code is code die uitgevoerd wordt in een virtuele machine, die de programmacode tijdens de uitvoering vertaalt naar machine-instructies. Voorbeelden van gemanagede programmeertalen zijn Java, PHP, C#. Uit de resultaten van de uitvoering van de set benchmarks doen de auteurs een aantal vaststellingen met betrekking tot enerzijds de gebruikte werklast en anderzijds de processorarchitecturen. De auteurs concluderen met een aantal aanbevelingen voor ontwerpers van processorchips en onderzoekers. Zo moedigen ze de ontwerpers en fabrikanten van chips aan om de aanwezige vermogenmeters op de chips open te stellen voor de gebruikers. Dat zou onderzoeken waarbij vermogenmetingen van de processor nodig zijn, gemakkelijker maken. Daarnaast zal het ook eenvoudiger zijn om de parameters van de processor (klokfrequentie, turboboost, hyperthreading ...) te finetunen naar de werklast die hij te verwerken zal krijgen. Onderzoekers worden aangemoedigd om naast native ook gemanagede werklasten aan te wenden. Als laatste geven de auteurs de richtlijn mee om het vermogenverbruik en de prestatie tegelijk te meten om op die manier het vermogenverbruik, de prestatie en het energieverbruik te begrijpen en te optimaliseren. Deze richtlijnen respecteren we in deze masterproef. We gebruiken PHP voor onze werklast in combinatie met de Apache server die tot native code gecompileerd is. Daarnaast focust deze masterproef vooral op de trade-off tussen prestatie en vermogenverbruik.

2.2

Energiebesparingstechnieken in servers

Naast onderzoek naar de vereisten van de volgende generatie hardware is er ook onderzoek om technieken te ontwikkelen die nu reeds bruikbaar zijn. Deze technieken benutten de mogelijkheden die in hedendaagse hardware aanwezig zijn, hoewel de onderzoeken ook dikwijls tekorten in de huidige hardware blootleggen. Powernap [5] is een techniek die de inactive low-power modes van componenten


6

benut. Het systeem probeert tijdens de volledig onbelaste intervallen in de servers, alle componenten in hun eigen low-power mode te zetten wanneer het systeem onbelast is. Wanneer er dan nieuw werk binnenkomt, worden alle componenten terug in hun normale toestand gebracht. Om dit systeem te kunnen toepassen zijn er twee vereisten. Enerzijds is het nodig dat elke component een low-power mode heeft en het energieverbruik in die toestand minimaal is. Anderzijds moet de transitie tussen deze low-power mode en de actieve toestand zeer snel gebeuren. Vooral de combinatie van de twee vereisten is in de huidige serverhardware nog een heikel punt, terwijl veel componenten in ingebedde systemen deze eigenschappen wel al bezitten. In servers is deze techniek dus nog niet echt bruikbaar, omwille van de te lange transitietijden t.o.v. de lengte van de onbelaste periodes. Vooral in webservers zijn deze onbelaste periodes doorgaans zeer kort. Het uitvoeren van een bepaalde werklast heeft meestal een aantal verschillende fasen. Zo zijn er bijvoorbeeld geheugenintensieve fases en fases met een hoge Instructions Per Cycle waarde (IPC). Isci en Martonosi ontwikkelden twee methodes [6, 7] om de verschillende fases tijdens het uitvoeren van een werklast te voorspellen. Met die voorspelling kunnen ze dan, gebruik makend van DVFS, de processor naar zijn ideale klokfrequentie voor die fase schalen en op die manier energie besparen. Hun eerste methode [6] schakelt hardware performance counters in om de waarde van een bepaalde metriek te schatten, bijvoorbeeld de IPC waarde. Deze metriek moet representatief zijn om de verschillende fases te beschrijven. Het algoritme maakt dan enerzijds een voorspelling van de toekomstige waarde en anderzijds een voorspelling van hoe lang die toekomstige waarde stabiel zal blijven. Tijdens een geheugenintensieve fase zou dan, door toepassing van DVFS, energie bespaard kunnen worden. Het artikel vermeldt echter geen concrete resultaten over behaalde energiewinsten of prestatieverlies. Hun tweede methode [7] maakt gebruik van technieken geadopteerd van sprongvoorspellers. Na een vast aantal uitgevoerde instructies wordt telkens het voorbije interval gelabeld overeenkomstig het karakter van de voorbije fase. Uit de labels van de voorbije x aantal intervallen wordt dan met behulp van een global phase history table (GPHT) de volgende fase voorspeld. De werking van de GPHT is volledig analoog aan de werking van een global branch history table bij sprongvoorspellers. Gebruik makend van de voorspelling van de nieuwe fase kan dan opnieuw DVFS toegepast worden. De auteurs bekomen hiermee een gemiddelde verbetering van 27% in het energy delay product bij een prestatieverlies van 5%. In beide papers worden geen webapplicaties gebruikt, er is ook geen aandacht voor de invloed van verschillen in de werklast. In deze masterproef spitsen we ons specifiek toe op deze twee aandachtspunten.


2.3

7

Energievoorziening in datacenters

Naast het onderzoek om energie te besparen is er ook veel onderzoek om het totale verbruik van een datacenter te controleren. Meestal zijn datacenters naar vermogenverbruik toe overgedimensioneerd. Er wordt dus heel wat geld ge¨ınvesteerd in energiedistributie-infrastructuur die nooit ten volle benut wordt. Deze onderzoeken proberen technieken te ontwikkelen die het toelaten om meer servers in een datacenter te plaatsen op een zodanige manier dat hun geaggregeerd verbruik nooit het maximum toegelaten verbruik overschrijdt. Mocht het datacenter toch zijn maximum vermogenbudget overschrijden dan kunnen zekeringen springen en (stukken van) het datacenter uitvallen. Aangezien datacenters veelal gebonden zijn aan Service Level Agreements (SLA’s) die boetes voorschrijven bij pannes, is dit niet wenselijk. Fan et al. [8] beschrijven de vaststelling dat het gesommeerde piekverbruik een slechte schatter is voor het piekverbruik van het volledige datacenter. Theoretisch gezien zou het mogelijk zijn om die waarde te bereiken, op voorwaarde dat men als piekverbruik voor een server al een realistische waarde neemt en niet het aangeduide maximum vermogenverbruik van de server. Dit maximum vermogenverbruik is altijd een zeer ruime bovengrens en wordt in realiteit nooit bereikt. Verder stellen de auteurs vast dat nooit alle servers in het datacenter tegelijk hun piekwaarde bereiken, waardoor in realiteit het datacenter als geheel ook nooit die gesommeerde piekwaarde bereikt. Hierdoor zouden 7–16% meer servers geplaatst kunnen worden in goed gedimensioneerde datacenters en tot 39% in reële datacenters. De auteurs gaan nog verder door DVFS toe te passen. Op die manier kunnen ze het piekverbruik nog verder doen dalen en de variatie tussen het gemiddeld verbruik en het piekverbruik van het datacenter verkleinen. Daardoor zouden nog eens 7–10% extra servers gedeployed kunnen worden. Raghavendra et al. [9] en Wang et al. [10] beschrijven beiden een concrete architectuur om DVFS toe te passen om het vermogenverbruik van het volledige datacenter te kunnen sturen. Beide beschreven architecturen zijn hiërarchisch opgebouwd uit een aantal niveaus. Elk niveau krijgt daarbij een budget toegewezen van het bovenliggende niveau, waaruit het de budgetten voor de onderliggende niveaus afleidt. Op het laagste niveau bepaalt dit budget welke klokfrequentie de server zal instellen. Het SHIP systeem [10] gebruikt hiervoor drie niveaus: server, rack en datacenter. Raghavendra et al. [9] gebruiken een uitgebreidere architectuur met vijf niveaus. Naast DVFS wenden ze ook server throttling aan. Door de functionaliteiten van een aantal servers te heralloceren op andere servers, kunnen ze enkele servers uitschakelen. Daardoor kunnen ze, terwijl ze erover waken dat het datacenter zijn maximaal toegelaten vermogenverbruik niet overschrijdt, tijdens periodes met minder belasting ook flink wat energie besparen.


8

In al deze studies wordt echter weinig aandacht besteed aan de invloed van deze technieken op de prestatie. Dat maakt dat deze technieken ook eerder geschikt zijn voor werklasten die langer lopen en dus niet voor hosting datacenters met hun kenmerkende zeer korte requests. In deze masterproef zijn webservers net de focus en is de invloed op de prestatie dus een essentieel onderdeel van het onderzoek. Naast de eerder vermelde systemen om het piekverbruik te controleren, wordt in [11] een andere methode voorgesteld. Deze methode werkt door het piekverbruik van een enkele server te controleren. Uit [8] weten we dat dit het piekverbruik van het volledige datacenter ook terugdringt. De voorgestelde methode bestaat er in elke component van het systeem een bepaald vermogenbudget te geven voor een bepaald interval. Eens dat budget opgebruikt is, voert de component geen werk meer uit tot het volgende interval begint en hij een nieuw budget krijgt. Het systeem maakt voorspellingen over de toekomstige activiteit van de componenten en verschuift zo de budgetten naar de componenten die ze nodig hebben. De auteurs stellen voor om DVFS toe te passen en zo het budget van de processor te controleren. Er is ook ruime aandacht voor de invloed op de prestatie. In dit onderzoek zijn wel enkel langer lopende werklasten getest. Deze masterproef kan een aanvulling zijn bij dit artikel [11] om specifiek de invloed van DVFS op de werklasten van webservers te kennen. Al worden in deze masterproef geen beperkingen opgelegd aan de geheugenactiviteit. Isci et al. [12] beschrijven een methode om het verbruik van een multicore processor te begrenzen tot een vooropgestelde waarde. Deze methode kan gebruikt worden in de techniek beschreven in [11] om het verbruik van een volledige server te beperken. De auteurs onderzoeken hier welke impact het individueel schalen van de verschillende cores zou hebben. Ze ontwikkelen een methode om zo de prestatie te maximaliseren en fairness te behouden terwijl ze het verbruik van de processor begrenzen. Momenteel zijn echter nog geen processoren op de markt die het toelaten om verschillende cores een andere klokfrequentie en voedingsspanning aan te leggen. Hun methode presteert stukken beter dan een gelijke schaling op alle cores. Met slechts drie discrete klokfrequenties kunnen ze een vloeiende prestatie/vermogenverbruik-curve bekomen, waar de gelijke schaling op alle cores slechts een trapvormige curve bekomt. Ze tonen aan dat met hun methode slechts drie discrete klokfrequentieniveaus nodig zijn, terwijl een gelijke schaling op alle cores veel meer (afhankelijk van het aantal cores) discrete niveaus nodig heeft om een gelijkaardige prestatie te bekomen.


2.4

9

DVFS in webapplicaties

Veel van de technieken ontworpen voor algemene datacenters zijn niet getest voor datacenters die webapplicaties hosten. Webapplicaties verschillen op veel manieren van traditionele applicaties, dit maakt veel technieken ongeschikt voor gebruik in hosting datacenters. Voor webapplicaties zijn er bijvoorbeeld zeer strenge vereisten omtrent de responstijd en aldus de prestatie. Chen et al. [13] stellen een systeem gebaseerd op regeltechniek of wachtlijntheorie voor, specifiek voor hosting datacenters. Hiervoor maken ze gebruik van DVFS naast server throttling. In deze studie brengen ze ook de kosten verbonden aan het verhoogd risco op falen bij het uit- en aanzetten van servers in rekening. In deze methode komt de prestatie voorgeschreven in de SLA’s waaraan datacenters moeten voldoen, uitgebreid aan bod. De techniek is ontwikkeld voor datacenters waar meerdere applicaties met verschillende SLA’s gehost worden. De auteurs schenken hier echter geen aandacht aan de verschillende types werklast die mogelijk zijn binnen een webapplicatie en de invloed daarvan op het energieverbruik en de prestatie bij gebruik van DVFS. Als metriek voor de responstijd hanteren ze de bestandsgrootte van het gevraagde bestand en gaan ze er van uit dat de responstijd omgekeerd evenredig is met de gebruikte klokfrequentie. Deze masterproef toont aan dat dit niet het geval is voor alle werklasten. In [14] wordt ten slotte een meerlagig datacenter voor webapplicaties beschouwd. Zo een meerlagig datacenter bestaat bijvoorbeeld dikwijls uit webservers op de eerste laag, applicatieservers op de volgende en databaseservers op de laatste laag. Elke laag kan dan indien nodig, afhankelijk van de specifieke aanvraag, een aanvraag sturen naar de onderliggende laag. Een request voor een afbeelding kan bijvoorbeeld afgehandeld worden door de webserver zelf, terwijl een aankoop in een webshop ook verwerking vergt van de applicatie- en databaseservers. De in deze laatste paper [14] voorgestelde methode meet de end-to-end delay en bedient zich van regeltechniek om de klokfrequentie op de verschillende lagen te schalen zodat een maximum delay gerespecteerd wordt. Daarbij wordt vooral de processorbelasting als metriek ingeschakeld om te beslissen welke server geschaald zal worden. Met deze methode kunnen de auteurs tot 30% van de totale energie besparen bij een matige belasting. Ze hebben voor deze testen wel laptops gebruikt in plaats van echte serverhardware. Dit artikel gaat opnieuw niet dieper in op de verschillende werklasten en ook de invloed van de vooropgestelde end-to-end delay wordt hier niet verder bekeken. In deze masterproef komen deze laatste twee aspecten wel aan bod.


2.5

10

Conclusies

In dit hoofdstuk presenteerden we een kort overzicht van de huidige state-of-the-art methodes om energie te besparen in datacenters door middel van DVFS. Ook enkele andere applicaties van DVFS kwamen aan bod. Veel van de gepresenteerde artikels hebben weinig aandacht voor de invloed van een verschillende werklast. De methodes zijn meestal niet ontwikkeld voor webapplicaties, terwijl deze applicaties specifieke prestatievereisten hebben. Deze masterproef kan een nuttige aanvulling zijn op deze artikels aangezien wij specifiek de invloed van DVFS op de prestatie van webapplicaties onderzoeken. Daarnaast bekijken we ook de invloed van verschillende werklasten. Zodoende kan de impact op de prestatie van de methodes in de gepresenteerde artikels voor verschillende werklasten geschat worden op basis van deze masterproef.

11

Hoofdstuk 3 Testomgeving De energie-efficiëntie van server hardware evolueert zeer snel, daarom is het belangrijk om een recent systeem te gebruiken. De testomgeving, gebruikt in deze masterproef, bestaat uit een state-of-the-art server. De hardware in deze server werd zorgvuldig uitgekozen om enerzijds energiezuinig te zijn maar anderzijds ook representatief voor servers in een huidig datacenter. In de volgende secties gaan we eerst dieper in op de specifieke eigenschappen van de gebruikte hardware. Daarna proberen we een inschatting te maken van het vermogenverbruik van de individuele componenten.

3.1

Overzicht

Alle testen in deze masterproef werden uitgevoerd op dezelfde server. De voornaamste gegevens van deze server staan in Tabel 3.1. De volgende onderdelen gaan dieper in op een aantal eigenschappen van het systeem in kwestie. Moederbord: Processor: Geheugen: Harde schijf: Besturingssysteem:

Supermicro x9scl-f-b Intel Xeon E3-1230 16GB Kingston DDR3-RAM 2TB Western Digital Green Ubuntu 11.04 server Linux 2.6.38-8-server x86 64

Tabel 3.1: Overzicht testsysteem

HOOFDSTUK 3. TESTOMGEVING

3.1.1

12

Processor

De processor in dit systeem is een Intel Xeon E3-1230 [15]. Deze maakt deel uit van de Sandy Bridge microarchitectuur van Intel. De Sandy Bridge generatie is gemaakt met 32nm procestechnologie van Intel. Door de kleinere technologieschaal dan vroegere generaties is deze processor een stuk energiezuiniger dan zijn voorgangers. De belangrijkste eigenschappen van de processor staan opgesomd in Tabel 3.2. Xeon E3-1230 Cores: 4 Draden: 8 (Intel Hyperthreading) Maximale klokfrequentie: 3,2 GHz 3,6 GHz (Intel Turboboost) L1 Cache data: 4x 32KB L1 Cache instructies: 4x 32KB L2 Cache: 4x 256KB Shared L3 Cache: 8 MB Thermal Design Power: 80W Intel Speedstep: 9 niveaus (3,2 3,0 2,8 2,6 2,4 2,2 2,0 1,8 1,6 GHz) Tabel 3.2: Overzicht processor Xeon E3-1230

Intel Speedstep is de marketing naam van Intel voor Dynamic Voltage and Frequency Scaling (DVFS). Bij gebruik van DVFS worden de voedingsspanning en de klokfrequentie van de processor geschaald. Als men de klokfrequentie van de processor naar beneden schaalt, zal de processor minder vermogen verbruiken, maar ook minder werk per tijdseenheid uitvoeren. Deze techniek is beschikbaar in quasi elke hedendaagse processor. De schaling gebeurt in een aantal discrete stappen, het aantal mogelijke stappen is afhankelijk van het processormodel. Deze discrete stappen worden in de Advanced Configuration and Power Interface (ACPI) [16] performance states genoemd en worden genummerd van P0 (beste prestatie) tot Pn-1 met n het aantal discrete niveaus. De processor in ons testsysteem heeft negen niveaus en dus P-states van P0 tot P8. Om te schakelen tussen deze verschillende P-states maken we gebruik van het cpufrequtils pakket [17]. De Thermal Design Power (TDP) van de processor is 80W. Dit betekent dat het volstaat om een koeling voor de processor te voorzien die 80W aan warmte kan afvoeren. Dit is een maximum door de fabrikant gekozen ruim boven wat de processor ooit kan verbruiken. Het minimale vermogenverbruik van de processor is 5,5W in de C6-state. De C-states zijn mogelijke slaapstanden voor de processor, deze zijn


13

ook gedefinieerd in de ACPI. De C0-state is de operating state en C6 de diepste slaapstand. Voor stijgende n heeft de Cn-state een lager vermogenverbruik en een hogere transitietijd om terug over te schakelen naar de operating state. In de C6-state worden geen instructies uitgevoerd en de voedingsspanning wordt voor alle cores op nul gezet.

3.1.2

Andere

Harde Schijf De server bevat een Western Digital Green schijf. Deze schijf maakt gebruik van de Intellipower technologie van Western Digital [18]. De Intellipower technologie is een technologie ontworpen om energiezuinig te zijn, maar toch een goede prestatie te leveren. Het is een weloverwogen compromis tussen verschillende caching algoritmes, transfersnelheden en rotatiesnelheden van de schijven. De fabrikant heeft op die manier voor elke grootte en elk type schijf een optimale rotatiesnelheid bepaald. Deze specifieke rotatiesnelheden per schijf zijn echter niet openbaar gemaakt. Maar voor een bepaald type schijf, bijvoorbeeld deze in onze server, is de rotatiesnelheid vast. De schijf gaat dus niet sneller of trager draaien in functie van de belasting. Intellipower is dus geen Dynamic Rotations Per Minute (DRPM) technologie zoals beschreven in [19], aangezien de rotatiesnelheid van de schijf nooit verandert (tenzij deze uitgeschakeld wordt natuurlijk). Naast Intellipower maakt de harde schijf ook gebruik van de Intelliseek technologie. De Intelliseek technologie berekent de optimale zoeksnelheid om het energieverbruik, het lawaai en de vibraties van de schijf te minimaliseren. [18] Geheugen In het testsysteem zitten DDR3 RAM geheugenchips. Bij stijgende types van de DDR standaard wordt telkens een lagere voedingsspanning gebruikt (DDR: 2,5V; DDR2: 1,8V; DDR3: 1,5V). Door die verlaging van de voedingsspanning verbruikt DDR3 tot 30% minder energie dan DDR2 [20]. De DDR4 standaard verlaagt de voedingsspanning tot 1,2V. De eerste commerciële producten zijn echter nog in volle ontwikkeling.

3.2

Vermogenmetingen

In deze masterproef werden veel vermogenmetingen gedaan. Alle metingen maakten gebruik van de Racktivity EnergySwitch 1008 PDU [21]. Dit is een toestel dat het vermogenverbruik van de server aan het stopcontact meet. Via een webinterface is


14

het dan mogelijk om het gemiddeld vermogenverbruik over de laatste seconde op te vragen. Dit gemiddeld vermogenverbruik over de laatste seconde is in werkelijkheid het gemiddelde van 25000 ogenblikkelijke metingen per seconde in het apparaat.

3.3

Vermogenverdeling over componenten

Om in te schatten welke component voor welk aandeel in het totale vermogenverbruik verantwoordelijk is, stelden we enkele eenvoudige testen op. Deze experimenten geven een ruw idee welke componenten van het systeem de grootste energieverslinders zijn. In de volgende subsecties worden deze testen en de daaruitvolgende vermogenverdeling besproken enerzijds voor een onbelast systeem en anderzijds voor een belast systeem.

3.3.1

Onbelaste vermogenverdeling

Een eerste reeks testen schat de vermogenverdeling in onbelaste toestand. Hiervoor werd gedurende een minuut elke seconde het vermogenverbruik voor een bepaalde configuratie gemeten. De uitgemiddelde resultaten staan in Figuur 3.1. Op het histogram staan ook 95% confidentie-intervallen aangegeven door middel van errorbars, deze zijn echter zo klein dat ze moeilijk zichtbaar zijn.

100 90 80

Fan losgekoppeld

Helft van geheugen

Bios met schijf

30

1 core

40

2 cores

50

3 cores

60

Bios zonder schijf

70

Standaard

Gemiddeld vermogenverbruik (W)

110

Figuur 3.1: Gemiddeld vermogenverbruik in onbelaste toestand voor verschillende configuraties

In de BIOS is het mogelijk om afzonderlijke cores uit te schakelen, dit heeft echter geen invloed op het vermogenverbruik in onbelaste toestand. Dit komt doordat een


15

onbelaste processor automatisch naar een C-state met laag energieverbruik overschakelt. Wanneer een core uitgeschakeld wordt in de BIOS vermoeden we dat de core in diezelfde C-state gezet wordt of dat het vermogenverbruik tussen beide toestanden zeer klein is. Wanneer de koeling (fan) losgekoppeld wordt, zakt het vermogenverbruik van 54,8W naar 36,8W. De fan gebruikt dus ongeveer 18W of 33% van het totale vermogenbudget. Dit is veel, maar dit komt doordat de fan ingesteld staat om voortdurend op zijn maximale toerental te draaien. Normaal is het toerental afhankelijk van de omgevingstemperatuur. Om de invloed van het veranderen van het toerental van de ventilator tijdens andere vermogenmetingen te kunnen afzonderen, staat hij ingesteld op het maximum. De helft van het RAM geheugen loskoppelen leidt tot een daling van 0,5W. Daaruit maken we een schatting dat het volledige geheugen verantwoordelijk is voor 1W of 2% in het totale vermogenverbruik van het onbelaste systeem. Om het aandeel van de harde schijf te schatten was het nodig om de server in het BIOS menu te zetten, aangezien de server niet kan opstarten zonder harde schijf. Doordat de processor in het BIOS menu op volle snelheid werkt, ligt het vermogenverbruik hier veel hoger. Vergelijken van de metingen wanneer de schijf aangekoppeld is in het BIOS menu en wanneer die losgekoppeld is, toont een verschil van 4,7W. Volgens de gegevens van de fabrikant is het vermogenverbruik tijdens lezen of schrijven 5,3W, in onbelaste toestand 3,3W en in slaapstand 0,7W. [18] Een taartdiagram van de geschatte vermogenverdeling in onbelaste toestand over de componenten staat in Figuur 3.2. In dit diagram zijn enkel resultaten opgenomen die volgen uit de testen. Daardoor bevat de categorie ’andere’ het aandeel van de processor, het moederbord en de voeding.

3.3.2

Belaste vermogenverdeling

De schatting van de vermogenverdeling in belaste toestand leidden we af uit de herhaalde uitvoering van een benchmark voor verschillende configuraties van de server. De gebruikte benchmark is Facesim uit de PARSEC v2.1 benchmark suite [22]. Facesim is een programma dat een model van een menselijk gezicht en een tijdsverloop van spieractivaties omzet naar een realistische visuele animatie van dat gezicht. De PARSEC suite is ontwikkeld om processoren met meerdere cores (multiprocessoren) te testen. Bij het starten van een bepaalde benchmark is het mogelijk om een minimum aantal draden op te geven. In Figuur 3.3 is het gemiddeld vermogenverbruik van het uitvoeren van de Facesim benchmark uitgezet. Bij de configuraties staat telkens tussen haakjes aangegeven met hoeveel draden de benchmark minimaal gestart is.


16

56,75%

Geheugen Fan Harde schijf Andere

1,82%

8,58% 32,85%

Figuur 3.2: Taartdiagram vermogenverdeling in onbelaste toestand

130

3 cores (6)

2 cores (4)

1 core (2)

TB disabled (8)

TB disabled (4)

HT disabled (8)

80

HT disabled (4)

90

Helft van geheugen (8)

100

Standaard (8)

110

Helft van geheugen (4)

120

Standaard (4)

Gemiddeld vermogenverbruik (W)

140

Figuur 3.3: Gemiddeld vermogenverbruik van Facesim benchmark voor verschillende configuraties

De standaarduitvoering met acht draden verbruikt 6W meer dan deze met acht draden. Het uitschakelen van hyperthreading zorgt voor een vermogenbesparing. Bij uitvoering met vier draden besparen we 4W of 3,4%, bij acht draden 12W of 9,6% ten opzichte van de standaardconfiguraties. Hyperthreading zorgt er voor dat er twee draden simultaan kunnen uitgevoerd worden op eenzelfde core. De processor kan zijn functionele eenheden beter benutten en verbruikt bijgevolg meer. We zien na het uitschakelen van de turboboost feature dat uitvoering met vier


17

draden 0,5% minder verbruikt en met acht draden 0,9% ten opzichte van de standaarduitvoering. Deze feature zorgt ervoor dat een bepaalde core of alle cores tijdelijk een hogere klokfrequentie aannemen (als de huidige temperatuur en het vermogenverbruik het toelaten). Op die manier kan de processor een bepaalde hoeveelheid werk sneller afwerken en dus sneller naar een laagverbruikende C-state overschakelen. Verder stellen we vast dat als we cores uitschakelen maar zorgen dat alle actieve cores hun maximaal aantal gelijktijdig uit te voeren draden uitvoeren, het vermogenverbruik afneemt met 10–15W per core. Hieruit volgt dat het dynamisch vermogenverbruik van alle cores samen 40–60W is. Naast de cores zelf zijn er natuurlijk ook nog andere componenten in de processor die ook energie verbruiken zoals de L3 cache. Het werkelijke vermogen voor de volledige processor zal dus nog hoger zijn. Ten slotte werd nog de helft van het geheugen verwijderd. De PARSEC benchmarks zijn vooral processorintensief en gebruiken weinig geheugen. De workingset van de Facesim benchmark past zeker nog in de helft van het geheugen. [22] De uitvoering bespaart 4–5W in vermogenverbruik. Hieruit kunnen we het verbruik van het volledige geheugen op 10W schatten. Het overzicht van de vermogenverdeling staat in Tabel 3.3. De categorie ’andere’ bevat het vermogenverbruik van de gemeenschappelijke delen van de processor, het moederbord en de voeding. Diezelfde resultaten zijn ook weergegeven in een taartdiagram in Figuur 3.4. Totaal 130W Geheugen: 10W Fan: 18W Harde schijf: 4,7W Processor (dynamisch): 40–60W Andere: 37,3–57,3W Tabel 3.3: Overzicht schatting vermogenverdeling bij uitvoeren van Facesim

3.3.3

Conclusie

In dit hoofdstuk zijn we er in geslaagd om het vermogenverbruik van de server op te splitsen in een aantal componenten. De grootste energieverslinders zijn de processor enerzijds en het moederbord in combinatie met de voeding anderzijds. Het geheugen, de koeling en de harde schijf zijn slechts kleinere aandeelhouders in het totale energieverbruik. Aangezien het vermogenverbruik van de processor het grootste dynamisch bereik heeft en softwarematig het gemakkelijkst te be¨ınvloeden is, is deze component uitermate geschikt om ons op te concentreren.


18 36,4%

7,7%

38,5%

Geheugen Fan Harde schijf Processor (dynamisch) Andere

13,8% 3,6%

Figuur 3.4: Taartdiagram vermogenverdeling in belaste toestand

Het energieverbruik van de processor kunnen we sturen met behulp van DVFS. In het volgende hoofdstuk gaan we na wat de impact van DVFS kan zijn op enerzijds het vermogenverbruik en anderzijds de prestatie. Daarnaast onderzoeken we ook in hoeverre dit afhankelijk is van de werklast aanwezig op het systeem. Hiervoor gebruiken we opnieuw de PARSEC benchmarks. Vervolgens gaan we op zoek naar de specifieke vorm van webapplicaties, om in het hoofdstuk daarna de invloed van DVFS op verschillende webapplicaties te testen.

19

Hoofdstuk 4 Invloed van de werklast 4.1

Inleiding

Naast het gebruiken van de PARSEC benchmarks om de invloed van verschillende serverconfiguraties te testen en zo de vermogenverdeling over de verschillende componenten van de server te schatten, kunnen deze benchmarks ook gebruikt worden om de invloed van DVFS op het energieverbruik en de prestatie te meten. Dit deden we voor alle benchmarks van de PARSEC suite. In de volgende secties bespreken we enkele metrieken voor drie van deze benchmarks.

4.2

Gekozen benchmarks

Uit de uitvoering van alle benchmarks kozen we drie interessante gevallen uit. Deze benchmarks verschillen in de besproken metrieken en zijn de duidelijkste voorbeelden uit de set die het punt illustreren dat we willen maken. De gekozen benchmarks zijn: Blackscholes, Facesim en Streamcluster. Facesim hebben we in het vorige hoofdstuk al besproken en gebruikt om de vermogenverdeling over de verschillende componenten te schatten. Blackscholes is een programma dat onderdeel uitmaakt van de PARSEC benchmark suite. Het is een programma dat gebruikt wordt in de financiële wereld. Meer bepaald berekent het de koersprijs van een set aandelenopties. Deze berekening bestaat uit het oplossen van een partiële differentiaal vergelijking, waarvoor geen oplossing in gesloten vorm beschikbaar is. De vergelijking moet bijgevolg numeriek opgelost worden. Streamcluster is een programma dat een stroom van inputpunten groepeert (clustert) in een vooraf bepaald aantal groepen. Het programma spendeert het merendeel van de uitvoeringstijd aan het onderzoeken van de mogelijke winst door het starten van een nieuwe groep. Dit soort programma’s wordt vooral gebruikt in omgevin-

HOOFDSTUK 4. INVLOED VAN DE WERKLAST

20

gen waar grote hoeveelheden, continu geproduceerde data in real-time georganiseerd moeten worden. Dit probleem treedt vooral op in netwerk intrusiedetectie, patroonherkenning en datamining algoritmes. Alle benchmarks werden uitgevoerd voor elke mogelijke instelbare klokfrequentie van de processor. Meer specifiek voerden we dit voor elke klokfrequentie zes keer uit. De eerste uitvoering gold als warm-up, dit resultaat werd niet gebruikt om mogelijke overgangsverschijnselen niet in rekening te brengen. De resultaten van de overige vijf uitvoeringen hebben we uitgemiddeld.

4.3

Vermogenverbruik

Genormaliseerd gemiddeld vermogenverbruik

In deze sectie bespreken we de resultaten voor het gemiddeld vermogenverbruik van de gekozen benchmarks tijdens de uitvoering aan verschillende klokfrequenties. Voor een processor wordt over het algemeen aangenomen dat zijn vermogenverbruik tussen kwadratisch en kubisch schaalt met zijn klokfrequentie [14]. Dit volgt uit de formule P ∝ V 2 f ∝ f 3 die voor CMOS technologie geldt, volgend uit de formule dat V ∝ f . Deze laatste formule is echter een vereenvoudiging, vandaar dat het vermogenverbruik in realiteit tussen kwadratisch en kubisch schaalt. 1,6 1,5

Blackscholes Facesim Streamcluster

1,4 1,3 1,2 1,1 1 0,9

1,6

1,8

2

2,2

2,4

2,6

2,8

3

3,2

Klokfrequentie (GHz)

Figuur 4.1: Gemiddeld vermogenverbruik voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie

De genormaliseerde resultaten van het vermogenverbruik voor de drie benchmarks staan in Figuur 4.1. Op de histogrammen staat tevens een 95% confidentie-interval aangegeven door middel van een errorbar. We stellen vast dat het vermogenverbruik iets sneller dan lineair toeneemt met stijgende klokfrequentie. We zien dus geen kubisch of kwadratisch verband op de grafiek. De verklaring zit hem in het onderscheid


21

tussen het statisch en het dynamisch vermogenverbruik van de server. In de grafiek staat het totale vermogenverbruik van de server weergegeven, niet enkel dat van de processor. Uit het vorige hoofdstuk weten we dat dit slechts 38% van het totaal is. Verder is het zo dat tijdens de onbelaste processorcycli de andere componenten van de server wel nog energie verbruiken. Dit energieverbruik telt door de uitmiddeling ook mee, waardoor het subkubische verband afgezwakt wordt. Verder hangt het verbruik van de processor ook af van zijn activiteit. Als er meer functionele eenheden actief zijn, zal de processor meer verbruiken dan wanneer deze eenheden onbelast zijn. Dit verklaart verschillen in het schalingsgedrag van het vermogenverbruik tussen de benchmarks.

4.4

Uitvoeringstijd

De resultaten voor de uitvoeringstijd van de benchmarks bij verschillende klokfrequenties staan in Figuur 4.2. De uitvoeringstijden zijn hier opnieuw genormaliseerd en de errorbars stellen een 95% confidentie-interval voor. De zwarte curve geeft de ideale schalingslijn aan waarbij de uitvoeringstijd procentueel evenveel afneemt als de klokfrequentie toeneemt. Op de grafiek is te zien dat de drie benchmarks een ander schalingsgedrag vertonen in de uitvoeringstijd voor verschillende klokfrequenties. Blackscholes heeft de grootste speedup bij stijgende klokfrequenties. Sterker nog, Blackscholes blijkt perfect omgekeerd evenredig te schalen met de klokfrequentie. Wanneer de klokfrequentie verdubbelt, halveert de uitvoeringstijd. Voor Facesim neemt de uitvoeringstijd 42% af en voor Streamcluster slechts 30%.

Genormaliseerde uitvoeringstijd

1,1


1 0,9 0,8 0,7 0,6 0,5 0,4

1,6

1,8

2

2,2

2,4

2,6

2,8

3

3,2


Figuur 4.2: Uitvoeringstijd voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie


22

De PARSEC benchmarks zijn ontwikkeld om processoren te testen, alle benchmarks zijn dan ook vooral processorintensief. De benchmarks zijn echter overgenomen van reële programma’s waardoor deze allemaal een verschillend geheugengedrag vertonen. Blackscholes heeft een workingset van 2MB, deze past dus volledig in de L3 cache. Facesim daarentegen heeft een workingset die niet in de caches past [22]. Hierdoor treden bij Facesim meer cache misses op en wordt dus meer gewacht op het hoofdgeheugen. Een schaling van de klokfrequentie van de processor be¨ınvloedt de absolute geheugenlatentie niet, waardoor de uitvoeringstijd van Facesim een vast aandeel wachttijd op het geheugen bevat. Dit is de verklaring voor het feit dat de speedup van Facesim kleiner is dan die van Blackscholes bij het omhoog schalen van de klokfrequentie van de processor. Streamcluster heeft een nog hogere miss rate dan Blackscholes en Facesim [22]. Daardoor is het schalingsgedrag van Streamcluster nog slechter en heeft deze benchmark de slechtste speedup van de drie besproken benchmarks. Deze hogere miss rate is ook verantwoordelijk voor het lagere verbruik van Streamcluster bij de hogere klokfrequenties. De processor moet meer wachten op de caches en het hoofdgeheugen waardoor de functionele eenheden inactief worden en minder verbruiken ten opzichte van de uitvoering van de andere benchmarks.

4.5

Energieconsumptie

De vermenigvuldiging van het gemiddeld vermogengebruik met de uitvoeringstijd van de benchmark drukt het totale energieverbruik van die benchmark uit. De resultaten van deze berekening voor de drie benchmarks staan in Figuur 4.3. We zien dat de drie benchmarks een minimum in het energieverbruik vertonen bij een verschillende klokfrequentie. Voor Blackscholes zien we dat de hoogste klokfrequentie het efficiëntst is in termen van energieverbruik. Dit is logisch gezien de grote speedup van Blackscholes. Met het kwadratisch verband tussen de klokfrequentie en het vermogenverbruik en een lineair verband tussen de klokfrequentie en de uitvoeringstijd in het achterhoofd, zou je verwachten dat de laagste klokfrequentie de meest energie-efficiënte zou zijn. Aangezien het vermogenverbruik dus sneller zou toenemen dan de uitvoeringstijd zou afnemen en het energieverbruik als product van deze twee berekend wordt. Dit is echter niet het geval, zoals we in de vorige sectie al aanhaalden is dit de invloed van het statisch vermogenverbruik. Aangezien dit statisch vermogenverbruik onvermijdelijk is, kunnen we beter de uitvoeringstijd zo kort mogelijk houden. Voor Facesim zijn er echter cache misses, waardoor de processor bij een hoge klokfrequentie in een hoogverbruikende toestand geen werk zal leveren. Dan is het


Genormaliseerd totaal energieverbruik

1,05

23


1 0,95 0,9 0,85 0,8 0,75 0,7

1,6

1,8

2

2,2

2,4

2,6

2,8

3

3,2


Figuur 4.3: Totaal energieverbruik voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie

voordeliger om de instructies trager uit te voeren en zo de relatieve latentie naar het hoofdgeheugen in klokcycli te verlagen. Zo worden geen klokcycli verspild waar de processor geen werk levert maar wel veel energie verbruikt. We zien dan ook dat Facesim een minimum vertoont in het energieverbruik bij 2,6GHz. Streamcluster heeft een nog hoger percentage cache misses, waardoor de energie-efficiëntste klokfrequentie nog lager is, namelijk bij 2,4GHz.

4.6

Conclusies

Uit de resultaten in dit hoofdstuk concluderen we dat de meest energie-efficiënte klokfrequentie afhankelijk is van de specifieke werklast die op de server draait. Voor deze testen hebben we de PARSEC benchmarks gebruikt. Dit zijn relatief lange jobs waar de requests voor een webserver zeer kort van aard zijn. Ook de uitvoeringstijd voor requests op een webserver (of voor elke andere interactieve applicatie) is zeer belangrijk. Als de uitvoeringstijd namelijk te lang is, be¨ınvloedt dit de gebruikerservaring op een negatieve manier. Aangezien de uitvoeringstijd toeneemt met dalende klokfrequentie, moeten we dus ook rekening houden met de uitvoeringstijd bij het kiezen van de klokfrequentie. Verder is het ook zo dat hoe zwaarder de processor van een webserver belast is, hoe langer de responstijd voor een request zal zijn. We kunnen dus ook niet zomaar de processor tot zijn maximum belasten. In het volgende hoofdstuk leggen we de verschillen tussen enerzijds normale applicaties en benchmarks en anderzijds webapplicaties bloot. Uit die verschillen bouwen we dan een benchmarkgenerator op die benchmarks kan genereren die het volledige


24

spectrum aan webapplicaties bestrijkt. Met deze benchmarks kunnen we vervolgens analyses uitvoeren omtrent het energieverbruik en de prestatie van webservers en hoe we deze kunnen be¨ınvloeden met DVFS.

25

Hoofdstuk 5 Synthetische webbenchmarks In het vorige hoofdstuk kwamen we tot de conclusie dat de meest energie-efficiënte klokfrequentie afhankelijk is van de werklast. Om dat aan te tonen gebruikten we de PARSEC benchmarks. In dit hoofdstuk kijken we hoe de PARSEC benchmarks zich verhouden tot de echte focus van deze masterproef namelijk webapplicaties. In de eerste sectie bekijken we de specifieke eigenschappen van webapplicaties. In de volgende sectie behandelen we de scripttaal PHP die veel gebruikt wordt om webapplicaties te ontwikkelen. Daarna vergelijken we verschillende soorten benchmarks. Met een raamwerk voor onze eigen benchmarksuite voor webapplicaties sluiten we ten slotte dit hoofdstuk af.

5.1

Webapplicaties

Webapplicaties zijn applicaties die niet lokaal op een computer ge¨ınstalleerd worden maar op een webserver. De gebruikers kunnen de applicatie gewoon openen in hun browser, waardoor ze geen applicatiespecifieke software moeten installeren op hun computer. Aan deze manier van werken zijn een aantal voordelen verbonden. Alle applicatielogica draait op de server(s). Als er dus een nieuwe versie uitgebracht is, hoeft enkel de software op de server een update te krijgen. Alle gebruikers schakelen op die manier gelijktijdig over op de nieuwe versie. Voor traditionele applicaties moeten de gebruikers op de hoogte worden gebracht van de beschikbaarheid van een update, deze dienen ze dan vervolgens nog zelf te installeren. Verder is het ontwikkelen van een webapplicatie ook stukken eenvoudiger. Waar de programmeur anders rekening moet houden met uiteenlopende besturingssystemen en hardware van de gebruikers, hoeft hij hier enkel rekening te houden met de verschillen in mogelijkheden tussen browsers. Deze zijn echter veel kleiner dan de verschillen tussen besturingssystemen.

HOOFDSTUK 5. SYNTHETISCHE WEBBENCHMARKS

26

Ook voor de gebruiker zijn er voordelen. Vermits de applicatie in een browser draait, is deze afgeschermd van de rest van de computer. Dit is het zogenaamde zandbaksysteem. De applicatie heeft slechts beperkte rechten en kan bij een eventuele crash de rest van het systeem niet in gevaar brengen. Bij een traditionele applicatie moeten de gebruikers de makers en de manier waarop ze de software verkregen vertrouwen, aangezien het installatiebestand ook malware zou kunnen bevatten. Uiteraard zijn er ook nadelen aan webapplicaties verbonden. Zo kan de gebruiker de applicatie enkel gebruiken als hij netwerktoegang heeft. De applicatie is dus niet toegankelijk als het netwerk of de server falen. Dit introduceert een single point of failure in het geval de applicatie slechts op een server draait en geen back-up voorzien is. Als een van deze componenten faalt, valt de toegang tot de applicatie weg. In een bedrijfscontext kan dit betekenen dat de werknemers niet meer kunnen werken, voor een webshop kunnen potentiële klanten geen aankopen meer doen. Redundantie in datacenters lossen dit probleem gedeeltelijk op, het eigen toegangsnetwerk blijft echter een mogelijke bron van falen. Daarnaast werkt een webapplicatie volgens het client-server principe. De client stuurt webrequests naar de server. Op de server gebeurt vervolgens een verwerking. Waarop deze een respons, de opgevraagde pagina door de gebruiker, terugstuurt naar de client. Om de gebruiker tevreden te houden, mag deze respons niet te lang op zich laten wachten. Volgens de literatuur [23] is de maximale laadtijd voor een pagina om de gebruikerservaring goed te houden twee seconden. De absolute maximum toelaatbare laadtijd (dan verlaat de gebruiker de pagina nog voor ze geladen is) voor een webpagina is vijftien seconden. Voor een webapplicatie is het dus belangrijk de laadtijd onder een maximum te houden, dit maximum is meestal vastgelegd in de SLA met de kant. De totale laadtijd wordt bepaald door een aantal termen. Enerzijds is er de netwerkdelay, dit is de reistijd van de aanvraag van de client naar de server en het antwoord van de server terug naar de client. Anderzijds is er de tijd die de server nodig heeft om de aanvraag te behandelen. Het behandelen van de aanvraag bevat dan weer een mogelijke wachttijd in de queue tot de server de aanvraag kan behandelen, opvragingen naar (externe) databases, verwerking van meegestuurde data, berekeningen ... Bij het schalen van de klokfrequentie van de server, zullen we de responstijd van de pagina’s ook be¨ınvloeden. Hierbij is het dus essentieel dat we er op letten onder de maximum delay voorgeschreven in de SLA te blijven. Een webapplicatie bestaat uit verschillende pagina’s en elke pagina heeft standaard al een andere laadtijd. Deze is afhankelijk van de hoeveelheid verwerking die nodig is op de server en de grootte van het datapakket dat naar de gebruiker gestuurd moet worden. De standaard laadtijd van de pagina zal dus bepalen in welke mate we de verwerking voor deze pagina sneller of trager kunnen doen verlopen. Daarnaast zal de specifieke opbouw van de


27

pagina ook bepalen hoeveel de klokfrequentie de laadtijd zal be¨ınvloeden.

5.2

PHP

PHP staat voor Hypertext PreProcessor. Het is een scripttaal ontwikkeld om op een webserver dynamische pagina’s te genereren, derhalve is ze veel gebruikt om webapplicaties te programmeren. De PHP-code kan ingebed worden in een HTML pagina door middel van de tags. De server verwerkt deze stukken code bij het opvragen van de pagina waarna het eindresultaat van deze verwerking naar de gebruiker wordt gestuurd. Dit eindresultaat bevat enkel nog HTML-code1 . Het gebruik van PHP maakt het op die manier mogelijk om de pagina die de gebruiker uiteindelijk te zien krijgt, aan te passen met behulp van gegevens die enkel op de server beschikbaar zijn. Alternatieven voor PHP zijn bijvoorbeeld: ASP (Microsoft), JSP en ColdFusion (Adobe). [24, 25] De verwerking van een PHP pagina gebeurt in twee stappen. In een eerste stap krijgt de webserver de request voor een bepaalde pagina met een .php-extensie2 . Deze pagina wordt doorgegeven aan de PHP-parser. De parser zal het bestand analyseren en de PHP-code binnen de PHP-tags compileren tot bytecode. In een tweede stap voert de virtuele machine van PHP, deze wordt ook wel de Zend Engine genoemd, de gegenereerde bytecode uit. De output van deze uitvoering is de uiteindelijke pagina die naar de gebruiker gestuurd wordt en vervolgens weergegeven wordt in zijn browser. Telkens een request voor een PHP-pagina binnenkomt, worden deze twee stappen opnieuw doorlopen. Aangezien het genereren van de bytecode voor elke request opnieuw gebeurt, voert de PHP-parser geen optimalisaties uit. Dit zou zorgen voor extra complexiteit en uitvoeringstijd voor de PHP-parser, deze gaat er dus van uit dat de programmeur de PHP-code efficiënt geschreven heeft. Ongebruikte variabelen of functies worden ook geparsed en zijn bijgevolg te vermijden.

5.3

Benchmarks

Computerbenchmarks zijn computerprogramma’s die gebruikt worden om systemen te testen. Aangezien de programma’s op elk systeem hetzelfde zijn, zijn ze uitermate geschikt om aan de hand van de resultaten de prestaties van verschillende systemen te vergelijken. Op die manier kan men dan zien wat de voordelen en nadelen van 1

Dit is de meest voorkomende situatie. In principe kan PHP ook andere formaten genereren zoals: XML, afbeeldingen, JavaScript ... 2 De server kan ook ingesteld worden om andere extensies te laten verwerken door de php software.


28

een bepaald systeem zijn en op basis daarvan beslissingen nemen. Met benchmarks kunnen we niet alleen hardwarecomponenten vergelijken maar ook software testen. Er bestaan een aantal soorten benchmarks die elk geschikt zijn voor verschillende doeleinden. We delen ze op in twee groepen: real world benchmarks en synthetische benchmarks. Real world benchmarks zijn echte programma’s die bijvoorbeeld gebruikt worden voor video rendering, audio encodering. Door deze programma’s te starten met vaste inputset, is de uitvoering vergelijkbaar op verschillende systemen. Op die manier krijgen deze programma’s een tweede functie als benchmark. Synthetische benchmarks zijn programma’s die uitsluitend ontwikkeld zijn om systemen te testen. Veelal proberen ze het gedrag van echte programma’s te weerspiegelen. De programma’s produceren echter geen nuttige output en bestaan enkel voor het benchmarken van systemen. Synthetische benchmarks worden dikwijls gegenereerd door een synthetische benchmarkgenerator, anderen daarentegen zijn handmatig geprogrammeerd [26]. Deze neemt een aantal parameters waaraan de geproduceerde set benchmarks moet voldoen. Een volledige set aan reële programma’s nabootsen behoort op die manier tot de mogelijkheden. Voorbeelden van real world benchmarksuites zijn: de verschillende SPEC-suites en de PARSEC-suite gebruikt in de vorige hoofdstukken. Voorbeelden van synthetische benchmarks zijn: Whetstone en Dhrystone. Het voordeel van real world benchmarks is dat ze een reële werklast voorstellen, het nadeel is dan weer dat deze werklast veelal domeinspecifiek is. De resultaten bekomen met deze benchmark zijn dus enkel representatief voor werklasten van dit type. Daarom komen real world benchmarks ook in suites, deze bevatten programma’s uit verschillende domeinen. Het voordeel van synthetische benchmarks is dan weer dat ze kunnen aangepast worden om specifieke componenten of klassen operaties te testen. Daarnaast laten ze, indien gegenereerd door een generator, toe een heel spectrum aan soorten programma’s testen. Dat maakt dat synthetische benchmarks uitermate geschikt zijn voor deze masterproef. We willen in deze masterproef het hele spectrum aan mogelijke webapplicaties bekijken. We hebben dus een benchmarkgenerator nodig die het mogelijk maakt alle mogelijke soorten webpagina’s te genereren. Deze gegenereerde pagina’s kunnen we vervolgens gebruiken om het effect van DVFS op deze verschillende soorten webapplicaties te testen. Helaas bestaat er geen synthetische webbenchmarkgenerator die aan onze eisen voldoet. We hebben dan ook zelf onze eigen generator geprogrammeerd. Onze eigen generator genereert PHP-pagina’s. De volgende sectie legt uit hoe deze is opgebouwd.


5.4

29

Synthetische webbenchmarks

In deze sectie bouwen we onze eigen synthetische benchmarkgenerator voor webapplicaties. Deze is ge¨ınspireerd op eerder werk die een benchmarkgenerator bouwde voor synthetische C benchmarks.

5.4.1

Synthetische C benchmarkgenerator

Een synthetische benchmarkgenerator werkt in drie fases, weergegeven in Figuur 5.1. In de eerste fase maakt de gebruiker een configuratiebestand aan. In dit configuratiebestand geeft hij aan hoe hij wil dat de set te genereren benchmarks er uit zal zien. Dit configuratiebestand geeft hij dan als parameter mee aan de benchmarkgenerator. Deze genereert vervolgens een aantal benchmarks overeenkomstig de parameters in het configuratiebestand. In de laatste fase produceert de generator de output, namelijk de gewenste set benchmarks om testen mee uit te voeren.

Configuratie

Benchmarkgenerator

Output

Figuur 5.1: Drie fasen van een synthetische benchmarkgenerator

De synthetische C benchmarkgenerator, SWEEP, voorgesteld in [27] gebruikt ook deze structuur. De SWEEP benchmarks uit het artikel bestaan uit een aantal aaneengeschakelde bouwblokken. Elk bouwblok stelt hierbij een ander gedrag en een verschillende werklast van het programma voor. Deze bouwblokken worden in de gewenste samenstelling en hoeveelheden gecombineerd om de uiteindelijke benchmark te bekomen. De SWEEP bouwblokken zijn: processorintensieve bouwblokken, geheugenintensieve bouwblokken, I/O-intensieve bouwblokken en blokken om threading te introduceren. Elk van deze blokken heeft zelf een aantal instelbare parameters. Zo kun je voor een processorintensief bouwblok bijvoorbeeld het aantal instructies kiezen, het type instructies, de inter-instruction dependency distance (IIDD)... Deze parameters bepalen mee welk gedrag de volledige benchmark zal vertonen. De IIDD is bijvoorbeeld het aantal instructies tussen twee van elkaar afhankelijke instructies. De IIDD bepaalt dus de hoeveelheid instruction-level parallelism (ILP) in het programma. Deze hoeveelheid is een maat voor het aantal instructies dat de processor potentieel gelijktijdig kan uitvoeren. Voor het type instructies kunnen we dan weer kiezen tussen


30

bewerkingen op gehele getallen of decimale getallen en ook de bewerking zelf kan gekozen worden. Zo weten we dat optellingen bijvoorbeeld minder processorcycli vergen dan een vermenigvuldiging.

5.4.2

Synthetische webbenchmarkgenerator

Voor onze webbenchmarkgenerator hebben we de C benchmarkgenerator SWEEP als basis genomen. Onze generator gebruikt dus ook diezelfde driefasige structuur. We nemen ook het concept met de bouwblokken over. We kunnen echter niet zomaar alles overnemen. Een blok voor threading is bijvoorbeeld niet relevant voor webapplicaties. Een PHP webpagina zal in zijn verwerking aan de serverkant geen bijkomende threads starten. PHP 5 bevat ook standaard geen primitieven voor multithreading. Daarnaast versturen webpagina’s dikwijls aanvragen naar een externe database of applicatieserver. Op dat moment blokkeert de uitvoering van het PHP-script en wacht deze tot de externe bron een antwoord terugstuurt. Daarna kan de uitvoering van het script voortgezet worden. Om dit gedrag te modelleren introduceren we in de webbenchmarkgenerator een bouwblok voor externe aanvragen. Verder heeft ook de hoeveelheid output die terug naar de client gestuurd moet worden een aanzienlijke invloed op de prestatie van een webapplicatie. Deze output moet immers over het netwerk verstuurd worden en introduceert daardoor een extra delay in de responstijd. Hoe meer output er is, hoe langer dit versturen duurt. We ontwerpen alle blokken zodat ze geen output genereren, maar introduceren een extra bouwblok dat daarvoor verantwoordelijk is. Zo hebben we exacte controle over de hoeveelheid output van het PHP-script. De processorintensieve, geheugenintensieve en I/O-intensieve blokken kunnen we in webapplicaties wel gebruiken. Tabel 5.1 zet de bouwblokken van C en PHP benchmarks nog eens netjes in een overzicht. In de volgende subsecties gaan we dieper in op de parameters en de opbouw van elk bouwblok. Parameters die relevant kunnen zijn voor C benchmarks hoeven het daarom niet te zijn voor PHP webbenchmarks en omgekeerd. Met behulp van een aantal microbenchmarks testen we welke parameters relevant zijn voor onze PHP bouwblokken. Een microbenchmark is een eenvoudige benchmark speciaal ontworpen om een klein specifiek stukje code, parameter of component te testen.

5.4.3

Processorintensieve bouwblokken

Invloed van de bewerking Voor de processorintensieve bouwblokken van de C benchmarks zijn een aantal parameters instelbaar. Zo is bijvoorbeeld het soort bewerking een parameter. In C


31

Bouwblokken C benchmarks Bouwblokken PHP benchmarks Processorintensief Processorintensief Geheugenintensief Geheugenintensief I/O-intensief I/O-intensief Threading Outputintensief Externe aanvragen Tabel 5.1: Vergelijking bouwblokken C en PHP benchmarks

vertaalt de compiler een optelling en een vermenigvuldiging rechtstreeks naar de corresponderende instructie in assembler. We weten ook dat een vermenigvuldiging in de processor meer cycli nodig heeft om uit te voeren dan een optelling. Via microbenchmarks in PHP en C zien we dat de keuze van de bewerking in PHP helemaal niet zoveel invloed heeft als in C. De gebruikte microbenchmarks bestaan uit 800 identieke operaties in PHP en C, de syntax is voor de beide talen identiek voor de gekozen bewerkingen. De 800 bewerkingen zijn allemaal afhankelijk van elkaar. Het is dus onmogelijk om meerdere instructies per cyclus uit te voeren. Van deze microbenchmarks werd voor 100 uitvoeringen de uitvoeringstijd gemeten en uitgemiddeld. In C werd de uitvoeringstijd gemeten via de gettimeofday()-functie [28]. In PHP maten we enkel de uitvoeringstijd van de bytecode, het parsen van de broncode is dus niet inbegrepen in de uitvoeringstijd. Deze meting is in PHP mogelijk door de microtime()-functie [29]. De microbenchmark in C werd gecompileerd met cc v4.5 en de vlag -O0 zodat de compiler geen optimalisaties uitvoert. De resultaten na uitvoering van deze microbenchmarks staan in Figuur 5.2. Op de histogrammen staan ook 95% confidentie-intervallen aangegeven. Waar we zien dat de deling in C 400% trager is dan de optelling, is dit in PHP slechts 12%. Voor de vermenigvuldiging is er zelfs geen verschil. De overhead van de PHP virtuele machine is zo groot dat de invloed van de verschillende uitvoeringstijden van de eigenlijke machine-instructies nog nauwelijks zichtbaar is. Voor de webbenchmarkgenerator is het dus niet nuttig om de bewerking instelbaar te maken, aangezien deze toch een zeer geringe invloed heeft. Invloed van de IIDD Een andere parameter voor een processorintensief blok in de C benchmarkgenerator is de IIDD. De overhead van de PHP virtuele machine blijkt echter opnieuw te groot om verschillen in de IIDD weerspiegeld te zien in de uitvoeringstijd. In realiteit wordt elke instructie in een PHP-script door de processor sequentieel uitgevoerd. Om tot deze


Uitvoeringstijd 800 instructies (µs)

20 18

32

PHP C

16 14 12 10 8 6 4 2 0

+=

-=

*=

/=

%=

Figuur 5.2: Invloed van de bewerking in PHP vs C

vaststelling te komen, deden we wederom experimenten met enkele microbenchmarks. De microbenchmarks in de vorige test hadden een IIDD gelijk aan één. We hebben diezelfde microbenchmarks ook gemaakt met IIDD gelijk aan vijf en tien. De resultaten van de microbenchmarks met een optelling als bewerking staan in Figuur 5.3, de resultaten voor de andere bewerkingen waren analoog. We zien dat voor PHP de uitvoeringstijd stabiel blijft bij een stijgende IIDD. Bij C is de uitvoering met IIDD gelijk aan tien echter 523% sneller dan een IIDD van één. We kunnen hier opnieuw besluiten dat het geen zin heeft om de IIDD te variëren in de PHP benchmarks.

Uitvoeringstijd 800 instructies (µs)

16 14

IIDD = 1 IIDD = 5 IIDD=10

12 10 8 6 4 2 0

C

PHP

Figuur 5.3: Invloed van de IIDD in PHP vs C


33

Invloed van het aantal regels code In de vorige microbenchmarks maten we telkens enkel de uitvoeringstijd van de bytecode. Als we de uitvoeringstijd voor de volledige pagina meten, dus ook het genereren van de bytecode, blijkt dat de uitvoering van de bytecode slechts 2,4% van de totale uitvoeringstijd behelst. De microbenchmark bevat dan ook veel regels code t.o.v. de complexiteit van de regels code. Eigenlijk hebben we nu steeds een microbenchmark gebruikt met een volledig uitgerolde lus met 800 bewerkingen. We hebben dezelfde test ook gedaan met de originele lusimplementatie. Codefragmenten voor de beide implementaties staan in Figuur 5.4. (a) Ontrolde lusimplementatie

(b) Lusimplementatie

Figuur 5.4: Structuur microbenchmarks

Het resultaat van deze testen staat in Figuur 5.5. De uitvoering van de bytecode met de lusimplementatie is drie keer zo traag als de ontvouwde lus, dit komt door de overhead van de lusiterator en de controleconditie. PHP incrementeert de lusiterator en controleert of de controleconditie nog voldaan is na elke lusuitvoering. Wat we winnen door de lus te ontvouwen verliezen we echter in het parsen van de code. Ondanks de tragere uitvoering van de bytecode, is de volledige uitvoering met de lusimplementatie 3,2 keer zo snel als de ontvouwde lusimplementatie. We kunnen dus besluiten dat het in PHP van belang is om de code compact te houden, aangezien het aantal regels code een grote impact heeft op de parsetijd. In PHP bestaat de mogelijkheid de Alternative PHP Cache (APC) te installeren [30]. Deze extensie cachet de bytecode voor een beperkt aantal pagina’s. Wanneer een gecachete pagina dan nog eens opgevraagd wordt hoeft de webserver deze niet opnieuw te parsen, maar kan de bytecode rechtstreeks uit de cache gehaald en uitgevoerd worden. We hebben de uitvoering van de twee soorten implementaties ook getest met bytecode caching ingeschakeld. Het resultaat daarvan staat ook in Figuur 5.5. Hier is de uitvoeringstijd van de eerste opvraging niet in rekening gebracht in het gemiddelde, aangezien de pagina op dat moment nog niet in de cache zat. Zoals we konden verwachten is bij het gebruik van bytecode caching de ontvouwde

HOOFDSTUK 5. SYNTHETISCHE WEBBENCHMARKS 600

34

Lusimpl. Ontrolde lusimpl.

200

100

0

Met bytecode caching

300

Generatie en uitvoering bytecode

400

Uitvoering bytecode

Uitvoeringstijd (µs)

500

Figuur 5.5: Invloed van de codelengte in PHP

lusimplementatie opnieuw sneller. Dit keer wel geen factor drie maar slechts 20%. Het zoeken in de cache en het ophalen van de bytecode introduceert dus ook wat overhead. Hoewel het grootste deel van de overhead waarschijnlijk voortkomt uit de Apache-webserver zelf. Besluit Uit deze testen concluderen we dat twee parameters volstaan om processorintensieve bouwblokken te karakteriseren. We implementeren de blokken door een aantal instructies te omringen met een lus. De twee parameters zijn dan enerzijds het aantal instructies in de lus en anderzijds het aantal lusiteraties. Hiermee zijn we in staat de tijd voor de generatie en uitvoering van de bytecode te balanceren. Meer instructies in de lus zorgen vooral voor een langere parsetijd, naast het toenemen van de uitvoeringstijd van de bytecode. Terwijl het verhogen van het aantal lusiteraties enkel de uitvoeringstijd van de bytecode verlengt.

5.4.4

Geheugenintensieve bouwblokken

Een geheugenintensief bouwblok bestaat uit een reeks geheugenoperaties op een geheugenstructuur. De parameters voor een geheugenblok in de C benchmarkgenerator zijn: de geheugenstructuur, de grootte van de geheugenstructuur, het toegangspatroon en de keuze voor lees- of schrijfoperaties. Voor de geheugenstructuur bestaat de keuze bijvoorbeeld uit een array, een gelinkte lijst of een binaire boom. De grootte van de geheugenstructuur bepaalt dan hoeveel elementen deze structuur zal bevatten. De grootte van de structuur zal ook bepalen in welke caches ze past en welke niveaus


35

van de geheugenhiërarchie aangesproken worden. Voor een array kan het toegangspatroon bijvoorbeeld willekeurig zijn of sequentieel. Een sequentieel patroon kan optimaal gebruik maken van de caches, terwijl bij een willekeurig toegangspatroon vooral de toegangstijd naar het geheugen cruciaal is. De laatste parameter laat toe te kiezen voor lees- of schrijfoperaties op de geheugenstructuur. Voor de webbenchmarkgenerator hebben we enkel de array als geheugenstructuur ge¨ımplementeerd. Het systeem is eenvoudig uitbreidbaar met andere geheugenstructuren. Via enkele microbenchmarks hebben we opnieuw getest welke parameters een invloed hebben voor de PHP-benchmarks. De microbenchmarks vullen eerst de array op met willekeurige getallen, gevolgd door de uitvoering van 200 geheugenoperaties. Enkel de uitvoeringstijd van de bytecode van deze geheugenoperaties wordt gemeten. In een eerste set microbenchmarks vergeleken we lees- en schrijfoperaties met een willekeurig toegangspatroon. De resultaten van deze test zijn uitgezet in Figuur 5.6. We zien dat leesoperaties telkens sneller zijn. Voor een kleine geheugenstructuur is dit 8% en dit neemt af voor groter wordende geheugenstructuren. De gemiddelde uitvoeringstijd voor de leesoperaties daalt dan ook zodat de uitvoering 3% sneller is dan deze van de schrijfoperaties. 70 65

Leesoperaties Schrijfoperaties


60 55 50 45 40 35 30 25 20 102

103

104

105

Aantal elementen in de array

Figuur 5.6: Uitvoeringstijd van lees- en schrijfoperaties in het geheugen

Arrays zijn in PHP ge¨ımplementeerd als een hashtable. De elementen van een array worden opgeslagen als paren met een key en value. Hierdoor neemt een element veel meer geheugen in dan het geval zou zijn in bijvoorbeeld C. We hebben onderzocht hoeveel geheugen een bepaald aantal elementen in de array inneemt. Dit is mogelijk door de memory get usage()-functie in PHP [31]. Voor het systeem beschreven in Hoofdstuk 3 konden we dan afleiden welke groottes nog in de caches pasten. De resultaten daarvan staan in Tabel 5.2.

HOOFDSTUK 5. SYNTHETISCHE WEBBENCHMARKS Aantal elementen Geheugengebruik 100 10KB 1000 102KB 10000 1MB 100000 10MB

36

Cachegedrag Past in de L1 cache Past in de L2 cache maar niet in de L1 Past in de L3 cache maar niet in de L2 Past in geen enkele cache

Tabel 5.2: Geheugengebruik van PHP arrays

Een tweede set microbenchmarks test de invloed van het toegangspatroon op de uitvoeringstijd. Dit deden we voor verschillende groottes van de arrays, overeenkomstig de conclusies met betrekking tot de caches. De resultaten hiervan staan in Figuur 5.7. We zien dat een array die nog in de L1 cache past 12% sneller is voor sequentiële toegangen en 15% voor willekeurige toegangen dan een array die nog net in de L3 cache past. Vanaf het moment dat de array echter niet meer in de caches past is deze 42% trager voor sequentiële toegangen en zelfs 279% voor willekeurige toegangen. Laten we de array nog een grootteorde toenemen, dan stijgt de uitvoeringstijd nog verder. Voor willekeurige toegangen neemt de uitvoeringstijd zelfs zoveel toe dat ze de maximaal toegelaten uitvoeringstijd voor een PHP-script overschrijdt. 70 65

Sequentieel Willekeurig


60 55 50 45 40 35 30 25 20 102

103

104

105

106

Aantal elementen in de array

Figuur 5.7: Invloed van het toegangspatroon op uitvoeringstijd van geheugenoperaties

We kunnen concluderen dat de latentie naar de caches verborgen blijft achter de overhead van de virtuele machine. Vanaf het moment dat er toegang tot het hoofdgeheugen vereist is, is de latentie echter te groot om nog verborgen te blijven, de uitvoeringstijd neemt dan zeer snel toe. Dit is vooral het geval bij willekeurige toegangspatronen, aangezien daar potentieel voor elke toegang het hoofdgeheugen aan-


37

gesproken moet worden. Voor sequentiële patronen is toegang tot het hoofdgeheugen nodig bij een cache miss, daarna kan het cachegeheugen opnieuw enkele toegangen bedienen. Het hoofdgeheugen beschikt ook over een prefetcher, waar sequentiële toegangspatronen ten volle de vruchten van plukken. Deze prefetcher probeert het toegangspatroon te achterhalen en op die manier de expliciete aanvragen voor te zijn. Hierdoor middelt de latentie naar het hoofdgeheugen uit over meerdere toegangen. De uitvoeringstijd neemt dan ook veel minder snel toe dan bij willekeurige toegangspatronen. Besluit In onze benchmarkgenerator is enkel de arraystructuur ge¨ımplementeerd, uitbreiding voor andere geheugenstructuren is echter mogelijk. De grootte van de structuur, het toegangspatroon en de keuze lees- of schrijfoperaties zijn instelbaar als parameter. Verder blijkt er voor PHP geen noemenswaardig verschil te bestaan tussen lees- of schrijfoperaties. Ook de grootte van de geheugenstructuur heeft geen aanzienlijke invloed, tenzij de geheugenstructuur niet meer in de caches past. De interessantste testen voor deze masterproef bestaan er dus in het toegangspatroon te variëren alsook de grootte van de array op zo’n manier te veranderen dat de ene array nog in de cache past en de andere niet meer.

5.4.5

I/O-intensieve bouwblokken

Een I/O-intensief blok doet lees- of schrijfoperaties naar de harde schijf van het systeem. In PHP kunnen we hiervoor de bestandssysteemfuncties [32] gebruiken. Om niet zelf een set bestanden aan te moeten maken en vervolgens beperkt te zijn tot die set, gebruiken we de volledige schijf als bestand 3 . Deze kunnen we openen met de fopen()-functie. Door de schijf op deze manier te openen en aangezien we in ons testsysteem slechts één harde schijf hebben (zie Hoofdstuk 3), beperken we ons enkel tot leesoperaties. Schrijven naar willekeurige plaatsen op deze schijf is namelijk allerminst verstandig te noemen. Als parameters voor een I/O-intensief blok in onze generator hebben we: het aantal uit te voeren toegangen, het toegangspatroon en de grootte van het te lezen blok per toegang. Voor het toegangspatroon bestaat de keuze uit sequentieel en willekeurig. Een leesoperatie wordt uitgevoerd met de fread()-functie die een blok van opgegeven lengte zal lezen vanaf de huidige positie in het geopende bestand. De fseek()-functie kan vervolgens de huidige positie in het bestand verplaatsen. 3

In Linux kan dit via /dev/sdaX. De gebruiker die de webserver uitvoert, moet dan wel genoeg rechten hebben om deze schijf te kunnen lezen.


38

Via een microbenchmark hebben we getest wat de invloed van de grootte van het te lezen blok is. Hiervoor maten we de uitvoeringstijd van de bytecode voor een willekeurige leesoperatie. Dit voerden we 100 keer uit, het gelezen adres was telkens anders. Het eerste resultaat vertoonde een overgangsverschijnsel en werd verder niet gebruikt. De uitmiddeling van de andere resultaten staat in Figuur 5.8. We hebben diezelfde test nogmaals uitgevoerd waarbij we tussen opeenvolgende uitvoeringen de caches leegmaakten 4 . De resultaten hiervan staan in diezelfde grafiek. met dropcaches zonder dropcaches

20000


18000 16000 14000 12000 10000 8000 6000 1KB

4KB

Grootte van het te lezen blok

Figuur 5.8: Invloed van de grootte van het te lezen blok op uitvoeringstijd van I/O

Het overgangsverschijnsel bij de eerste uitvoering is te verklaren doordat PHP eerst een aantal softwarebibliotheken moet ophalen voor hij de toegang naar de schijf kan openen. Wanneer we de caches tussendoor leegmaken zien we dit overgangsverschijnsel echter niet, dit komt doordat diezelfde softwarebibliotheken elke keer opnieuw opgehaald moeten worden. We zien ook dat de grootte van het te lezen blok geen invloed heeft wanneer we de caches tussen de verschillende uitvoeringen leegmaken. Wanneer we de caches tussen de metingen niet leegmaken merken we dat het ophalen van een groter blok 15% sneller is. Je zou verwachten dat het ophalen van een kleiner blok sneller zou gaan. Wat we hier zien is echter volledig te verklaren door het effect van de caches. Hoewel de opgehaalde blokken willekeurig zijn, kan de cache toch enkele (delen) van de te lezen blokken verstrekken. Als we telkens een groter blok lezen, is er ook meer data beschikbaar in de caches en is dus de kans groter dat een deel van de op te halen data zich al in de cache bevindt. We kunnen dus besluiten dat de grootte van het te lezen blok geen invloed heeft als de leesoperaties volledig random zijn aangezien de kans dat de te lezen data zich in de 4

Dit kan in Linux met het commando sync; echo 3 | sudo tee /proc/sys/vm/drop caches


39

caches bevindt dan uitermate klein is. Verder heeft het leegmaken of vervuilen van de caches vooral een effect op de uitvoeringstijd doordat de nodige softwarebibliotheken voor het lezen van de harde schijf opnieuw ingelezen moeten worden.

5.4.6

Outputintensieve bouwblokken

Een outputintensief bouwblok bevat geen PHP-code. De enige parameter voor dit soort bouwblok is het aantal karakters. Het blok bevat dan dit aantal willekeurig gekozen karakters. Aangezien geen enkel ander bouwblok output genereert kunnen we met behulp van dit bouwblok exact de hoeveelheid data die over het netwerk gestuurd moet worden voor de respons controleren. Hierbij moeten we natuurlijk in rekening nemen dat de headers van de verschillende protocollen (HTML, TCP, IP) ook over het netwerk passeren.

5.4.7

Bouwblok met externe aanvragen

Als laatste zijn er nog de externe aanvragen. Dit kunnen aanvragen zijn naar databases of andere applicatie- of webservers. Op dat moment zal het PHP-script blokkeren tot het een response krijgt op de aanvraag. Dit gedrag modelleren we in een bouwblok door het script even te laten slapen. Dit kan met de usleep()-functie [33] die x als argument neemt. De verdere uitvoering van het script wordt dan x aantal microseconden uitgesteld.

5.5

Conclusie

In het vorige hoofdstuk stelden we vast dat de energie-efficiëntste klokfrequentie voor traditionele applicaties afhankelijk is van de werklast. Webapplicaties verschillen echter op vele vlakken van traditionele applicaties. Daarom bouwden we in dit hoofdstuk een synthetische webbenchmarkgenerator. Met deze generator kunnen we een volledig spectrum aan mogelijke webapplicaties genereren aan de hand van de gepaste parameters. Om deze generator op te bouwen vertrokken we van een bestaande synthetische C benchmarkgenerator. Voor webbenchmarks identificeerden we vijf soorten bouwblokken in de code, deze zijn: processorintensief, geheugenintensief, I/O-intensief, outputintensief en externe aanvragen. Vervolgens onderzochten we wat de beste manier was om elk bouwblok op te bouwen, daaruit destilleerden we een aantal relevante parameters voor elk bouwblok. We stelden vast dat er toch grote verschillen zijn tussen C benchmarks en webbenchmarks. Voor PHP-pagina’s wordt bij elke request de pagina opnieuw geparsed en uitgevoerd. Dit introduceert een zekere overhead die er


40

voor zorgt dat heel wat fijnmazige parameters in de C benchmark geen effect hebben op de uitvoering voor de webbenchmarks.

41

Hoofdstuk 6 Experimentele resultaten 6.1

Inleiding

Dit hoofdstuk is het sluitstuk van deze masterproef. We gebruiken de benchmarkgenerator uit het vorige hoofdstuk om verschillende werklasten te genereren. Voor deze werklast onderzoeken we dan op welke klokfrequentie we de webserver moeten instellen om het energieverbruik te minimaliseren. Hierbij moeten we er rekening mee houden dat de responstijd van de requests niet te groot wordt. Dit is afhankelijk van de requestrate, die uitdrukt hoeveel aanvragen de server per tijdseenheid te verwerken krijgt. In de volgende sectie leggen we uit hoe we de testen uitgevoerd hebben. In de daaropvolgende secties bespreken we de resultaten van deze testen voor werklasten opgebouwd met elk van de bouwblokken besproken in Hoofdstuk 5. In de laatste sectie tonen we aan de hand van een real-life requestrate patroon wat het effect kan zijn van de behaalde resultaten.

6.2

Meetopstelling

We willen testen welke klokfrequentie het efficiëntst is voor een zekere werklast bij een bepaalde requestrate zonder dat de responstijd een vooropgestelde drempel overschrijdt. Hiervoor installeren we op onze server uit Hoofdstuk 3 een HTTP webserver, namelijk Apache 2.2 [34]. Vanaf een tweede server, de afspeelmachine, sturen we aan een bepaalde requestrate requests naar de webserver. Op die server meten we ook de responstijd voor elke request. Hiervoor hebben we Tsung 1.4 gebruikt [35]. Een schema van de volledige meetopstelling staat in Figuur 6.1. Tsung is een gedistribueerde, multifunctionele tool om stresstests mee uit te voeren. Vanop meerdere servers kunnen requests gestuurd worden naar één of meerdere te testen servers. Hier gebruiken we HTTP requests aangezien we een HTTP server

HOOFDSTUK 6. EXPERIMENTELE RESULTATEN

42

willen testen, maar Tsung kan ook gebruikt worden om allerhande andere protocollen te testen (bv: SOAP, MySQL). Voor een bepaalde test is de testduur instelbaar alsook de gewenste requestrate, deze kan indien gewenst ook variëren tijdens het experiment. Tsung maakt gebruik van een exponentiële distributie om de interarrivaltijden te genereren tussen de verzonden requests. Tijdens de test meet Tsung voor elke request de responstijd, de grootte van de respons, de connectietijd ... Voor de testen hier gebruiken we telkens een test van vijf minuten met een vaste requestrate tijdens de test. Uit de logbestanden van Tsung lichten we enkel de responstijden.

Figuur 6.1: Meetopstelling

Op de afspeelmachine loggen we tijdens de test via de webinterface van de EnergySwitch PDU ook het vermogenverbruik van de webserver. Op de webserver zelf loggen we via vmstat de processorbelasting. Met deze gegevens (de responstijd, het vermogenverbruik en de processorbelasting voor verschillende pagina’s, klokfrequenties en requestrates) kunnen we DVFS evalueren in een webcontext. Om tijdelijke afwijkingen en effecten uit te sluiten hebben we elke meting vijf keer herhaald met tussen de afzonderlijke metingen 30 seconden rust. Eén meetpunt in de volgende secties is dus bekomen na uitmiddeling van deze metingen en vereist een testtijd van in totaal een half uur.

6.3

Processorintensieve werklast

Voor een eerste set testen kozen we een pagina met uitsluitend processorintensieve blokken. De pagina bevat tien blokken met in elk blok een lus met daarin tien optellingen. Het aantal lusuitvoeringen werd bij elke opvraging van de pagina opnieuw gekozen uit een uniforme distributie tussen 105 en 2.105 . Verder bevat de pagina geen output. Dit wil natuurlijk niet zeggen dat er geen trafiek over het netwerk moest, aangezien er nog steeds een respons gestuurd werd met de headers van alle protocollen in de protocolstack. Het verkeer over het netwerk was daardoor wel tot het strikte minimum beperkt.


43

Een bepaalde requestrate belast de processor voor een bepaald percentage. Deze processorbelasting legt vervolgens vast hoeveel de processor verbruikt in functie van zijn klokfrequentie. We kunnen er van uit gaan dat de andere componenten in de server slechts een onbeduidende variatie teweegbrengen in het vermogenverbruik van de server, aangezien de belasting hier uitsluitend processorintensief is. De resultaten van de test met betrekking tot het vermogenverbruik staan in Figuur 6.2. Op de grafiek staan ook 95% confidentie-intervallen aangegeven met errorbars. 130

f=3,2GHz f=2,4GHz f=1,6GHz

Vermogenverbruik (W)

120 110 100 90 80 70 60 50 40

0

10

20

30

40

50

60

70

80

90

100

Processorbelasting (%)

Figuur 6.2: Invloed van de processorbelasting op het vermogenverbruik bij processorintensieve pagina’s

Zoals verwacht is voor een gegeven processorbelasting het vermogenverbruik bij een lagere klokfrequentie altijd lager dan bij een hogere klokfrequentie. We zien ook dat het vermogenverbruik niet constant is bij een vaste klokfrequentie. Tijdens de onbelaste periodes kunnen namelijk de C-states van de processor gebruikt worden, waardoor de processor op dat moment toch relatief weinig energie consumeert. In Figuur 6.3 staat de relatieve responstijd aangegeven in functie van de processorbelasting. De relatieve responstijd wordt berekend ten opzichte van de responstijd bij de hoogste klokfrequentie wanneer we één request in isolatie afspelen.We zien dat de responstijd toeneemt bij stijgende processorbelasting. Wanneer deze boven de 75–80% klimt, neemt de responstijd en de variantie op de responstijd zeer snel toe. Vanaf dit punt is het moeilijk nog een maximale responstijd te garanderen. Verder zien we ook dat de responstijd perfect schaalt met de klokfrequentie. Verdubbelen we de klokfrequentie dan halveert de responstijd. De meest praktisch bruikbare grafiek is de grafiek die de responstijd uitzet tegenover de requestrate, in Figuur 6.4. Met de conclusie van Figuur 6.2 in het achterhoofd, namelijk dat een lagere klokfrequentie naar energieverbruik altijd voordeliger

HOOFDSTUK 6. EXPERIMENTELE RESULTATEN 10


9 8 Relatieve responstijd

44

7 6 5 4 3 2 1 0

0

10

20

30

40

50

60

70

80

90

100


Figuur 6.3: Invloed van de processorbelasting op de responstijd bij processorintensieve pagina’s

6


Relatieve responstijd

5 4

3

2 1

0

0

2

4

6

8

10

12

14

16

18

20

Requestrate (requests/s)

Figuur 6.4: Invloed van de requestrate op de responstijd bij processorintensieve pagina’s

is, kunnen we uit deze grafiek heel wat afleiden. Als we voor een bepaalde pagina een maximale drempel vastleggen voor de responstijd, dan kunnen we uit de grafiek afleiden vanaf welke requestrate we welke klokfrequentie moeten gebruiken. Neem bijvoorbeeld dat de responstijd van een bepaalde pagina voor de hoogste klokfrequentie en laagste processorbelasting normaal 100ms is. Als we willen dat de responstijd maximaal 300ms wordt, dan is de drempel voor de relatieve responstijd voor dit voorbeeld 3. Voor het voorbeeld betekent dit dat we de klokfrequentie instellen op 1,6GHz tot de requestrate hoger wordt dan 7 requests/s. In dat geval schakelen we


45

naar 2,4GHz omdat de responstijden anders boven de drempelwaarde klimmen. Eens de requestrate meer dan 12,5 requests/s bedraagt, moeten we overschakelen naar de hoogste klokfrequentie. Willen we met deze server de drempel uit het voorbeeld nooit overschrijden dan kunnen we voor die pagina maximaal 18 requests/s afhandelen.

Figuur 6.5: Uitwerking voorbeeld mogelijke energiebesparing bij DVFS

Figuur 6.5 verduidelijkt het vorige voorbeeld nog verder. Op de bovenste grafiek is de drempelwaarde voor de maximale relatieve responstijd 3. Hieruit wordt de schaling van de klokfrequentie voor DVFS afgeleid: deze is aangeduid met de dikke zwarte lijn. De verticale stippellijnen bakenen het requestrate-bereik waarin elke klokfrequentie gebruikt moet worden af. Op de onderste grafiek ten slotte is de vermogenbesparing ingekleurd in het grijs. Dit is de vermogenbesparing ten opzichte van de situatie


46

waarin de klokfrequentie zou ingesteld staan op zijn maximum. In de laatste sectie van dit hoofdstuk bekijken we een voorbeeld van een echt datacenter en berekenen we hoeveel effectief bespaard kan worden. We kunnen ook vaststellen dat de vermogenbesparing sterk afhankelijk is van de vooropgestelde drempelwaarde. Het is realistisch om voor alle pagina’s van onze webapplicatie dezelfde maximale responstijd voorop te stellen. De gebruiker heeft immers voor het laden van verschillende pagina’s evenveel geduld. De standaard laadtijd kan van elke pagina echter verschillend zijn. Dit resulteert samen met de vooropgezette maximale responstijd in een verschillende drempelwaarde voor de relatieve responstijd. Bijgevolg zal de DVFS-schaling voor deze pagina’s anders moeten verlopen. Bovendien is het schalingsgedrag ook afhankelijk van de specifieke werklast. Hier hebben we nu een louter processorintensieve werklast gebruikt, in de volgende secties behandelen we de overige werklasten. We sommen nog even de belangrijkste conclusies voor processorintensieve werklasten op. Ten eerste schaalt de responstijd perfect omgekeerd evenredig met de klokfrequentie. Ten tweede neemt de responstijd vanaf een processorbelasting van 75–80% zeer snel toe. Ten derde verbruikt voor een bepaalde processorbelasting de processor altijd meer bij een hogere klokfrequentie. Ten vierde: gegeven een maximale drempel voor de responstijd kunnen we aan de hand van een grafiek die de responstijd in functie van de requestrate uitzet, een model opstellen om DVFS toe te passen.

6.4

Geheugenintensieve werklast

In een tweede set experimenten testen we geheugenintensieve pagina’s. Hiervoor gebruiken we pagina’s die uitsluitend zijn opgebouwd met geheugenintensieve bouwblokken, zoals besproken in Hoofdstuk 5. Zoals aangehaald in dat hoofdstuk variëren we hier de grootte van de gebruikte geheugenstructuur en het toegangspatroon. Zo krijgen we vier pagina’s. Enerzijds twee pagina’s met een grote datastructuur die niet meer in de caches past waarvan de ene bevraagd wordt met een sequentieel en de andere met een willekeurig toegangspatroon. Anderzijds twee pagina’s met een kleine datastructuur die wel in de caches past, waarvan de ene opnieuw met een sequentieel en de andere met een willekeurig toegangspatroon bevraagd wordt. Via een eerste test met de microtime()-functie stelden we vast dat alle pagina’s 74–78% van hun totale responstijd spenderen aan het uitvoeren van de codesectie met de geheugenoperaties. In Figuur 6.6 staat het vermogenverbruik van alle pagina’s uitgezet in functie van de processorbelasting bij de maximale klokfrequentie. Het valt meteen op dat


Klein & Willekeurig Klein & Sequentieel Groot & Willekeurig Groot & Sequentieel

130 Vermogenverbruik (W)

47

120 110 100 90 80 70 60 50

0

10

20

30

40

50

60

70

80

90

100


Figuur 6.6: Vermogenverbruik van de verschillende pagina’s bij de maximale klokfrequentie

de grafiek van de pagina met grote datastructuur met willekeurig toegangspatroon het meest afwijkt van de andere pagina’s. Deze afwijking wordt groter bij stijgende processorbelasting. De afwijking van de andere pagina’s is 11–16%. Deze pagina’s wijken onderling maximaal 5% af. Voor alle andere resultaten zien we ook dat deze drie pagina’s een gelijk gedrag vertonen. Om de grafieken in het vervolg van deze sectie niet te overladen, plotten we enkel nog de resultaten van de pagina met een kleine datastructuur met willekeurig toegangspatroon. Vervolgens bekijken we de invloed van DVFS op het vermogenverbruik in Figuur 6.7. In deze grafiek staan in stippellijn ook de grafieken van een processorintensieve pagina uit de vorige sectie. De pagina met kleine en willekeurig bevraagde datastructuur verbruikt steeds meer dan de processorintensieve pagina, bij een gelijke processorbelasting. Dit extra vermogenverbruik is het vermogen geconsumeerd door de caches en het geheugen, bij de processorintensieve pagina zijn deze componenten nauwelijks actief. De curve voor een grote, willekeurig bevraagde datastructuur blijkt minder te verbruiken dan de processorintensieve pagina. Doordat de datastructuur niet meer in de caches past en deze willekeurig bevraagd wordt, treden veel cache misses op. Het hoofdgeheugen moet bijgevolg aangesproken worden, waardoor de processor moet wachten en stallt. De processor voert op dat moment geen instructies meer uit en alle functionele eenheden zijn inactief. Door deze inactieve eenheden verbruikt de processor veel minder dan wanneer wel instructies uitgevoerd worden (zoals bij de processorintensieve pagina). Deze inactieve cyclussen worden echter wel meegeteld


48

140 Groot Groot Groot Klein Klein Klein

130


120 110

& & & & & &

Willekeurig Willekeurig Willekeurig Willekeurig Willekeurig Willekeurig

10

20

f=1,6GHz f=2,4GHz f=3,2GHz f=1,6GHz f=2,4GHz f=3,2GHz

100 90 80 70 60 50 40

0

30

40

50

60

70

80

90

100


Figuur 6.7: Vermogenverbruik van geheugenintensieve pagina’s

als belast in de processorbelasting. Dit verklaart het lagere vermogenverbruik bij deze pagina ten opzichte van de processorintensieve pagina. We zien ook dat het verschil tussen de curves voor de grote, willekeurig bevraagde datastructuur kleiner wordt wanneer de klokfrequentie naar beneden geschaald wordt. Dit komt doordat de latentie naar het hoofdgeheugen in absolute tijd even groot blijft, maar de processorcycli langer worden. De latentie naar het hoofdgeheugen neemt dus af in processorcycli. Hierdoor zal de processor minder inactieve cycli hebben en aldus meer verbruiken. Als we de responstijd van de drie pagina’s met gelijkaardige resultaten bekijken in functie van de requestrate, dan zien we hetzelfde gedrag als bij de processorintensieve pagina. Dit wil zeggen dat we een gelijkaardige redenering kunnen opbouwen als in de vorige sectie. Het enige verschil is dat het verbruik steeds hoger zal zijn door het extra verbruik van de caches en het geheugen. Het is zo dat de pagina’s enkel hetzelfde gedrag vertonen, de requestrates waarbij we moeten overschakelen naar een andere klokfrequentie verschillen wel van pagina tot pagina. De werklast heeft dus wel degelijk een invloed op de optimale klokfrequentie bij een bepaalde requestrate. De grafiek van de responstijd in functie van de requestrate voor de pagina met grote datastructuur en willekeurig toegangspatroon wijkt echter wederom af. Deze grafiek staat in Figuur 6.8. We zien dat de curves van 2,4GHz en 3,2GHz dicht bij elkaar liggen. Door de cache misses bij dit soort pagina, bestaat een deel van de responstijd uit wachttijd op het hoofdgeheugen. Deze wachttijd wordt niet be¨ınvloed door de klokfrequentie. Daardoor zal een toename van de klokfrequentie slechts een deel van de responstijd doen afnemen. Dat deel neemt verder af bij hogere



5 Relatieve responstijd

49

4

3

2 1

0

0

5

10

15

20

25


Figuur 6.8: Responstijd van een geheugenintensieve pagina met een grote datastructuur bevraagd met willekeurig toegangspatroon in functie van de requestrate

klokfrequenties, waardoor de curves dichter bij elkaar komen te liggen. Dit betekent dat als we dezelfde redenering opbouwen zoals in de vorige sectie, we zullen zien dat de hoogste klokfrequenties slechts in een kleiner requestrate-bereik bruikbaar zijn. Voor een processorintensieve pagina en de andere geheugenintensieve pagina’s is het requestrate-bereik per klokfrequentie altijd ongeveer even groot. We concluderen dat geheugenintensieve pagina’s zich gedragen als processorintensieve pagina’s met dat verschil dat ze voor een gegeven processorbelasting meer verbruiken. Dit is te wijten aan de activiteit van de caches en het geheugen bij dit soort pagina’s. Wanneer we een geheugenintensieve pagina beschouwen waarin een grote datastructuur die niet meer in de caches past, willlekeurig bevraagd wordt, dan wijkt deze wel af van het gedrag van een processorintensieve pagina. Bij hoge klokfrequenties verbruikt dit soort pagina minder dan een processorintensieve pagina, doordat er vaak op het hoofdgeheugen gewacht wordt en derhalve de functionele eenheden van de processor inactief worden. Omwille van deze wachttijd op het geheugen bij diezelfde hoge klokfrequenties, levert deze frequentie bijgevolg weinig voordeel in termen van responstijd. Zodoende worden voor dit soort pagina’s de lage frequenties in een DVFS-schema in een breder requestrate-bereik aangesproken.

6.5

Outputintensieve werklast

Een volgende set bevat puur outputintensieve pagina’s, opgebouwd met uitsluitend outputintensieve bouwblokken. In dergelijke pagina’s komen geen tags voor


50

en ze vergen bijgevolg ook geen verwerking van de PHP-parser en de PHP virtuele machine. We hebben twee pagina’s gegenereerd, de ene is 1,2KB groot de andere ongeveer 1MB. Deze pagina’s werden getest met een requestrate van 25 requests/s 1 . De gegenereerde pagina’s hadden de .php-extensie waardoor ze nog steeds de PHP-parser moesten passeren. Om de invloed van de PHP-parser te bekijken, hebben we exact dezelfde pagina’s ook getest met een .htm-extensie. Met deze extensie moeten ze de PHP-parser niet passeren. Het resultaat voor het vermogenverbruik tijdens deze test staat in Figuur 6.9. We stellen vast dat het schalen van de klokfrequentie geen invloed heeft op het vermogenverbruik. Dit is gemakkelijk te verklaren met de vaststelling dat de test met de kleine outputpagina de processor voor slechts 0,1% belast. De grote outputpagina genereert ook slechts 1% belasting. Voor de HTML-pagina’s is de belasting nog een factor tien kleiner. Deze lage belasting betekent dat de processor het merendeel van de tijd in een laagverbruikende C-state verkeert. De PHP-parser blijkt — vooral bij de pagina met veel output — toch wat overhead te genereren, dit zien we aan de vertienvoudigde processorbelasting. Dit vertaalt zich dan ook in een hoger vermogenverbruik, al is het verschil slechts 1–4%. Verder verbruiken de grote PHP-pagina’s 10–12% meer dan de kleine pagina’s, voor de HTML-pagina’s is dit 8–9%. 46


45 44

Kleine PHP-pagina Grote PHP-pagina Kleine HTML-pagina Grote HTML-pagina

43 42 41 40 39 38

1,6

2,4

3,2


Figuur 6.9: Vermogenverbruik bij outputintensieve pagina’s

Als we vervolgens de responstijd bekijken, uitgezet in Figuur 6.10, zien we dat de responstijd van een pagina met veel output een factor dertien groter is dan een pagina met weinig output. Voor de PHP-pagina’s zien we een absoluut verschil van 23ms. Gegeven dat er tussen de afspeelmachine en de webserver gigabit ethernet 1

Dit is tevens de maximale requestrate die we kunnen genereren met onze afspeelserver.


51

beschikbaar is, kunnen we perfect berekenen hoeveel van dit verschil te wijten is aan een extra netwerkdelay. verschil in bestandsgrootte 999000 × 8bit = = 8ms netwerksnelheid 109 bit s

(6.1)

We besluiten dat van de 23ms, 8ms verklaard wordt door de extra netwerkdelay. Uit het verschil met de HTML-pagina’s merken we dat de extra PHP-parsetijd ongeveer 4ms bedraagt. De resterende 11ms hebben dus louter te maken met extra verwerking op de server zoals: het ophalen van de pagina, deze incapsuleren in de juiste protocolheaders en sturen naar de netwerkinterface. Schalen van de klokfrequentie tussen de hoogste en de laagste frequentie realiseert een toename in de responstijd van 8%. We kunnen de server hier dus beter op de hoogste klokfrequentie laten staan, aangezien er toch geen verschil te merken is in het vermogenverbruik. 35

Responstijd (ms)

30

Kleine PHP-pagina Grote PHP-pagina Kleine HTML-pagina Grote HTML-pagina

25 20 15 10 5 0

1,6

2,4

3,2


Figuur 6.10: Responstijd bij outputintensieve pagina’s

We concluderen dat het voor de geteste werklast bestaande uit outputintensieve pagina’s geen zin heeft om DVFS toe te passen. Dit geldt ook voor alle andere bestanden die geen verwerking op de server vergen, zoals HTML pagina’s, afbeeldingen en andere downloadbare bestanden. Verder valt het aan te bevelen geen onnodige output te genereren en bestanden enkel een .php-extensie te geven indien dit strikt noodzakelijk is.

6.6

Werklast met externe aanvragen

Voor deze test genereerden we een pagina met uitsluitend blokken voor externe aanvragen. In Hoofdstuk 5 argumenteerden we dat we de externe aanvragen modelleren


52

door de pagina te laten slapen. In elk van de tien blokken die het bestand bevat, wordt een willekeurige slaaptijd gegenereerd met behulp van een uniforme distributie tussen 1ms en 100ms. Wat basiskennis van de statistiek leert ons dat de pagina gemiddeld 495ms slaapt. In Figuur 6.11 kunnen we het vermogenverbruik van de server bekijken in functie van de requestrate. We merken dat het vermogenverbruik nauwelijks toeneemt in functie van de requestrate. Het schalen van de klokfrequentie heeft ook geen noemenswaardige invloed op het vermogenverbruik. We zien hetzelfde fenomeen optreden als bij de outputintensieve pagina’s uit de vorige sectie. De belasting op de server stijgt nauwelijks boven de nul procent uit. De processor vertoeft het merendeel van zijn tijd in een energiezuinige C-state, terwijl het PHP-script blokkeert tot de slaaptijd afgelopen is. 40



39,5 39

38,5

38 37,5

37

0

1

2

3

4

5

6

7

8


Figuur 6.11: Vermogenverbruik bij pagina’s met externe aanvragen

Bekijken we hetzelfde experiment met betrekking tot de responstijd in Figuur 6.12 dan stellen we vast dat de klokfrequentie ook op de responstijd weinig invloed heeft. De verwerking op de server is erg beperkt: enkel het genereren van de bytecode en de willekeurige slaaptijden belasten de server. Dit is een danig klein percentage van de tijd dat een halvering van de klokfrequentie de responstijd met maximum 1% doet toenemen. Ook een stijgende requestrate doet de responstijd niet toenemen. Er treedt dan ook geen competitie op tussen de verschillende requests aangezien alle requests het leeuwendeel van de tijd vredevol slapen. De gemiddelde responstijd is 509ms. We weten dat 495ms hiervan te verklaren is door de slaaptijd. De overige 14ms bevat de Round-trip Time (RTT) van de request en de verwerking op de server. Dit verklaart nogmaals de geringe processorbelasting op de server.



540 Responstijd (ms)

53

520

500

480

460

0

1

2

3

4

5

6

7

8


Figuur 6.12: Responstijd bij pagina’s met externe aanvragen

We trekken dezelfde conclusies als voor outputintensieve pagina’s. Voor externe aanvragen heeft het geen zin DVFS toe te passen. De uitvoering wordt voortdurend geblokkeerd en het schalen van de processor kan slechts op een marginaal aandeel van de processortijd invloed uitoefenen.

6.7

I/O-intensieve werklast

In een laatste set testen bekijken we I/O-intensieve pagina’s. We genereerden twee pagina’s met elk tien I/O-intensieve bouwblokken. Elk blok bevat evenveel schijfoperaties waarbij de blokken in de eerste pagina een willekeurig toegangspatroon volgden en die in de tweede pagina een sequentieel. Elke schijfoperatie leest 4KB van de harde schijf. Een eerste test met de microtime()-functie toonde aan dat van de totale responstijd van beide pagina’s, 99% van de tijd gespendeerd wordt aan de codesectie met de schijfoperaties. In Figuur 6.13 staat het vermogenverbruik in functie van de requestrate uitgezet. We zien dat het vermogenverbruik relatief laag is. Waar het vermogenverbruik van de pagina met het willekeurig toegangspatroon snel toeneemt, stijgt dat van de pagina met sequentieel toegangspatroon nauwelijks. We zien ook dat er geen verschillen optreden wanneer we de klokfrequentie schalen. Dit kunnen we andermaal verklaren aan de hand van de processorbelasting die hier opnieuw amper boven de nul procent uit komt. De processor staat wederom voortdurend in een C-state. Aangezien er geen verschil is in de processorbelasting tussen de pagina met het sequentieel toegangspatroon en die met het willekeurig patroon, is het verschil in vermogenverbruik tussen beide sets testen afkomstig van de harde schijf. Ook de stijging in het vermo-


Willekeurig Willekeurig Willekeurig Sequentieel Sequentieel Sequentieel


43 42

54


41

40 39

38

0

0,2

0,4

0,6

0,8

1

1,2


Figuur 6.13: Vermogenverbruik van I/O-intensieve pagina’s

genverbruik voor de pagina met het willekeurig toegangspatroon is afkomstig van de schijf, want ook hier stijgt de processorbelasting nauwelijks. In Hoofdstuk 3 zagen we dat het dynamisch bereik van de harde schijf 0,7–5,3W is. De stijging van het vermogenverbruik voor de pagina met willekeurig toegangspatroon is 3,7W en past bijgevolg binnen dit bereik. 4000

Willekeurig Willekeurig Willekeurig Sequentieel Sequentieel Sequentieel

3500

Responstijd (ms)

3000


2500 2000 1500 1000 500 0

0

0,2

0,4

0,6

0,8

1

1,2


Figuur 6.14: Responstijd van I/O-intensieve pagina’s

Figuur 6.14 toont de responstijd voor dezelfde testen. Beide pagina’s moeten evenveel data lezen, toch is de responstijd voor het willekeurig toegangspatroon minimaal vijf keer zo groot. Het willekeurig toegangspatroon belast de schijf veel zwaarder, want de leeskop moet telkens verplaatst worden en wachten op de gewenste sector.


55

Hierdoor is er een grotere variantie en bijgevolg confidentie-interval op de metingen. Voor een sequentieel toegangspatroon kan de schijf simpelweg opeenvolgende sectoren lezen. Er moet bijgevolg niet gewacht worden en de leeskop moet zich slechts zelden verplaatsen. Bovendien kan het sequentieel toegangspatroon nog extra profiteren van de I/O prefetcher. Deze achterhaalt het leespatroon en haalt de volgende blokken al van de schijf nog voor ze expliciet gevraagd worden. Op die manier kan de responstijd nog verder teruggedrongen worden. We bemerken in het volledige requestrate-bereik een stijging in de responstijd van 35% voor de pagina met sequentieel toegangspatroon. Voor een willekeurig toegangspatroon is de stijging 420%. Deze laatste pagina heeft duidelijk meer last van de stijgende requestrate. Dit heeft te maken met het overlappen van verschillende requests. Op dat moment richten de twee requests verschillende aanvragen tot de harde schijf en be¨ınvloeden de requests elkaar op een negatieve manier. Hoe groter de requestrate hoe hoger de kans dat de requests overlappen. Wanneer meer requests overlappen neemt de responstijd toe door deze negatieve be¨ınvloeding. Daardoor wordt de kans dat de requests overlappen nog groter. Eens verschillende requests overlappen, neemt de responstijd dus zeer snel toe. We besluiten, net zoals bij outputintensieve pagina’s en pagina’s met externe aanvragen, dat toepassen van DVFS geen zin heeft aangezien de processor het merendeel van zijn tijd in een C-state staat te wachten. Daarnaast belast een willekeurig toegangspatroon de schijf veel zwaarder, wat leidt tot hogere responstijden en hoger vermogenverbruik. Het loont dus de moeite om fragmentatie op de schijf te voorkomen en bestanden die vaak samen gebruikt worden, contigu op de schijf te alloceren.

6.8

Toepassing

Als toepassing hebben we het systeem van het voorbeeld uit sectie 6.3 uitgewerkt voor een reëel datacenter. In een datacenter zijn er piek- en daluren voor de requestrate van de gebruikers. Zo zijn er ’s nachts bijvoorbeeld weinig requests, terwijl er ’s avonds rond zeven uur een piek te zien is. Aan de hand van deze gegevens zou men dus DVFS kunnen toepassen. In deze sectie berekenen we hoeveel energie deze methode kan besparen met de data bekomen voor processorintensieve pagina’s in sectie 6.3. Op basis van de data voor een operationeel datacenter hebben we een dagverloop van de requestrate opgesteld voor ons testsysteem. Hiervoor zijn we er vanuit gegaan dat het datacenter goed gedimensioneerd is, zodat onze server op het piekmoment ook een aanzienlijke belasting kent. Concreet hebben we het dagverloop van het echte datacenter herschaald zodat de maximale requestrate 16 is. Dit dagverloop staat in Figuur 6.15.


Belasting datacenter Drempel: 5 Drempel: 3 Drempel: 2

14

3,2

12 10 2,4

8 6


16


56

4 2 1,6 0

2

4

6

8

10

12

14

16

18

20

22

24

Uur van de dag

Figuur 6.15: Dagverloop van de requestrate in een datacenter

Zoals aangetoond in sectie 6.3 is de energiezuinigste klokfrequentie voor een vooropgestelde, maximale responstijd afhankelijk van deze maximale responstijd. Voor een andere drempelwaarde voor de responstijd, moeten we bijgevolg vanaf een andere requestrate en aldus op een ander moment van de dag overschakelen naar een andere klokfrequentie. Voor verschillende drempelwaarden voor de relatieve responstijd hebben we dit schalingsverloop uitgezet in Figuur 6.15. Hierbij moet de rechter y-as gebruikt worden om de klokfrequenties af te lezen. We zien dat wanneer we een kleinere drempel kiezen en we aldus minder marge hebben voor onze pagina, sneller overgeschakeld wordt naar een hogere klokfrequentie. 110

Maximale klokfrequentie Drempel: 5 Drempel: 3 Drempel: 2


100 90 80 70 60 50 40

2

4

6

8

10

12

14

16

18

20

22

24

Uur van de dag

Figuur 6.16: Vermogenverbruik in de loop van de dag voor verschillende DVFS-schema’s


57

Aan de hand van de requestrate op elk moment van de dag en de klokfrequentie kunnen we dan ook het vermogenverbruik van de server afleiden. Dit hebben we gedaan voor een aantal verschillende schalingsverlopen, alsook voor het schema waarbij de server constant de hoogste klokfrequentie gebruikt. Dit vermogenverbruik staat uitgezet in Figuur 6.16. Als we deze grafieken uitmiddelen over een volledige dag, dan wordt bij een drempelwaarde van vier of vijf keer de responstijd 10% energie bespaard. Voor een drempelwaarde van drie is dat nog 8,9% en voor een drempelwaarde van twee 5,7%. Uit alle experimenten blijkt dat de laagste klokfrequentie het minst energie verbruikt. De laagste klokfrequentie kan echter maar een beperkt aantal requests per seconde verwerken zonder dat de responstijd te lang wordt. Men zou denken dat het op niveau van een datacenter misschien energie-efficiënter zou zijn om gegeven een piekrequestrate meerdere servers aan de laagste klokfrequentie te zetten, dan minder servers aan de maximale klokfrequentie of met een DVFS-schema. Aan de hand van de data uit deze masterproef kunnen we perfect deze optie overwegen. Stel dat we twee servers gebruiken die ingesteld zijn op de laagste klokfrequentie om de requests van het profiel uit Figuur 6.15 af te handelen. Hierbij verdelen we de requests gelijkmatig over deze twee servers. Dan blijkt dit scenario gemiddeld 107W te verbruiken. Gebruiken we slechts één server ingesteld op de hoogste klokfrequentie, dan komen we aan een verbruik van 78W. In deze twee scenario’s stijgt de relatieve responstijd op het piekmoment van de dag maximaal tot 4,71. We kunnen deze twee scenario’s dus vergelijken met een scenario waarbij we één server schalen met DVFS en vijf als drempelwaarde voor de relatieve responstijd gebruiken. Dit laatste scenario heeft een gemiddeld verbruik van 70W. We zien dus dat de scenario’s met één server nog steeds het voordeligst zijn. Dit komt door het statisch vermogenverbruik van de server. Tijdens de onbelaste momenten verbruikt de server nog steeds 39W. Wanneer er dus een lage belasting is, hebben we in het scenario met twee servers, dubbel zoveel statisch vermogenverbruik. De winst die we halen door de servers op de laagste klokfrequentie te houden bij hogere belasting is duidelijk nog niet groot genoeg. Scenario A één server, ingesteld op de hoogste klokfrequentie Scenario B twee servers, ingesteld op de laagste klokfrequentie Scenario C één server met DVFS en 5 als drempel voor de relatieve responstijd Tabel 6.1: Uitleg verschillende scenario’s

Hardware blijft continu evolueren en het statisch vermogen van de verschillende componenten blijft afnemen. Daarom bekijken we de drie scenario’s uit Tabel 6.1


58

opnieuw voor afnemend statisch vermogenverbruik. De resultaten hiervan staan in Figuur 6.17. We kunnen zien dat meerdere servers enkel voordeliger worden dan één server aan de hoogste klokfrequentie eens het statisch vermogen 77% afneemt tot 9W. In dat geval is scenario C met DVFS nog steeds energiezuiniger dan het scenario met meerdere servers. Opdat het scenario met meerdere servers de meest efficiënte van alle scenario’s zou zijn, moet het statisch vermogen van de server 97% afnemen, zodat het statisch vermogen nog slechts 1W bedraagt.

Vermogenverbruik van het scenario (W)

110

Scenario A (1x Max) Scenario B (2x Min) Scenario C (1x DVFS)

100 90 80 70 60 50 40 30 20

0

5

10

15

20

25

30

35

40

Statisch vermogen per server (W)

Figuur 6.17: Vergelijking van verschillende scenario’s voor afnemend statisch vermogen

We besluiten dat we met DVFS tot 10% energie kunnen besparen als het toegelaten is dat de responstijd verviervoudigd. Verder blijft deze DVFS-methode te verkiezen boven het plaatsen van meerdere servers ingesteld op de laagste klokfrequentie, zelfs als het statisch vermogen 96% afneemt.

59

Hoofdstuk 7 Conclusies In deze masterproef toonden we aan dat de meest energie-efficiënte klokfrequentie afhankelijk is van de werklast. Dit deden we met behulp van de PARSEC benchmarks. Dit resultaat is dus geldig voor traditionele applicaties. Webapplicaties verschillen echter op veel manieren van traditionele applicaties. Om te testen of deze conclusie ook geldt voor webapplicaties, bouwden we een eigen webbenchmarkgenerator. Met deze generator is het mogelijk een set benchmarks te genereren op een zodanige manier dat elke webapplicatie uit het volledige spectrum gemodelleerd kan worden. Met behulp van deze benchmarkgenerator voerden we een set experimenten uit waarbij we de responstijd en het vermogenverbruik van verschillende webapplicaties maten voor verschillende instellingen van de klokfrequentie en verschillende belastingsniveaus. Voor processorintensieve webpagina’s zagen we dat de uitvoeringstijd perfect schaalt met de klokfrequentie. Aangezien een lagere klokfrequentie leidt tot een lager verbruik, kunnen we, wanneer we een maximale responstijd voorop stellen, een DVFS-schema afleiden. Dit DVFS-schema bepaalt vanaf welke requestrate overgeschakeld moet worden naar welke klokfrequentie. Op die manier wordt steeds de minst verbruikende klokfrequentie gekozen zonder dat de maximale responstijd overschreden wordt. Voor geheugenintensieve pagina’s toonden we aan dat ze zich gedragen als processorintensieve pagina’s met dat verschil dat het verbruik iets hoger ligt door de extra activiteit van de caches en het geheugen. Pagina’s die een geheugenstructuur alloceren die niet meer in de caches past en deze vervolgens met een willekeurig toegangspatroon bevragen, wijken hiervan af. Bij dit soort pagina’s kan dezelfde redenering nog steeds opgebouwd worden maar door de vaste wachttijd op het hoofdgeheugen worden de hoogste klokfrequenties in een DVFS-schema minder benut. Verder is bij de hoogste klokfrequenties het verbruik lager dan bij processorintensieve pagina’s doordat de processor stallt, alle functionele eenheden inactief worden en bijgevolg minder

HOOFDSTUK 7. CONCLUSIES

60

verbruiken. Verder concluderen we nog dat DVFS geen invloed heeft op het energieverbruik voor pagina’s en requestrates die nauwelijks een processorbelasting genereren. Dit is bijvoorbeeld het geval voor statische inhoud, die geen dynamische verwerking op de server vergt. Hierbij denken we onder andere aan gewone HTML-pagina’s en afbeeldingen. Ook voor pagina’s die veel I/O of externe aanvragen bevatten is dit het geval. Bij dit soort pagina’s staat de processor immers voortdurend in een geblokkeerde toestand te wachten tot de nodige data beschikbaar worden. Als we het DVFS-schema voor een processorintensieve pagina toepassen voor een belastingsverloop van een reëel datacenter dan bekomen we een energiebesparing van 10% als we toelaten dat de responstijd verviervoudigd. Eisen we dat de responstijd maximaal verdubbeld, dan halen we nog een energiewinst van 5,7%. We demonstreren ook dat deze DVFS-methode voordeliger is dan het plaatsen van meerdere servers ingesteld op de laagste klokfrequentie. Meer nog: zelfs als het statisch vermogenverbruik van toekomstige serverhardware tot 96% afneemt, blijft DVFS te verkiezen boven het plaatsen van meerdere servers.

61

Bibliografie [1] Gartner. Gartner estimates ICT industry accounts for 2 percent of global co2 emissions. http://www.gartner.com/it/page.jsp?id=503867, 2007. [2] McKinsey&Co. Revolutionizing data center efficiency, 2008. [3] L.A. Barroso and U. Holzle. The case for energy-proportional computing. Computer, 40(12):33–37, 2007. [4] H. Esmaeilzadeh, T. Cao, Y. Xi, S.M. Blackburn, and K.S. McKinley. Looking back on the language and hardware revolutions: measured power, performance, and scaling. In ACM SIGARCH Computer Architecture News, volume 39, pages 319–332. ACM, 2011. [5] D. Meisner, B.T. Gold, and T.F. Wenisch. Powernap: eliminating server idle power. ACM Sigplan Notices, 44(3):205–216, 2009. [6] C. Isci, A. Buyuktosunoglu, and M. Martonosi. Long-term workload phases: Duration predictions and applications to DVFS. Micro, IEEE, 25(5):39–51, 2005. [7] C. Isci, G. Contreras, and M. Martonosi. Live, runtime phase monitoring and prediction on real systems with application to dynamic power management. In Proceedings of the 39th Annual IEEE/ACM International Symposium on Microarchitecture, pages 359–370. IEEE Computer Society, 2006. [8] X. Fan, W.D. Weber, and L.A. Barroso. Power provisioning for a warehousesized computer. In ACM SIGARCH Computer Architecture News, volume 35, pages 13–23. ACM, 2007. [9] R. Raghavendra, P. Ranganathan, V. Talwar, Z. Wang, and X. Zhu. No power struggles: Coordinated multi-level power management for the data center. In ACM SIGOPS Operating Systems Review, volume 42, pages 48–59. ACM, 2008.

BIBLIOGRAFIE

62

[10] X. Wang, M. Chen, C. Lefurgy, and T.W. Keller. SHIP: Scalable hierarchical power control for large-scale data centers. In Parallel Architectures and Compilation Techniques, 2009. PACT’09. 18th International Conference on, pages 91–100. IEEE, 2009. [11] W. Felter, K. Rajamani, T. Keller, and C. Rusu. A performance-conserving approach for reducing peak power consumption in server systems. In Proceedings of the 19th annual international conference on Supercomputing, pages 293–302. ACM, 2005. [12] C. Isci, A. Buyuktosunoglu, C.Y. Cher, P. Bose, and M. Martonosi. An analysis of efficient multi-core global power management policies: Maximizing performance for a given power budget. In Microarchitecture, 2006. MICRO-39. 39th Annual IEEE/ACM International Symposium on, pages 347–358. IEEE, 2006. [13] Y. Chen, A. Das, W. Qin, A. Sivasubramaniam, Q. Wang, and N. Gautam. Managing server energy and operational costs in hosting centers. In ACM SIGMETRICS Performance Evaluation Review, volume 33, pages 303–314. ACM, 2005. [14] T. Horvath, T. Abdelzaher, K. Skadron, and X. Liu. Dynamic voltage scaling in multitier web servers with end-to-end delay control. Computers, IEEE Transactions on, 56(4):444–458, 2007. [15] Intel Corporation. Intel Xeon Processor E3-1230 (8M Cache, 3.20 GHz). http: //ark.intel.com/products/52271/. op 3 juni 2012. [16] Advanced configuration and power interface. http://en.wikipedia.org/w/ index.php?title=Advanced_Configuration_and_Power_Interface. op 3 juni 2012. [17] cpufrequtils 007. http://packages.ubuntu.com/natty/cpufrequtils. op 3 juni 2012. [18] Western digitial caviar green drives - cool, quiet and eco-friendly. http://www. wdc.com/en/products/products.aspx?id=120. op 3 juni 2012. [19] S. Gurumurthi, A. Sivasubramaniam, M. Kandemir, and H. Franke. Reducing disk power consumption in servers with DRPM. Computer, 36(12):59–66, 2003. [20] DDR3 SDRAM. http://en.wikipedia.org/wiki/DDR3_SDRAM. op 3 juni 2012.

BIBLIOGRAFIE

63

[21] Rackativity EnergySwitch 1008 PDU. http://www.racktivity.com/media/ pdf/Racktivity_EnergySwitch_ES1000_Series-Datasheet.pdf. op 3 juni 2012. [22] C. Bienia. Benchmarking modern multiprocessors. PhD thesis, Princeton University, 2011. [23] F.F.H. Nah. A study on tolerable waiting time: how long are web users willing to wait? Behaviour & Information Technology, 23(3):153–163, 2004. [24] PHP. http://en.wikipedia.org/wiki/PHP. op 3 juni 2012. [25] PHP. http://php.net. op 3 juni 2012. [26] A.M. Joshi, L. Eeckhout, and L.K. John. The return of synthetic benchmarks. In 2008 SPEC Benchmark Workshop, 2008. [27] K. Du Bois, T. Schaeps, S. Polfliet, F. Ryckbosch, and L. Eeckhout. SWEEP: evaluating computer system energy efficiency using synthetic workloads. In Proceedings of the 6th International Conference on High Performance and Embedded Architectures and Compilers, pages 159–166. ACM, 2011. [28] gettimeofday, linux man page. http://linux.die.net/man/2/gettimeofday. op 3 juni 2012. [29] microtime, PHP manual. http://php.net/microtime. op 3 juni 2012. [30] Alternative PHP cache, PHP manual. apc.php. op 3 juni 2012.

http://php.net/manual/en/book.

[31] microtime, PHP manual. http://php.net/microtime. op 3 juni 2012. [32] Filesystem functions, PHP manual. http://php.net/filesystem. op 3 juni 2012. [33] usleep, PHP manual. http://php.net/usleep. op 3 juni 2012. [34] Apache HTTP webserver. http://httpd.apache.org/. op 3 juni 2012. [35] Tsung. http://tsung.erlang-projects.org/. op 3 juni 2012.

64

Lijst van figuren 3.1 3.2 3.3 3.4 4.1 4.2 4.3

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 6.2 6.3 6.4

Gemiddeld vermogenverbruik in onbelaste toestand voor verschillende configuraties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taartdiagram vermogenverdeling in onbelaste toestand . . . . . . . . Gemiddeld vermogenverbruik van Facesim benchmark voor verschillende configuraties . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taartdiagram vermogenverdeling in belaste toestand . . . . . . . . . Gemiddeld vermogenverbruik voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie . . . . . . . . . . . . . . . . . Uitvoeringstijd voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . Totaal energieverbruik voor de geselecteerde PARSEC benchmarks in functie van de klokfrequentie . . . . . . . . . . . . . . . . . . . . . . . Drie fasen van een synthetische benchmarkgenerator . . . . . . . . . . Invloed van de bewerking in PHP vs C . . . . . . . . . . . . . . . . . Invloed van de IIDD in PHP vs C . . . . . . . . . . . . . . . . . . . . Structuur microbenchmarks . . . . . . . . . . . . . . . . . . . . . . . Invloed van de codelengte in PHP . . . . . . . . . . . . . . . . . . . . Uitvoeringstijd van lees- en schrijfoperaties in het geheugen . . . . . . Invloed van het toegangspatroon op uitvoeringstijd van geheugenoperaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invloed van de grootte van het te lezen blok op uitvoeringstijd van I/O Meetopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invloed van de processorbelasting op het vermogenverbruik bij processorintensieve pagina’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invloed van de processorbelasting op de responstijd bij processorintensieve pagina’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invloed van de requestrate op de responstijd bij processorintensieve pagina’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 16 16 18

20 21 23 29 32 32 33 34 35 36 38 42 43 44 44

LIJST VAN FIGUREN 6.5 6.6 6.7 6.8

6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17

Uitwerking voorbeeld mogelijke energiebesparing bij DVFS . . . . . . Vermogenverbruik van de verschillende pagina’s bij de maximale klokfrequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vermogenverbruik van geheugenintensieve pagina’s . . . . . . . . . . Responstijd van een geheugenintensieve pagina met een grote datastructuur bevraagd met willekeurig toegangspatroon in functie van de requestrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vermogenverbruik bij outputintensieve pagina’s . . . . . . . . . . . . Responstijd bij outputintensieve pagina’s . . . . . . . . . . . . . . . . Vermogenverbruik bij pagina’s met externe aanvragen . . . . . . . . . Responstijd bij pagina’s met externe aanvragen . . . . . . . . . . . . Vermogenverbruik van I/O-intensieve pagina’s . . . . . . . . . . . . . Responstijd van I/O-intensieve pagina’s . . . . . . . . . . . . . . . . . Dagverloop van de requestrate in een datacenter . . . . . . . . . . . . Vermogenverbruik in de loop van de dag voor verschillende DVFSschema’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vergelijking van verschillende scenario’s voor afnemend statisch vermogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 45 47 48

49 50 51 52 53 54 54 56 56 58

66

Lijst van tabellen 3.1 3.2 3.3

Overzicht testsysteem . . . . . . . . . . . . . . . . . . . . . . . . . . . Overzicht processor Xeon E3-1230 . . . . . . . . . . . . . . . . . . . . Overzicht schatting vermogenverdeling bij uitvoeren van Facesim . . .

11 12 17

5.1 5.2

Vergelijking bouwblokken C en PHP benchmarks . . . . . . . . . . . Geheugengebruik van PHP arrays . . . . . . . . . . . . . . . . . . . .

31 36

6.1

Uitleg verschillende scenario’s . . . . . . . . . . . . . . . . . . . . . .

57

Evaluatie van DVFS met behulp van synthetische webbenchmarks

Recommend Documents