SSDs påverkan på MySQL En prestandajämförelse

Examensarbete i datavetenskap C-nivå SSDs påverkan på MySQL En prestandajämförelse Författare: Edison Gashi och Jacob Carlsson Handledare: Patrik Brandt Termin: VT12 Kurskod: 2DV40E

Abstrakt Solid State Drives (SSD) blir idag allt vanligare som lagringsmedium och håller på att bli ett alternativ till magnetiska hårddiskar. Denna studie+ har undersökt hur man på bästa sätt kan utnjytta SSDer i en MySQL-databas. Undersökningen genomfördes med hjälp av experiment där prestandamätningar gjordes för att få en klar bild på i vilken konfiguration av SSDs som ger bäst prestanda i MySQL. Mätverktygen som användes var sql-bench och mysqlslap. Resultaten visar att en databas på en enskild SSD presterar lika bra som en databas med SSD-cache under majoriteten av mätningarna och visar bättre resultat än resterande konfigurationerna som var en databas på hårddisk och transaktionsloggen på en SSD. Nykelord: Databas, MySQL, OpenIndiana, mysqlslap, sql-bench, Solid State Drive, Hårddisk, Prestanda, ZFS I

Abstract Solid State Drives (SSD) are now becoming more common as storage and is about to become an alternative to magnetic disks. This report studied how to best utilize SSDs in a MySQL database. This study was carried out using experiments in which performance benchmarks were made to get an accurate view on which configuration of SSDs that gives the best performance in MySQL. The benchmarks where made with sql-bench and mysqlslap. The results indicate that a database using only SSD storage performs equal to a database of solid-state cache under the majority of the tests and shows better results than the remaining configurations that include a database on a single hard drive and a configuration with the transaction log on a SSD. Keywords: Database, MySQL, OpenIndiana, mysqlslap, sql-bench, Solid State Drive, Hård drive, Performance, ZFS II

Förord Vi vill tacka vår handlerade Patrik Brandt för att under arbetets gång givit oss ett stort stöd. Vi vill också tacka Linnéuniversitet för att tillhandahållit hårdvara som krävdes för att möjliggöra undersökningen. III

Innehåll Innehåll IV 1 Introduktion 1 1.1 Inledning 1 1.2 Tidigare forskning 1 1.3 Problemformulering 1 1.4 Syfte och frågeställning 2 1.5 Avgränsning 2 1.6 Målgrupp 2 1.7 Disposition 2 2 Bakgrund 3 2.1 Operativsystem 3 2.1.1 OpenIndiana 3 2.2 Datalagring 3 2.2.1 Magnetiska hårddiskar 3 2.2.2 Solid State Drive 4 2.2.3 ZFS 4 2.3 Databas 4 2.3.1 MySQL 5 3 Metod 6 3.1 Vetenskaplig ansats och urval 6 3.2 Studieobjekt 6 3.3 Testverktyg 6 3.4 Experimentmiljö 7 3.5 Genomförande 7 3.5.1 Scenario 1 Databas på hårddisk 8 3.5.2 Scenario 2 Databas på SSD 8 3.5.3 Scenario 3 ZIL & L2ARC 9 3.5.4 Scenario 4 Transktionslogg på SSD 9 3.6 Metoddiskussion 10 4 Resultat 11 4.1 Mätresultat för sql-bench 11 4.2 Mätresultat för mysqlslap 13 IV

5 Analys 14 5.1 Analys av sql-bench 14 6 Diskussion 19 6.1 Resultat 19 6.2 Metodreflektion 19 7 Avslutning 20 7.1 Slutsats 20 7.2 Förslag till fortsatt forskning 20 Referenser 21 Bilagor 24 Bilaga 1: Resultat från sql-bench 24 Bilaga 2: Resultat från mysqlslap 60 V

1 Introduktion För att få en djupare förståelse för vad detta arbete behandlar kommer här problemet beskrivas. En sammanfattning om den tidigare forskningen som finns inom detta ämne finns även att läsa. Arbetet har fokuserat kring en tidigare forskning [1] där författarna menar att SSD-enheter kan ha många olika användningsområden i en databas, men det är oklart vad som ger den bästa prestandan. 1.1 Inledning En ny typ av lagring som snabbt växt sig in på marknaden är Solid State Drives (SSD). Detta lagringsmedium håller idag på att bli ett alternativ till magnetiska hårddiskar. Det kommer därför vara nödvändigt att förr eller senare integrera dessa enheter i företagsmiljöerna. Ett möjligt användningsområde som Ioannis och Stratis [1] diskuterar är databaser. Databaser har länge använt magnetiska hårddiskar för att lagra all information på. Fördelen med denna typ av lagring är mängden data som kan lagras på en och samma enhet, jämfört med en SSD i samma prisklass. Magnetiska hårddiskar lider ofta av sämre prestanda än SSD-enheter. En anledning till detta är avsaknaden av mekansiska delar hos SSD-enheter. En läsarm används för att läsa och skriva data till hårddisken. Alternativet till den mekaniska lagringen, som redan nämnts är flashbaserad lagring. Dessa enheter beroende på modell presterar ofta betydligt bättre än en mekanisk tack vare avsaknaden av rörliga delar. Det är idag oklart hur en solid state drive (SSD) påverkar prestandan för en databas, speciellt när prestanda och kapacitet skiljer sig väldigt mycket mellan olika märken och modeller. Ioannis och Stratis [1], menar att vissa enheter kan vara betydligt långsammare än mekaniska hårddiskar vid slumpmässiga skrivningar (random writes), medan andra är snabbare vid både slumpmässiga läsningar och skrivningar (random reads & random writes). Frågan som de ställer [1], och denna uppsats ska försöka svara på är hur SSD-enheter bäst utnyttjas i ett Database Management System (DBMS). 1.2 Tidigare forskning Författarna bakom artikeln [1], säger att det saknas en hel del forskning gällande Solid State Drives, speciellt i samband med databaser. När egenskaper som pris och prestanda ständigt ändras, bildas automatiskt flera klasser av SSDer. Det enda som verkar vara gemensamt för samtliga enheter är en utmärkt random read-prestanda. De övriga egenskaperna kan skilja dramatiskt mellan olika enheter. Vissa enheter som testats har haft en sämre random write-prestanda, medan andra enheter presterar överlägset bättre i både random read och write throughput och latency. Eftersom det visar sig skilja mycket mellan olika enheter återstår frågan om hur varje klass med SSDer bör användas i en databas. Svaret på denna fråga beror på hur mycket DRAM som finns tillgängligt för systemet, men även vad för typ av underliggande hårddiskar som används. [1] 1.3 Problemformulering Enligt Ioannis och Stratis [1], är det idag oklart hur prestandan på databaser påverkas av SSD-enheter. Då pris och prestanda skiljer mellan olika enheter är det intressant att hitta ett unikt användningsområde för olika typer av SSD-enheter. 1

Vissa enheter kan prestera bättre i slumpmässiga skrivningar (random writes), vilket gör att de kanske lämpar sig bättre till ett visst användningsområde. Ett av dessa användningsområden som kommer undersökas i denna studie är att använda SSDenheter som cache för en vanlig hårddisk. För att testa detta kommer testerna ske med filsystemet ZFS, som erbjuder ett sätt att använda SSDer i kombination med vanliga hårdiskar, för att öka läs- och skrivhastigheter. Utöver denna cache-lösning är det möjligt att placera transaktionsloggen för en databas på en SSD-enhet [1]. Studien kommer ta reda på i vilken konfiguration en SSD tillsammans med en mekanisk hårddisk ger bäst prestanda för en databas. 1.4 Syfte och frågeställning I en tidigare forskning av Ioannis och Stratis [1] behandlas, SSD-enheters prestandapåverkan på databaser. Denna forskning saknar dock den praktiska undersökningen, de kommer fram till att SSDer förmodligen kan påverka prestandan på en databas, men det lämnas otestat. Syftet med undersökningen är att ta reda på hur SSD-enheter i en viss prestandaklass utnyttjas bäst, för att ge högsta möjliga prestanda. För att ta reda på vilken konfiguration av SSD-enheter som presterar bäst kommer ett antal prestandamätningar utföras mot en databas. Mätningarna kommer att undersöka hur snabbt en databas kan genomföra olika arbetsuppgifter som att skapa tabeller, lägga till objekt och poster. Den fråga som undersökningen kommer försöka besvara är: Med målet att effektivt kunna bearbeta ett stort antal databas-förfrågningar, vad är det bästa användningsområdet för SSD-enheter i en databas-server? 1.5 Avgränsning Denna studie begränsas till databasen MySQL pågrund av att det är open-source och finns tillgängligt för en mängd olika plattformar [2]. Den databasen som är bland de mest populära är Microsofts SQL Server [3], då studien har för avsikt att inkludera filsystemet ZFS, som inte är kompatibelt med Microsoft SQL Server [4]. ZFS används även i Oracle Solaris 11 [5], men eftersom de inte tillåter publicering av prestandatester utan tillåtelse först [6], uteslöts det från studien. Pågrund av dessa begränsningar kommer alla tester utföras i operativsystemet OpenIndiana. 1.6 Målgrupp Arbetet riktar sig framför allt till mindre företag som ska implementera eller vill förbättra sin befintliga databas med begränsade resurser. Arbetet riktar sig även till de individer som har ett intresse eller är verksamma inom ett relevant yrke. 1.7 Disposition Arbetet innehåller en grundläggande förklaring kring arbetet, problemformulering och syfte. Det innehåller även en teknisk bakgrund som behandlar de olika mjukvaror och tekniker som har används för att möjliggöra arbetet. Den vetenskapliga metoden presenteras i kapitel tre, där även de olika testverktyg som arbetet har använt sig av presenteras. Efter metod kommer resultaten presenteras i tabell- och diagram-form. Efter resultaten kommer analys och diskussion i ett varsitt kapitel. 2

2 Bakgrund I det här kapitlet finns grundläggande information om de tekniker och program som används i genomförandet av arbetet. 2.1 Operativsystem Operativsystemet är den viktigaste komponenten som utgör en dator, utan den blir datorn mer eller mindre obrukbar. Det är en länk mellan datorns hårdvara och de olika mjukvaror användaren väljer att köra på datorn.operativsystemet i sig måste vara gjort så att hårdvaran kan utnyttjas effektivast [11]. Ett operativsystem ska enligt [14], kunna fördela de resurser som finns mellan konkurrerande komponenter, genom ett gemensamt gränssnitt för hårdvaran och de applikationer som körs. Operativsystemet är en uppsättning av en eller flera applikationer som gör att mjukvara och hårdvara kan kommunicera. Det ansvarar även för att hantera delade resurser mellan flera processer. Sedan datorn uppfanns på 1940-talet, har eftersträvan varit att göra operativsystemet så effektivt som möjligt, samtidigt som det fortfarande är användarvänligt [11]. 2.1.1 OpenIndiana OpenIndiana är ett community-utvecklat operativsystem utvecklat med öppen källkod. Det är en Solaris-distribution som liknar OpenSolaris och en del av Illumos- Stiftelsen. Syftet med projektet är att bli den OpenSolaris distributionen för produktionsservrar där säkerhet och buggfixar ska ingå utan extra kostnad. [12] När Oracle köpte upp Sun Microsystems 2009 [29], gjordes ett val att lägga ner utvecklingen av OpenSolaris, och istället ersätta det med en egen version. ZFS som tidigare ägdes av Sun Microsystems tillhör nu Oracle. Illumos valde att skapa en egen version av OpenSolaris senaste version, som är kompatibel med Solaris 11 Express, på samma sätt som CentOS följer utvecklingen av Red Hat Enterprise Linux[12]. 2.2 Datalagring Ett system som används för datalagring måste ha tillgång till ett medium, där data kan lagras. Det ska finnas sätt att skriva, läsa och tolka data. Till exempel, om denna text var utskrivet på ett papper, skulle pappret tolkas som ett medium. Bläcket skapar information när det skrivs ner på pappret, där det lagras. För att läsa informationen som står på pappret använder vi våra ögon. Till slut tolkar våra hjärnor den data som har lagrats på pappret. Komponenter med liknande funktioner finns i det flesta datalagringsenheterna, till exempel i en mekanisk hårddisk. [21] 2.2.1 Magnetiska hårddiskar En mekanisk hårddisk består av en eller flera magnetiska roterande skivor. På dessa skivor lagras och läses data ifrån med hjälp av en läs och skrivarm. För att utöka lagringskapaciteten kan data lagras på båda sidorna av en skiva. All data lagras i cirkulära spår på skivorna och antalet spår som kan packas ihop kallas för TPI (tracks per inch) [21]. Läs- och skrivhastigheterna på en hårddisk påverkas bland annat av hur snabbt skivorna roterar. I dagens vanligaste typ av mekaniska 3

hårddiskar ligger hastigheten på skivorna runt 7,200 varv i minuten, och har en läsoch skrivhastighet mellan 50-100 MB/s[13]. 2.2.2 Solid State Drive Består av flera flashminnen som är sammankopplade, vilket gör att den inte har några rörliga delar som den mekaniska hårddisken. SSDs använder sig av celler som den lagrar data på och det finns två olika typers celler, MLC(Multi-level Cell) och SLC(Single-level Cell). Skillnaden mellan de två är att MLC lagrar data på olika nivåer i sina celler, medans SLC bara har en nivå i sina celler. Beroende på vilken typ av SSD som gäller, påverkas bland annat lagringsstorleken på samma yta och hastigheten. SLC har bättre hastigheter men sämre lagringsstorlek på samma yta än vad MLC har. MLC är den typen som används under arbetets gång, och enligt specifikationerna [31] kan enheten uppnå läshastigheter upp till 525 MB/s, samt skrivhastigheter upp till 475 MB/s.[15] 2.2.3 ZFS Jeff Bonwick som är en av utvecklarna bakom filsystemet ZFS [27], berättar att designmålen med filsystemet var från första början att skapa ett filsystem med fokus på dataintegritet, enkel administration och hög kapacitet [26]. Den största anledningen till ZFS framgång, är enligt [9] att för att det är ett väldigt simpelt, men samtidigt ett väldigt kraftfullt filsystem. Anledning till att ZFS kan utlova hög dataintegritet är dess implementering av copyon-write. Genom att skapa kopior av viktiga block, där samtliga kopior pekar på ursprungsblocket kan korrupt data undvikas. Detta överliggande ursprungsblock heter uberblock. Varje uberblock kan ha upp till tre kopior av sig själv, såkallade ditto-block som pekar på uberblocket. Som standard skapas en kopia för redundans av data, och flera för metadata. Om filsystemet upptäcker att checksumman av ett block inte stämmer, kommer en underliggande kopia med korrekt checksumma användas för att återskapa data. [20] En annan metod för att undvika korrupt data och samtidigt öka prestandan är använda en skrivlogg, till det finns ZFS Intent Log, förkortat ZIL. Enbart synkrona skrivningar till disk kan hanteras av ZIL. ZIL loggar alla systemanrop och innehåller då all nödvändig information som krävs för att kunna återskapa data om en systemcrash skulle inträffa. [28] För att hantera läsning från filsystemet används Layer 2 Adaptive Replacement Cache, förkortat L2ARC och är en läs-cache. Det används för att lagra data som ska läsas, utanför primärminnet. SSDer kan med fördel användas som L2ARC, men är långsammare än DRAM, dock fortfarande väldigt mycket snabbare än vanliga hårddiskar. [28] 2.3 Databas En databas är en strukturerad kollektion av data. Data kategoriseras som antingen end-user data eller metadata. End-user data är rå fakta som är av intresse för slutanvändaren. Metadata innehåller information om data och dess relationer inom en databas[16]. Möjligheterna till vad en databas kan användas 4

till är stora, det kan vara allt från enkla shoppinglistor med lite information, till stora listor som innehåller information om anställda på ett företag. För att hämta ut, lägga till och modifiera data i en databas används en databashanterare [17].Några vanligt förekommande operationer som används för detta är INSERT för att lägga till nya rader i en tabell, SELECT för att hämta ut data ur en tabell, UPDATE för att upppdatera data i ett kolumn med nya världen och DELETE som tar bort specifika rader i en tabell [33]. Dessa operationer utgör grunden för hur data hanteras. En eller flera operationer som hämtar eller ändrar data är en transaktion. Genom att gruppera fler operationer till en transaktion tvingas MySQL att alla operationer slutförs för att säkerhetsställa data integritet, kommer ingen av de ändringar operationerna gjort skrivas ner till disk. [23] 2.3.1 MySQL Databasen MySQL är den populäraste databashanteraren, byggd på öppen källkod[18]. Vilket innebär att det är helt gratis att använda och modifiera MySQL är utvecklat av företaget MySQL AB som nu ägs av företaget Oracle, sedan 2010 [19]. På grund av att MySQL är uppbyggd på öppen källkod är alternativen större för vilka operativsystem som stöds, tillskillnad från de kommersiella databashanterarna. De mest populära plattformarna för MySQL är Windows, Macintosh och Linux[18]. MySQL kan hantera extremt stora och komplexa databaser utan att tappa mycket i prestanda. Yahoo, NASA och Texas Instruments är exempel på företag och organisationer som använder sig av MySQL för att hantera sina stora databaser[23]. 5

3 Metod I detta kapitel förklaras den vetenskapliga ansatsen och den metod som användes. Kapitlet presenterar också den experimentmiljö som studien är baserad på, samt hur den var konfigurerad. Enheter och mjukvara som användes under studien beskrivs utförligt under kapitlet 3.2 Studieobjekt. 3.1 Vetenskaplig ansats och urval För att ta reda på i vilken konfiguration SSD-enheter ger den bästa generella prestandan används en kvantitativ metod. Den kvantitativa metoden passar bäst in då studien utför mätningar och tester av experiment. Data som samlats in under studien har analyserats för att nå ett resultat. [34] Författarna bakom artikeln Data Mangement Over Flash Memory [1], beskriver sex olika konfigurationer som är möjliga att använda, för att öka den generella prestandan på en databas. Alternatives include (a) using the SSD as persistent storage, either in combination with HDDs or by itself, (b) using the SSD as a cache for the HDDs, (c) using the SSD as a transactional log, (d) using the HDD as a log-structured write cache for the SSD, (e) using the SSD as a temporary buffer for specific query evaluation algorithms (e.g., sorting), and, of course, (f) any combination of the above. Undersökningen har begränsats till att jämföra en enskild SSD på en databas, en databas med SSD-cache och implementera transaktionsloggen på en SSD. Studien tar inte upp resterande konfigurationer på grund av tidsbrist och begränsad tillgång till hårdvara på Linnéuniversitetet. 3.2 Studieobjekt För att utföra denna typ av experiment behövs någon form av hårdvara, och i detta fall en Dell Optiplex GX620. Följande hårdvara gäller för samtliga tester. Processor: Intel Pentium D 2,8GHz Ramminne: 4x 1GB, DDR2, 533MHz 2x Seagate Barracuda 160GB 7200 RPM 8MB Cache SATA 3.0Gb/s 2x OCZ Agility 3 Series SATA III 2.5" SSD 60GB För att kunna utföra prestandatester mot hårdvaran behövs flera mjukvaror, till att börja med ett operativsystem, databashanteraren och till sist de olika testverktygen. Openindiana 151a Server Edition MySQL 5.1.62 sql-bench mysqlslap 3.3 Testverktyg För att kunna avgöra vilken konfiguration presterar bäst, behövs ett testverktyg. Det finns ett antal olika verktyg för att mäta prestandan i MySQL [30], två av dessa verktyg har används i undersökningen för att belasta och mäta prestandan i MySQL. 6

MySQL Benchmark Suite (sql-bench) är ett verktyg från MySQL, som används för att mäta prestandan hos MySQL-servrar. Det är i grunden en samling perl-skript som mäter hur snabbt databasen klarar av att utföra olika uppgifter och sedan få ett resultat som berättar hur lång tid det tog att utföra varje uppgift. När testet är klart kommer det rapporteras hur bra databasen kunde utföra olika operationer. [7, 30] Skriptet som används i studien heter run-all-test. När detta skript körs startar den flera mindre test, ett för varje typ av operation [7]. mysqlslap ett verktyg som används för att emulera klient-last på en MySQL-server, som sedan rapporterar den tid det tar att genomföra varje steg. Verktyget kan emulera flertalet klienter som samtidigt arbetar mot databasen. Det finns tillgängligt för MySQL-version 5.1.4 och senare. [25, 30] 3.4 Experimentmiljö Experimentmiljön består av en dator av modell Dell Optiplex GX620, med tillhörande hårddiskar och SSDer, som konfigurerades om i ZFS beroende på scenario. Operativsystemet Openindiana 151a installerades med grundinställningar för att inte påverka resultaten. Datorn kopplades ihop med flera virtuella maskiner, en med m0n0wall, som är ett router-operativsystem. Det användes för att ge servern internetåtkomst. Den andra virtuella maskinen bestod av Windows XP, där SSHklienten PuTTY installerades och användes för att lättare konfigurera systemet och köra testerna. I de flesta scenarion användes ZFS-poolen tank som bestod av den disk som inte användes av operativsystemet. Anledningen till detta var att ZFS inte tillåter ZIL och/eller L2ARC att användas med rpool. Till poolen tank konfiguredes sedan SSDdiskar som ZIL och L2ARC. För att få MySQL att arbeta mot den disk vi lagt i poolen tank, konfigurerades MySQL att spara all data till /tank/mysql/data genom att i konfigurationsfilen /etc/my.cnf lägga till raden datadir=/tank/mysql/data och sedan ge användaren och gruppen mysql fullständiga rättigheter från /tank/mysql/data ner till roten. 3.5 Genomförande Fyra olika testscenarion skapades med helt olika konfigurationer. Under varje testscenario utfördes tre tester per mätprogram för att validera riktigheten av resultaten. Samtliga resultat dokumenterades och sedan skapades ett medelvärde över de tester som gjorts. Resultaten kommer att visas i tabeller och eventuella trender för de olika konfigurationerna jämförs i form av diagram under kapitel 5 Analys. Förkonfiguration av experimentmiljö MySQL 5.1.62 finns att ladda ner på mysql.com och det gjordes med kommandot: wget http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.62-solaris10- i386.pkg.gz När filen är nerladdad ska den packas upp och installeras: 7

gunzip mysql-5.1.62-solaris10-i386.pkg.gz pkgadd -d mysql-5.1.62-solaris10-i386.pkg Testprogramvaran sql-bench kräver perl-pluginen DBI och DBD::mysql. För att installera dessa behövs en c-kompilator. För att installera Sun Studio 11: sudo pkg set-publisher -g http://pkg.openindiana.org/legacy opensolaris.org sudo pkg install pkg:/developer/sunstudio12u1 sudo mkdir -p /opt/sunwspro sudo ln -s /opt/sunstudio12.1 /opt/sunwspro/sunstudio12.1 Sedan går det att installera nödvändiga moduler: perl -MCPAN -e shell install DBI install DBD::mysql 3.5.1 Scenario 1 Databas på hårddisk För det första scenariot skapades en ny Zpool vid namn tank, och sedan ett filsystem på det. Det gjordes med följande kommando: zpool create tank c4d1 zfs create tank/mysql För att sedan MySQL ska spara all data på den nya zpoolen, stoppades MySQLtjänsten och sedan editerades konfigurationsfilen för MySQL /etc/my.cnf. Där följande rad las till datadir=/tank/mysql/data. För att samtliga databaser inte ska försvinna när sökvägen till databas-filerna uppdateras flyttas /var/lib/mysql till /tank/mysql/data med kommandot: cp -R -p /var/lib/mysql /tank/mysql/data När all konfiguration var klar startades MySQL-tjänsten igen och testerna började med sql-bench, som standard följer med MySQL. Börja med att ändra sökvägen: cd /opt/mysql/mysql/sql-bench/ För att köra starta ett test skrivs kommandot nedan (detta upprepades tre gånger): perl run-all-tests --server=mysql Efter samtliga tester med sql-bench, fortsatte testerna med mysqlslap. För att belasta databas-motorn så mycket som möjligt kommer en större mängd förfrågningar att göras. Ett test med 50 000 förfrågningar uppdelat på 100 användare användes genom att skriva kommandot nedan (detta upprepades tre gånger):./opt/mysql/mysql/bin/mysqlslap --user=root --auto-generate-sql --concurrency=100 --number-of-queries=50000 --engine=innodb 3.5.2 Scenario 2 Databas på SSD För det första scenariot skapades en ny ZFS-pool vid namn tank, och sedan ett filsystem på det. Det gjordes med följande kommando: zpool create tankssd c5d0 zfs create tank/mysql 8

För att sedan MySQL ska spara all data på det nya filsystemet, stoppades MySQLtjänsten och sedan editerades konfigurationsfilen för MySQL /etc/my.cnf. Där följande rad ändrades till datadir=/tank/mysql/data. För att samtliga databaser inte ska försvinna när sökvägen till databas-filerna uppdateras flyttas /var/lib/mysql till /tank/mysql/data med kommandot: cp -R -p /var/lib/mysql /tankssd/mysql/data För att köra starta ett test skrivs kommandot nedan (detta upprepades tre gånger): perl run-all-tests --server=mysql Efter samtliga tester med sql-bench, kördes samtliga tre tester med mysqlslap. 3.5.3 Scenario 3 ZIL & L2ARC Poolen tank existerar redan, men zpoolen tankssd behöver förstöras för att göra båda SSD-enheter tillgänliga för användning: zpool destroy tankssd Sedan behöver bara konfigurationsfilen för MySQL /etc/my.cnf editeras. Där följande rad ändrades till datadir=/tank/mysql/data. För att skapa ZIL och L2ARC används följande två kommandon: zpool add tank log c5d0 zpool add tank cache c5d1 För att köra starta ett test skrivs kommandot nedan (detta upprepades tre gånger): perl run-all-tests --server=mysql Efter samtliga tester med sql-bench, kördes samtliga tre tester med mysqlslap. 3.5.4 Scenario 4 Transktionslogg på SSD För att ta bort SSD-diskarna som används som ZIL och L2ARC används kommandona: zpool remove tank c5d0 zpool remove tank c5d1 Sedan skapas en ny pool med en SSD: zpool create tankssd c5d0 För att få MySQL att skriva transaktionsloggen till en SSD-disk, editeras konfigurationsfilen för MySQL med raden logdir=/tankssd/. För att köra starta ett test skrivs kommandot nedan (detta upprepades tre gånger): perl run-all-tests --server=mysql Efter samtliga tester med sql-bench, kördes samtliga tre tester med mysqlslap. 9

3.6 Metoddiskussion Experimentmiljön under studien är uppbyggd helt på riktig hårdvara, vilket anses ge en större tillförlitlighet på resultaten. En utomstående person kan sätta upp ett av scenarierna och få likartade resultat som denna studie presenterar. Det finns många faktorer som kan påverka resultatet i denna studie, både inom hård- och mjukvaran. Det är inte enbart lagringen som påverkar prestandan i en databas, artikeln Data Mangement Over Flash Memory förklarar att mängden DRAM som finns tillgängligt på datorn och hur snabbt det är kan påverka prestandan [1]. Inom mjukvara finns allt från val av operativsystem, filsystem och versioner av program som används under studien som kan påverka resultatet. Resultaten från de två olika mätprogrammen kommer inte att kunna jämföras mot varandra på grund av att de mäter på olika sätt. Istället presenterar studien resultaten från de två olika mätprogrammen som validering till vilken konfiguration som visar bäst prestanda. Ett faktor som kan påverka prestandan är avsaknaden av SATA III på den dator som används under testerna. Då SSD-enheterna använder sig av SATA III och datorn enbart har stöd för SATA II, kan begränsningen [35] på 300MB/s för SATA II göra att SSD-enheten inte kan prestera lika bra som specifikationerna [31] säger. 10

4 Resultat En sammanställning av resultaten från testerna i sql-bench presenteras i en tabell för varje scenario, och digram med jämförelse mellan de olika scenariona kan ses under analys. Eftersom resultaten för mysqlslap inte är lika ingående som sql-bench, visas samtliga scenarion från mysqlslap i ett diagram. 4.1 Mätresultat för sql-bench Resultaten som ges av sql-bench presenteras här i tabeller, en för varje scenario. Tabellerna visar hur många sekunder det tog att genomföra varje test. De fullständiga resultaten från samtliga tester med sql-bench hittas i bilaga 1. I konfigurationen med en ensam hårddisk tog testerna längst tid att genomföra. Scenario 1 Databas på hårddisk alter-table 41,0 ATIS 38,3 big-tables 17,7 connect 160,0 create 300,7 insert 1834,3 select 695,3 transactions - wisconsin 16,0 Tabell 4.1 Tid det tar att genomföra varje test, i sekunder. I Tabell 4.2 visas resultatet en ensam SSD-enhet. Testet alter-table, som utför ändringar mot databasen, presterade nära dubbelt så bra jämfört med ovanstående konfiguration. ATIS-testet skapar ett mindre antal tabeller som den sedan gör en många SELECT-kommandon mot. Även ATIS-testet visar nära dubbla prestandan jämfört med enbart en ensam hårddisk. Testet big-tables, som testar hur bra databasen presterar när stora tabeller med mycket data skapas, visar marginellt bättre prestanda jämfört med en ensam hårddisk. Testet connet tar här 93 sekunder att genomföra, vilket är det bästa av samtliga konfigurationer. Det resultat som skiljer sig mest från samtliga andra konfigurationer är det från create-testet, som skapar och sedan tar bort tabeller. När en SSD används som primär lagring för databasen tar det ca 80 sekunder att genomföra detta test, jämfört med ca 300 sekunder för en ensam hårddisk. Resultatet från testet insert skiljer sig också markant mellan konfigurationerna, där det får bäst resultat när en SSD används som primär lagring. Select-testet visar ingen större skillnad mellan de olika konfigurationerna. Wisconsin-testet som är en port av PostgreSQL-versionen av denna benchmark, visar ingen markant skillnad mellan konfigurationerna, bortsett från en ensam hårddisk, där det presterade något sämre än övriga konfigurationer. 11

Scenario 2 Databas på SDD alter-table 21,0 ATIS 23,7 big-tables 13,0 connect 93,0 create 79,7 insert 1299,0 select 445,7 transactions - wisconsin 12,3 Tabell 4.1 Tid det tar att genomföra varje test, i sekunder. När ZIL och L2ARC används ihop med den primära mekaniska lagringen presterar systemet likvärdigt med en ensam SSD i majoriteten av testerna, eftersom SSDcachen i ZFS tar hand om nästan all data. De resultaten som skiljer sig mest här är connect som tar ca 133 sekunder att genomföra jämfört med databasen på en SSD där testet tar 93 sekunder att genomföra. Scenario 3 - ZIL & L2ARC alter-table 20,0 ATIS 23,7 big-tables 13,3 connect 133,3 create 77,0 insert 1302,0 select 446,0 transactions - wisconsin 12,0 Tabell 4.2 Tid det tar att genomföra varje test, i sekunder. När transaktionsloggen för MySQL sparades på en SSD, kunde flertalet testet utföras snabbare än en mekanisk hårddisk, men långsammare än både ZIL & L2ARC och ensam SSD. Detta kan ses i testet create, som presterar ungefär likvärdigt med scenario 1. Testet alter-table får ett resultat som placeras mellan scenario 1 och övriga två. Scenario 4 Transaktionslogg på SSD alter-table 30,0 ATIS 23,7 big-tables 13,0 connect 132,3 create 297,3 insert 1317,0 select 440,7 transactions - wisconsin 13,0 Tabell 4.3 Tid det tar att genomföra varje test, i sekunder. 12

4.2 Mätresultat för mysqlslap Det slutliga resultatet för mätningarna med mysqlslap är ett medelvärde av de tre olika tester som gjorts i varje scenario. De fullständiga resultaten från samtliga tester med mysqlslap hittas i bilaga 2. Resultaten visar att när transaktionsloggen placeras på en SSD-enhet tar det genast ytterligare 112 sekunder för 100 klienter att tillsammans göra 50 000 förfrågningar mot databasen. När databasen är placerad på en SSD uppnås den bästa prestandan, men inte långt där efter kommer SSD-cachen iform av ZIL & L2ARC. När databasen är placerad på en hårddisk syns en prestanda som är marginellt sämre än en SSD-cache. 1353,14 1223,51 1229,43 1241,62 LOG on SSD SSD ZIL & L2ARC HDD 1150 1200 1250 1300 1350 1400 Tid i sekunder (lägre är bättre) Figur 4.1: 50 000 förfrågningar uppdelat på 100 klienter 13

5 Analys Genom resultaten som har presenteras i kapitel 4.1 kan man konstatera att scenario 2 - Databas på SSD och scenario 3 ZIL & L2ARC visar övergripande bättre prestanda än resterande scenarier. De två scenarierna visade snarlika reslutat genom alla tester, detta kan bero på att SSD-cachen under scenariot 3 ZIL & L2ARC inte belastades tillräckligt under testerna för att tvinga den att använda sig av hårddisken under testerna. Detta leder till att alla tester som mätprogrammen genomförde gjordes bara mot SSD-cachen. Scenario 1 Databas på hårddisk visar överlag sämst prestanda genom alla tester. Under operationen insert i sql-bench visar resultaten störst skillnad i jämförelse med de andra scenarierna. Scenario 1 Databas på hårddisk visar ett resultat som är ca 70 % sämre än övriga scenarier under operationen insert. Under operationerna ATIS, big-tables, instert, wisconsin och select som sql-bench utförde gjordes det en anmärkning till att alla scenarierna med SSD-enheter i sin konfiguration visade snarlika resultat. Resultaten från mysqlslap visar att scenario 2 Databas på SSD presterar bäst och med liten marginal kommer scenario 3 ZIL & L2ARC tvåa. Märkbart under det här testet är resultatet som scenario 4 Transaktionslogg på SSD presenterar. Det förblir oklart till varför det scenariot visade betydligt sämre reslutat än övriga scenarion. 5.1 Analys av sql-bench Testet som utför ändring av tabeller visar att när databasen är placerad på en SSD visar det ett likvärdigt resultat som scenariot med ZIL & L2ARC, där det bara skiljer en sekund mellan de två. De två scenarierna visar ett resultat som är ca 49 % snabbare än det sämst presterande scenariot, databas på hårddisk. Scenariot med transaktionsloggen på en SSD visar ett resultat som hamnar i mitten mellan det bästa och det sämsta resultatet. 30 alter-table 20 21 41 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 10 20 30 40 50 Figur 5.1: Jämförelse mellan konfigurationer i testet alter-table 14

Testet ATIS skapar 29 tabeller och utför en större mängd select-förfrågningar på dessa. När databasen är placerad på en hårddisk visas ett resultat som är ca 62 % sämre än övriga scenarion. Under detta test visar alla scenarion med SSD-enheter i sin konfiguration samma resultat, även det med transaktionsloggen på en SSD. 23,7 ATIS 23,7 23,7 38,3 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 10 20 30 40 50 Figur 5.2: Jämförelse mellan konfigurationer i testet ATIS Under testet som skapar stora tabeller visar alla scenarier med SSD-enheter i sin konfiguration snarlika resultat. Scenariot med databasen på en hårddisk visar ett resultat som är ungefär fyra sekunder långsammare än de bästa scenarierna. 13 big-tables 13,3 13 17,7 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 5 10 15 20 Figur 5.3: Jämförelse mellan konfigurationer i testet big-tables Testet connect testar hastigheten på anslutningar mot databasen. Här visar scenario 2, med databasen på en SSD överlägset bäst resultat och visar ca 58 % bättre resultat än scenariot med databasen på en hårddisk, som visar sämst resultat av alla. Ungefär i mitten lägger sig scenariot med ZIL & L2ARC och scenario 4, med transaktionsloggen på en SSD. 15

132,3 connect 93 133,3 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD 160 Databas på hårddisk 0 50 100 150 200 Figur 5.4: Jämförelse mellan konfigurationer i testet connect Testet create skapar tabeller och sedan raderar de. Här visar scenariot med databasen på en SSD och scenariot med ZIL & L2ARC överlägset bättre resultat än resterande scenarier. ZIL & L2ARC visar ca 26 % bättre resultat än det lägst presterande som är scenariot med databasen på en hårddisk. Anmärkningsvärt under denna operation är att scenariot med transaktionsloggen på en SSD visar ett resultat som är snarlikt scenariot med databasen på en hårddisk. En anledning till detta kan vara att databasen inte använder sig av transaktionsloggen vid utförandet av operationen create. 297,3 create 77 79,7 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD 300,7 Databas på hårddisk 0 100 200 300 400 Figur 5.5: Jämförelse mellan konfigurationer i testet create Testet insert skapar en tabell och infogar data i den. Alla scenarier med SSD-enheter i konfigurationen visar snarlika resultat. När databasen är placerad på en hårddisk visar resultaten att prestandan är ungefär 71 % sämre än det bästa resultatet som sker 16

när databasen är placerad på en SSD. Anmärkningsvärt är att skillnaden mellan det bästa och sämsta resultatet är som störst under detta test. 1317 insert 1302 1299 1834,3 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 500 1000 1500 2000 Figur 5.6: Jämförelse mellan konfigurationer i testet insert Testet select utför select-kommandon. Alla scenarier med SSD-enheter i konfigurationen visar snarlika resultat. Scenariot med databasen på en hårddisk visar ett resultat som är ca 63 % sämre än det bästa resultatet som är scenario 4 med transaktionsloggen på en SSD. 440,7 select 446 445,7 695,3 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 200 400 600 800 Figur 5.7: Jämförelse mellan konfigurationer i testet select Testet wisconsin utför skapandet av tabeller och infogar data i dem. Scenariot med ZIL & L2ARC visar bäst resultat, men skiljer sig inte märkvärt med övriga scenarier som använder sig SSD-enheter i sin konfiguration. Scenariot databasen på en hårddisk visar ett resultat som är ca fyra sekunder långsammare än det bäst presterande. 17

wisconsin 12 13 12,3 16 Transaktionslogg på SSD ZIL & L2ARC Databas på SSD Databas på hårddisk 0 5 10 15 20 Figur 5.8: Jämförelse mellan konfigurationer i testet wisconsin 18

6 Diskussion Denna uppsats har haft en frågeställning som under hela arbetet legat till grund för samtliga scenarion och dess tester. Detta kapitel kommer diskutera helheten av arbetet. Det finns även en reflektion kring den metod som har präglat arbetet, för att se vad som kan ha påverkat resultaten. 6.1 Resultat Eftersom alla scenarion som Ioannis och Stratis [1] nämner inte har inkluderats i denna studie, kan slutsatsen enbart ses som ett delresultat av alla möjliga. Om fler konfigurationer inkluderats i studien kan resultaten sett annorlunda ut. Våra resultat visade att en SSD-cache i ZFS (ZIL & L2ARC) och en ensamstående SSD-enhet presterar likvärdigt, i större delen av testerna. I vissa fall även marginellt snabbare, dock inget man ska dra några slutsatser över, då det alltid finns en viss felmarginal. På grund av en begränsad mängd på antalet förfrågningar i testerna är det inte säkert att SSD-cachen inte belastats till fullo. Eftersom SSD-enheterna som används har en relativt hög kapacitet, på 60GB är det troligt testerna inte genererar tillräckligt med data för att fylla SSD-enheterna. Om enheterna som används som cache haft en mindre kapacitet är det möjligt att resultaten sett annorlunda ut om någon av enheterna som används som cache får slut på utrymme, tvingas ny data skrivas eller läsas direkt från hårddisken istället, och kommer då påverka prestandan negativt. Under testerna med sql-bench genererades inga resultat för transaktioner. Vad det kunde bero på hittade vi då aldrig något svar på. På grund av begränsade tidsramar valde vi istället att fortsätta med testerna, utan resultat för transaktioner. Senare läste vi på MySQLs hemsida [31], att en möjlig anledning till avsaknaden av resultat från transaktioner kan bero på att den databas-motorn som används som standard i MySQL (MyISAM) ej har stöd för transaktioner. Då återstod två alternativ för oss, antingen göra om samtliga tester med sql-bench, och där använda databas-motorn InnoDB som enligt [31] har stöd för transaktioner. Med tanke på den tid som återstod valde vi att istället inkludera InnoDB i testerna för sqlslap för att få med resultat för transaktioner där. MySQL använder RAM-minnet för cache, för att minska hårddiskanvändningen, då hårddiskar är väldigt mycket långsammare än RAM-minne [30]. Då denna undersökningen enbart gjorts med standard-inställningar har inte någon konfiguration gjorts för detta. Om RAM används som cache kan det påverkat testerna, men eftersom samma inställningar används i samliga tester är detta inget problem, anser vi. 6.2 Metodreflektion För att öka trovärdigheten för testerna med mysqlslap, kunde fler testet utförts med olika många förfrågningar. Det är möjligt att SSD-cache presterar bäst, tills att ett visst nummer av förfrågningar uppnås. Det vore intressant att veta när detta tröskelvärde uppnås. 19

7 Avslutning Denna studie har fokuserat på hur SSD-enheter utnyttjas bäst i en databas-server. Tidigare forskning nämner olika konfigurationssätt som SSD-enheter kan implementeras in i en databas-server, men de visar inte upp några prestandaresultat kring de olika konfigurationerna. Syftet har varit att utföra prestandatester och jämföra de olika konfigurationerna som tidigare forskning tar upp, detta för att få en klar bild av skillnaderna. Arbetet har visat hur prestandan mellan databas på hårddisk, databas på SSD, databas med SSD-cache och transaktionsloggen på en SSD skiljer sig. Resultaten för de olika konfigurationerna togs fram med hjälp av mätprogrammen sql-bench och mysqlslap. Med alla faktorer som kan påverka prestandan som en databas har är det inte säkert att samma resultat uppstår med annorlunda hårdvara. 7.1 Slutsats Med hjälp av prestandamätningarna kan vi dra slutsatsen att under den miljö där mätningarna gjorts presterar en databas på en enskild SSD lika bra som en databas med SSD-cache under majoriteten av mätningarna och visar bättre resultat än de resterande konfigurationerna som var en databas på hårddisk och transaktionsloggen på en SSD. 7.2 Förslag till fortsatt forskning Denna studie presenterar delresultat av de sex olika konfigurationerna som författarna bakom artikeln Data Mangement Over Flash Memory tar upp, förslag till forsatt forskning inom området kan vara att utföra prestandatester på resterande konfigurationer [1] som inte denna studie tar upp. Ett annat alternativ är att undersöka prestandan för MySQL mot en annan databashanterare i samma experimentmiljö som denna studie har. En jämförelse mellan operativsystemen Openindiana och FreeBSD skulle också vara intressant och se hur mycket valet av operativsystem påverkar resultaten. För att se hur MySQL presterar under olika mycket belastning, kan flera tester med mysqlslap köras och där olika många förfrågningar. Genom att göra flera mätningar med olika mycket belastning går det också se ifall prestandan håller sig i linje med den belastning som ges. 20

Referenser [1] I. Koltsidas and S. Viglas, Data Management Over Flash Memory, 2011. [2] MySQL :: Why MySQL. Tillgänglig: http://www.mysql.com/why-mysql/ [Hämtad: 2012-04-17] [3] MySQL :: Market Share. Tillgänglig: http://www.mysql.com/whymysql/marketshare/ [Hämtad: 2012-04-17] [4] Hardware and Software Requirements for Installing SQL Server 2012. Tillgänglig: http://msdn.microsoft.com/en-us/library/ms143506.aspx [Hämtad: 2012-04-17] [5] Oracle Solaris 11 ZFS Technology. Tillgänglig: http://www.oracle.com/technetwork/server-storage/solaris11/technologies/zfs- 338092.html [Hämtad: 2012-04-17] [6] Oracle SQL Developer License Terms. Tillgänglig: http://www.oracle.com/technetwork/licenses/sqldev-license-152021.html [Hämtad: 2012-04-17] [7] MySQL :: MySQL 5.1 Reference Manual :: 8.1.3 The MySQL Benchmark Suite. Tillgänglig: http://dev.mysql.com/doc/refman/5.1/en/mysql-benchmarks.html [Hämtad: 2012-04-25] [8] T. Bourke, Super Smack. Tony Bourke. Tillgänglig: http://supersmack.com/ [Hämtad: 2012-04-25] [9] N. Solter et al., OpenSolaris Bible, John Wiley & Sons, 21 Mars 2011 [10] Setting Up Separate ZFS Log Devices. Tillgänglig: http://docs.oracle.com/cd/e19253-01/819-5461/6n7ht6qs6/index.html#indexterm-1 [Hämtad: 2012-05-04] [11] M. Naghibzadeh, Operating System: Concepts And Techniques, iuniverse, Inc.,8 December 2005 [12] OpenIndiana Frequently Asked Questions. Tillgänglig: http://wiki.openindiana.org/oi/frequently+asked+questions/ [Hämtad: 2012-05-09] [13] Tomshardware :Data Transfer Rates. Tillgänglig: http://www.tomshardware.com/reviews/understanding-hard-driveperformance,1557-10.html [Hämtad: 2012-05-31] [14] B. Stuart, Principles of Operating Systems: Design & Applications, Course Technology; 1 edition, 15 January 2008 21

[15] K. Kim och S. Ahn, Operating System: Concepts And Techniques, Springer; 2012 edition, 7 December 2011 [16] C. Coronel et al., Database Systems: Design, Implementation, and Management, Course Technology; 9 edition, 20 November 2009 [17] MySQL :: MySQL 5.1 Reference Manual :: 1.3.1 What is MySQL. Tillgänglig: http://dev.mysql.com/doc/refman/5.1/en/what-is-mysql.html [Hämtad: 2012-05-04] [18] L. Ullman, MySQL, Second Edition, Peachpit Press; 2 edition, 20 May 2006 [19] Hardware and Software. Engineered to Work Together. Tillgänglig: http://www.oracle.com/us/sun/index.htm [Hämtad: 2012-05-04] [20] Y. Zhang, et al., End-to-end data integrity for file systems: a ZFS case study, FAST'10 Proceedings of the 8th USENIX conference on File and storage technologies, USENIX Association Berkeley, CA, USA [21] S. Piramanayagam och T. Chong Developments in Data Storage: Materials Perspective, Wiley-IEEE Press; 1 edition, 8 November 2011 [22] J. Bonwick et al., The Zettabyte File System 2006 [23] V. Vaswani, MySQL(TM): The Complete Reference, McGraw-Hill Osborne Media; 1 edition, 18 December 2003 [24] The Binary Log. Tillgänglig: http://dev.mysql.com/doc/refman/5.5/en/binarylog.html [Hämtad: 2012-05-05] [25] mysqlslap - Load Emulation Client. Tillgänglig: http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html [Hämtad: 2012-05-05] [26] The Zettabyte File System. Tillgänglig: http://ipv6.jbowdenassociates.com/docs/solaris/zfs_overview.pdf [Hämtad: 2012-05-05] [27] J. Stanik A Conversation with Jeff Bonwick and Bill Moore, 2007. Tillgänglig: http://dl.acm.org/citation.cfm?id=1317394.1317400&coll=dl&dl=acm&cfid=80 686937&CFTOKEN=40211008 [28] About ZFS Storage Caches. Tillgänglig: http://docs.oracle.com/html/e26092_01/storage-write-cache.html [Hämtad: 2012-05-05] [29] Oracle Buys Sun. Tillgänglig: http://www.oracle.com/us/corporate/press/018363 [Hämtad: 2012-05-15] 22

[30] B. Schwart, et.al., High Performance MySQL O'Reilly Media; 2 edition, 25 Juni 2008 [31] OCZ Agility 3 SATA III 2.5" SSD: Specifications. Tillgänglig: http://www.ocztechnology.com/ocz-agility-3-sata-iii-2-5-ssd.html [Hämtad: 2012-05-31] [32] MySQL :: MySQL 5.1 Reference Manual :: Storage Engines. Tillgänglig: http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html [Hämtad: 2012-06-04] [33] MySQL :: MySQL 5.1 Reference Manual :: 13. SQL Statement Syntax: http://dev.mysql.com/doc/refman/5.1/en/sql-syntax.html [Hämtad: 2012-06- 04] [34] J. Backman, Rapporter och Uppsatser. Studentlitteratur, 2008 [35] Serial ATA International Organization. Tillgänglig: http://www.sataio.org/documents/sataenglishbrochure_final_000.pdf [Hämtad: 2012-06-04] 23

Bilagor Bilaga 1: Resultat från sql-bench Benchmark DBD suite: 2.15 Date of test: 2012-05-09 19:48:47 Running tests on: SunOS 5.11 i86pc Arguments: Comments: Hårddisk test1 Limits from: Server version: MySQL 5.1.62/ Optimization: None Hardware: alter-table: Total time: 41 wallclock secs ( 0.09 usr 0.07 sys + 0.00 cusr 0.00 csys = 0.16 ATIS: Total time: 46 wallclock secs ( 2.46 usr 0.54 sys + 0.00 cusr 0.00 csys = 3.00 big-tables: Total time: 19 wallclock secs ( 5.42 usr 0.37 sys + 0.00 cusr 0.00 csys = 5.79 connect: Total time: 173 wallclock secs (43.51 usr 26.27 sys + 0.00 cusr 0.00 csys = 69.78 create: Total time: 307 wallclock secs ( 4.87 usr 2.58 sys + 0.00 cusr 0.00 csys = 7.45 insert: Total time: 2067 wallclock secs (326.99 usr 86.44 sys + 0.00 cusr 0.00 csys = 413.43 select: Total time: 828 wallclock secs (23.44 usr 5.02 sys + 0.00 cusr 0.00 csys = 28.46 transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 17 wallclock secs ( 1.81 usr 0.93 sys + 0.00 cusr 0.00 csys = 2.74 All 9 test executed successfully Totals per operation: Operation seconds usr sys cpu tests alter_table_add 18.00 0.02 0.01 0.03 100 alter_table_drop 17.00 0.02 0.01 0.03 91 connect 15.00 6.74 3.17 9.91 10000 connect+select_1_row 20.00 9.28 4.24 13.52 10000 connect+select_simple 17.00 7.36 3.71 11.07 10000 count 7.00 0.03 0.00 0.03 100 count_distinct 23.00 0.15 0.03 0.18 1000 count_distinct_2 18.00 0.14 0.04 0.18 1000 count_distinct_big 19.00 1.43 0.02 1.45 120 count_distinct_group 17.00 0.42 0.04 0.46 1000 count_distinct_group_on_key 28.00 0.17 0.03 0.20 1000 count_distinct_group_on_key_parts 19.00 0.36 0.05 0.41 1000 count_distinct_key_prefix 23.00 0.13 0.03 0.16 1000 count_group_on_key_parts 30.00 0.36 0.04 0.40 1000 count_on_key 337.00 5.75 1.42 7.17 50100 create+drop 95.00 1.55 0.79 2.34 10000 create_many_tables 103.00 1.21 0.42 1.63 10000 24

create_index 3.00 0.00 0.00 0.00 8 create_key+drop 98.00 1.45 0.71 2.16 10000 create_table 0.00 0.00 0.00 0.00 31 delete_all_many_keys 167.00 0.01 0.01 0.02 1 delete_big 0.00 0.00 0.01 0.01 1 delete_big_many_keys 167.00 0.01 0.01 0.02 128 delete_key 3.00 0.19 0.20 0.39 10000 delete_range 31.00 0.00 0.00 0.00 12 drop_index 3.00 0.00 0.00 0.00 8 drop_table 0.00 0.00 0.00 0.00 28 drop_table_when_many_tables 5.00 0.29 0.32 0.61 10000 insert 131.00 8.88 8.94 17.82 350768 insert_duplicates 28.00 3.75 3.34 7.09 100000 insert_key 204.00 4.83 2.79 7.62 100000 insert_many_fields 4.00 0.25 0.08 0.33 2000 insert_select_1_key 11.00 0.00 0.00 0.00 1 insert_select_2_keys 9.00 0.00 0.00 0.00 1 min_max 9.00 0.01 0.00 0.01 60 min_max_on_key 30.00 12.02 2.95 14.97 85000 multiple_value_insert 2.00 0.28 0.02 0.30 100000 once_prepared_select 38.00 4.91 2.70 7.61 100000 order_by_big 13.00 4.52 0.16 4.68 10 order_by_big_key 14.00 5.63 0.30 5.93 10 order_by_big_key2 12.00 5.94 0.21 6.15 10 order_by_big_key_desc 15.00 8.03 0.34 8.37 10 order_by_big_key_diff 10.00 6.06 0.15 6.21 10 order_by_big_key_prefix 12.00 5.73 0.20 5.93 10 order_by_key2_diff 6.00 0.40 0.03 0.43 500 order_by_key_prefix 3.00 0.45 0.03 0.48 500 order_by_range 3.00 0.31 0.03 0.34 500 outer_join 82.00 0.00 0.00 0.00 10 outer_join_found 74.00 0.01 0.00 0.01 10 outer_join_not_found 42.00 0.00 0.00 0.00 500 outer_join_on_key 38.00 0.01 0.00 0.01 10 prepared_select 49.00 15.33 3.90 19.23 100000 select_1_row 22.00 3.33 2.48 5.81 100000 select_1_row_cache 21.00 2.57 2.16 4.73 100000 select_2_rows 25.00 3.27 2.37 5.64 100000 select_big 12.00 8.24 0.26 8.50 80 select_big_str 7.00 3.07 1.37 4.44 10000 select_cache 113.00 1.28 0.32 1.60 10000 select_cache2 124.00 1.15 0.30 1.45 10000 select_column+column 20.00 2.32 1.98 4.30 100000 select_diff_key 1.00 0.07 0.01 0.08 500 select_distinct 11.00 0.42 0.05 0.47 800 select_group 47.00 0.49 0.09 0.58 2911 select_group_when_many_tables 6.00 0.37 0.34 0.71 10000 select_join 3.00 0.19 0.03 0.22 100 select_key 87.00 38.55 8.48 47.03 200000 select_key2 94.00 36.39 8.31 44.70 200000 select_key2_return_key 87.00 35.66 8.26 43.92 200000 select_key2_return_prim 91.00 36.04 8.18 44.22 200000 select_key_prefix 95.00 36.45 8.15 44.60 200000 25