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

(1)

Examensarbete i datavetenskap

C-nivå

SSDs påverkan på MySQL

En prestandajämförelse

(2)

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

(3)

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

(4)

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.

(5)

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

(6)

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

(7)

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.

(8)

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 SSD- enheter 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 prestanda- på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.

(9)

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

(10)

hårddiskar ligger hastigheten på skivorna runt 7,200 varv i minuten, och har en läs- och 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 copy- on-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

(11)

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].

(12)

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.

(13)

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 SSH- klienten 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 SSD- diskar 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:

(14)

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 MySQL- tjä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

(15)

För att sedan MySQL ska spara all data på det nya filsystemet, stoppades MySQL- tjä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

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

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/.

(16)

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.

(17)

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.

(18)

Scenario 2 – Databas på SDD

ATIS 23,7

big-tables 13,0

connect 93,0

create 79,7

insert 1299,0

select 445,7

transactions -

wisconsin 12,3

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 SSD- cachen 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

ATIS 23,7

big-tables 13,3

connect 133,3

create 77,0

insert 1302,0

select 446,0

transactions -

wisconsin 12,0

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

ATIS 23,7

big-tables 13,0

connect 132,3

create 297,3

insert 1317,0

select 440,7

transactions -

wisconsin 13,0

(19)

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.

Figur 4.1: 50000 förfrågningar uppdelat på 100 klienter 1241,62

1229,43 1223,51

1353,14

1150 1200 1250 1300 1350 1400

Tid i sekunder (lägre är bättre)

LOG on SSD SSD ZIL & L2ARC HDD

(20)

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.

Figur 5.1: Jämförelse mellan konfigurationer i testet alter-table 41

21 20

30

0 10 20 30 40 50

alter-table

Transaktionslogg på SSD ZIL & L2ARC

Databas på SSD Databas på hårddisk

(21)

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.

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.

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.

38,3 23,7

23,7 23,7

0 10 20 30 40 50

ATIS

17,7 13

13,3 13

0 5 10 15 20

big-tables

(22)

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.

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

160 93

133,3 132,3

0 50 100 150 200

connect

300,7 79,7

77

297,3

0 100 200 300 400

create

(23)

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.

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.

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.

1834,3 1299

1302 1317

0 500 1000 1500 2000

insert

695,3 445,7

446 440,7

0 200 400 600 800

select

(24)

Figur 5.8: Jämförelse mellan konfigurationer i testet wisconsin 16

12,3 12

13

0 5 10 15 20

wisconsin

(25)

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 r

esultat 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.

(26)

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.

(27)

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/why- mysql/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-drive- performance,1557-10.html [Hämtad: 2012-05-31]

[14] B. Stuart, “Principles of Operating Systems: Design & Applications”, Course Technology; 1 edition, 15 January 2008

(28)

[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/binary- log.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]

(29)

[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.sata-

io.org/documents/sataenglishbrochure_final_000.pdf [Hämtad: 2012-06-04]

(30)

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 CPU)

ATIS: Total time: 46 wallclock secs ( 2.46 usr 0.54 sys + 0.00 cusr 0.00 csys = 3.00 CPU) big-tables: Total time: 19 wallclock secs ( 5.42 usr 0.37 sys + 0.00 cusr 0.00 csys = 5.79 CPU)

connect: Total time: 173 wallclock secs (43.51 usr 26.27 sys + 0.00 cusr 0.00 csys = 69.78 CPU)

create: Total time: 307 wallclock secs ( 4.87 usr 2.58 sys + 0.00 cusr 0.00 csys = 7.45 CPU)

insert: Total time: 2067 wallclock secs (326.99 usr 86.44 sys + 0.00 cusr 0.00 csys = 413.43 CPU)

select: Total time: 828 wallclock secs (23.44 usr 5.02 sys + 0.00 cusr 0.00 csys = 28.46 CPU)

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 CPU)

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

(31)

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

(32)

select_key_prefix_join 8.00 0.81 0.04 0.85 100

select_key_return_key 84.00 36.74 8.26 45.00 200000

select_many_fields 15.00 5.17 0.28 5.45 2000

select_range 84.00 2.31 0.05 2.36 410

select_range_key2 20.00 2.89 0.54 3.43 25010

select_range_prefix 19.00 3.10 0.58 3.68 25010

select_simple 13.00 2.66 2.24 4.90 100000

select_simple_cache 13.00 2.89 2.54 5.43 100000

select_simple_join 2.00 0.18 0.03 0.21 500

update_big 113.00 0.00 0.00 0.00 10

update_of_key 26.00 1.11 1.19 2.30 50000

update_of_key_big 50.00 0.01 0.01 0.02 501

update_of_primary_key_many_keys 43.00 0.01 0.01 0.02 256

update_with_key 93.00 7.01 7.88 14.89 300000

update_with_key_prefix 28.00 5.22 3.54 8.76 100000

wisc_benchmark 3.00 1.06 0.12 1.18 114

TOTALS 3602.00 405.45 121.93 527.38

3425950

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

Examensarbete i datavetenskap

C-nivå