1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Autonomic Benchmarking Szombath István Autonóm és hibatűrő.

Az előadások a következő témára: "1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Autonomic Benchmarking Szombath István Autonóm és hibatűrő."— Előadás másolata:

1 1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Autonomic Benchmarking Szombath István Autonóm és hibatűrő informatikai rendszerek

2 2 Benchmarking  Célok: szoftver/hardver eszközök teljesítményének összehasonlítása o Döntéstámogatás melyiket előnyösebb megvenni/telepíteni mekkora terhelésre elég a meglévő rendszer o Teljesítménytesztelés kell-e még teljesítményen javítani és hol (fejlesztésnél) optimális-e egy konkrét beállítás van-e egy beállításnak teljesítményre gyakorolt hatása

3 3  Specifikáció o hardver o szoftver o üzemviszonyok o ütemezés o dokumentáció  Alapelvek o kölcsönös zavarás minimalizálása (üzem közben) o Pareto elv (80/20) kihasználása o prekoncepció (mit mérünk) o terhelés közelítse a valós mintát (profilok) Bechmark környezet

4 4  Tudományos/műszaki rendszerek o nagy mennyiségű adat feldolgozása (number crunching) o párhuzamos módszerek  Tranzakciókezelés (OLTP) o kliens-szerver környezet o sok gyors, párhuzamos tranzakció  Batch jellegű adatfeldolgozás o riport készítés nagy mennyiségű adatból  Döntéstámogatás o kevés, bonyolult lekérdezés o ad hoc műveletek o sok adat (pl. OLAP )  Virtualizáció Benchmark terhelési modellek

5 5  OLTP architektúra példa (táblánál) Benchmark terhelési modellek példa

6 6 Mérendő paraméterek (Metrikák)  Futási idő o kezdet, vég? o eloszlás o CPU, I/O, hálózat,…  Tranzakiósebesség o rendszer reakcióideje o akár egymásba ágyazott tranzakciók  Áteresztőképesség o feldolgozott adatmennyiség / futási idő o terhelés függvényében

7 7 Mérendő paraméterek (2)  Válaszidő o terhelés függvényében felhasználók tranzakciók száma, stb.  X-Percentil o Egy adott halmaz X százaléka ez alatt az érték alatt van

8 8 Eredmények összehasonlítása  Pl. referenciarendszer alapján  Több paraméter alapján ellentmondást kaphatunk  Absztrakt referencia („standard benchmark”)  Adatbányászati módszerek  Nincs egy univerzális teljesítménymérő metrika még egy- egy szűkebb területen belül sem!

9 9 Tipikus problémák  Túl kicsi problémaméret  A felhasználási terület számára releváns eredmény?  Elavult referenciák  „Rejtett” paraméterek o konfigurációs beállítások o adott környezet specifikus tulajdonságai  Elfogultság  Hiányos specifikáció

10 10 Benchmark típusok  Tudományos terminológia o Macrobenchmark – nagy összetett alkalmazás mérése relevancia biztosításával közvetlenül használható eredményeket ad o Microbenchmark – alkalmazás kis részének kiemelt, analitikus mérése analitikus felhasználás, profiling, teljesítmény előrejelzés o Nanobenchmark – egy-egy atomi művelet teljesítményének elkülönített mérése főleg hibakeresés, profiling célra hasznos

11 11 Benchmark elvégzése  Relevancia biztosítása o Tényleg azt az alkalmazást mérjük, amit kell Különböző macrobenchmarkok eredményei többnyire nem vihetőek át egymás között. o Terhelésgenerálás jellege közelítse a valódi terhelést Főleg macrobenchmarkoknál fontos, időben szétosztott valódi terhelést félrevezető lehet egy összefüggő batch terheléssel helyettesíteni. Ügyeljünk a terhelésgenerátorra ható visszacsatolásokra o Minimalizáljuk a zavaró tényezőket Főleg microbenchmarknál fontos, Pl.: ne mérjünk bele véletlenül diszk I/O-t a memória áteresztőképességébe, ne fusson más alkalmazás közben Futási eredmények szórását kezelni kell

12 12 Eredmény analitikus felhasználása  Cél: következtetünk jövőbeli (tehát nem mérhető) terhelésnél kapott eredményre A A B B C C D D Összetett alkalmazás Egyes részfeladatok aránya ismert (vagy legalább jól becsülhető) a terhelés során Eredmények részfeladatonkénti microbenchmarkra: ABCDABCD Becsült teljesítmény

13 13 SPEC benchmarkok  http://www.spec.org/benchmarks.html  Standard Performance Evaluation Corp.  Erőforrás és alkalmazás szintű benchmarkok o CPU o Alkalmazások o Levelező szerverek o Web szerverek o Network File System, stb.  Benchmark: megrendelhető szolgáltatás o Forráskódot adnak, nekünk kell fordítani o Licensz díjas!

14 14 SPEC CPU2006  CPU intenzív  CINT2006 o Számításigényes egész számos  CFP2006 o Lebegőpontos  Példa:

15 15 CINT2006 és CFP2006 terhelésgenerátorok 400.perlbenchCProgramming Language 401.bzip2CCompression 403.gccCC Compiler 429.mcfCCombinatorial Optimization 445.gobmkCArtificial Intelligence 456.hmmerCSearch Gene Sequence 458.sjengCArtificial Intelligence 462.libquantumCPhysics / Quantum Computing 464.h264refCVideo Compression 471.omnetppC++Discrete Event Simulation 473.astarC++Path-finding Algorithms 483.xalancbmkC++XML Processing  CFP2006:  CINT2006 :

16 16 SPECweb2009  Terhelés: o Biztonságos bankolás (SSL) o E-kereskedelem (SSL+ http letöltés pl) o Áteresztőképesség o Teljesítmény / energia metrikák  Architektúra (ábra)  Terhelésgenerálás (ábra)  Példa:

17 17 SPECweb2009

18 18 SPECjAppServer2004  Html oldal elemzése előadáson Html  J2EE Benchmark o Alkalmazásszerver skálázhatósága és teljesítménye  Architektúra (több szerveres, kliens - szerver arch.)  Metrika: o Áteresztő- képesség  Terhelés: o Autógyártás o Gyár – megrendelők o Autókatalógus

19 19 SPECjvm2008  Ingyenes!  JRE teljesytémény o CPU / memória o Kevés fájl I/O, nincs hálózati I/O  Alkalmazások o Javac o LZW o Startup o MPEGaudio o Xml (transzformáció és validáció) o Crypto Aes, rsa, signverify

20 20 SPECvirt_sc2010  Szerverek 18%-a volt virtualizált 2009q4-ben  Cél: skálázhatóság / energiahatékonyság o Hány VM konszolidálható egy HW-re  Architektúra (ld. ábra) o 1 „tile” 6 VM o Függőségek!  Terhelés o Tile-ok számát növeli o Amíg QoS megvan, vagy amíg a metrikák már nem nőnek  Metrika o Szubkomponensek normalizált metrikái o Pl kérés/s a webszerveren, alkalmazásszerver burstössége

21 21 SPECvirt_sc2010

22 22 SPECvirt_sc2010

23 23 TPC benchmarkok  http://www.tpc.org/information/benchmarks.asp  Transaction Processing Council  TPC-C (elektronikus kereskedelem, banki rendszer): o felhasználók tranzakciókat hajtanak végre o rendelés/lemondás, lekérdezés, stb. o szervereket hasonlít össze HW OS DBMS egyéb paraméterek: – tervezett rendelkezésre állás, elérhetőség (pl. 24/7 vs. 8/5) o OLTP rendszerek mérőszámai: tranzakciós ráta (tpmC): 5 különböző fajta tranzakció alapján ár / tranzakció ($/tpmC): fenntartási költségek / tranzakciók o Bővebben: info itt, pdf itt.itt

24 24 TPC-CWarehouseW Legend Table Name <cardinality> one-to-manyrelationship secondary index DistrictW*10 10 CustomerW*30K 3K HistoryW*30K+ 1+ Item 100K (fixed) StockW*100K 100K W OrderW*30K+ 1+ Order-LineW*300K+ 10-15 New-OrderW*5K 0-1

25 25 TPC-W  TPC-W (Web e-Commerce rendszerek): o komplex rendszereket hasonlít össze különféle szerverek összekapcsolása o dinamikus oldalak o 3 különböző profil vizsgálata rendelés gyakorisága különböző o szimulált terhelés o könyvesbolt a mintarendszer bejelentkezés, bevásárlókocsi, online rendelés hitelkártya információ külső szolgáltatótól (Payment Gateway) böngészőből elérhető

26 26 TPC-W konfiguráció

27 27 TPC-W mérés  Emulált kliensek  Konfiguráció o „gondolkodási idő”, átlag 7 sec, max. 70 sec o döntési valószínűségek (Web Interaction Mix) o válaszidő követelmények o új / régi felhasználók (regisztrálás, cache) o felhasználók száma (Number of Users)  Scale factor: o könyvek száma az adatbázisban, 1000…10,000,000  Átlagos vagy Worst Case értékek

28 28  Előnyök o komplex rendszer tesztelés o valós viszonyok terheléskiegyenlítés a Web szerverek közt külön Image szerver Web cache használata  Hátrányok: o nem valós alkalmazást használ alacsony szinten van kódolva o túl egyszerű lekérdezéseket használ o kevés kép/oldal van a mintarendszerben ezért tiltja a cache-t az emulált böngészőben TPC-W tulajdonságai forrás: Wayne D. Smith: TPC-W: Benchmarking An Ecommerce Solution http://www.tpc.org/tpcw/TPC-W_Wh.pdf

29 29 TPC-App (TPC-W 2.0)  Alkalmazás szerver és Web szerver együttes mérése  TPC-W utóda  Kereskedelmi alkalmazások o B2B is o Webszolgáltatások o Sokféle tranzakció egyszerre  Alap metrika: SIPS o Web Service Interactions Per Second  SIRT: Web Service Interaciton Response Time

30 30 TPC-App konfiguráció Remote Business Emulator Üzleti funkciók megjelenítése Külső szolgáltatók Adatbázis „Üzleti logika” megvalósítása System Under Test

31 31 TPC-App környezet  Külső szolgáltatások o Purchase Order Validation Emulator o Payment Gateway Emulator o Inventory Control Emulator o Shipment Notification Emulator  Tesztelési paraméterek o ACID adatbáziskezelés o Configured EBs (felhasználók száma) o Active EBs (párhuzamosan belépett felhasználók száma) (0.9...1)*(Configured EBs)

32 32 TPC-App fizikai elrendezés

33 33 TPC-App egyéb követelmények  A használt műveletek aránya dokumentálandó  3 órás egyensúlyi állapot kell  SSL/TSL használata kötelező  ACID tulajdonságok o Izolációs tesztek  8 órányi log  60 napnyi üzemidőnek megfelelő tárhely állon rendelkezésre

34 34 VMark  Mindmap

35 35 Dependebility Benchmarking  Pdf – erre nem jutott idő 

36 36 The Autonomic Computing Benchmark  Nagyvállalati környezet „rugalmasságának” vizsgálata (resilience) o Self * mérése (önmenedzselés) o Hibainjektálással o A rendszer robosztusságát és automatizáltságát vizsgálja  Cél: kevés metrika o Rendszer evolúciójának vizsgálata o Különböző rsz-ek összehasonlítása

37 37 Architektúra  Elvben bármi lehet  Példa: SPECjAppServer2004 architektúra / benchmark o Webszerver o Alkalmazásszerver o Adatbázis o Üzenetküldő szerver

38 38 Metrikák  Áteresztőképesség index o Zavar hatása az áteresztőképességre  Fejlettség index (ld. később) o Emberi interakciók mennyiség hibadetektálás, hibaanalízis, helyreállás során

39 39 Mechanizmus  3 fázis: o Alap fázis o Tesztfázis o Ellenőrzés Konzisztencia ellenőrzése  Tesztfázist slotokra osztják o Egymás utáni slotokban hibákat injektálunk és azok hatását vizsgáljuk

40 40 Mechanizmus – 1 slot  Állandósult állapotba kerül a rendszer  Hibainjektálás  Hibadetektálás o Automatikus o Bizonyos idő elteltével (emberi interakció szimulálása)  Helyreállítás  Újraindítás  Rendszer futtatása o Degradálódott-e a szolgáltatás?

41 41 Hibafajták  Hibák (példa): o Váratlan leállás (hw, os, sw) o Erőforrás versenyhelyzet (CPU, mem) o Adatvesztés (file, DBMS) o Terhelésváltozás („karácsonyi roham”) o Sikertelen újraindítás detektálása

42 42 Metrikák (folyt)  Áteresztőképesség index: P_i / P_base o Figyelem! Nem rendelkezésre állás.  Fejlettség index o Kifejezi mennyire automatizált a rendszer o Mennyi emberi beavatkozás kell o A SUT egy lista alapján pontokat kap o Nemlineáris skála o Átlagolunk, normalizáljuk o Index 0—1 között 0 nincs automatizmus 1 nem kell emberi közbeavatkozás

43 43 Példa  Esettanulmány az órán  Ábrák elemzése a cikkből

44 44 Nehézségek  Zavar megtervezése o Zavarok katalógusának összegyűjtése o Szimuláció?  Eredmények összehasonlítása o Terhelés o Skálázódás a metrika nem skálázódik feltétlenül együtt a rendszermérettel o Ár Robosztus és automatizált rendszer nagyon költséges  Benchmark során: hum. interakció becslés!

45 45 DBench-OLTP Autonomic összehasonlítás  Dbench-OLTP  TPC-C alapú  Egy komponenst  Hiba hatása a rsz-re  Több metrika  Autonomic C. B  Bármilyen terhelés  SPECjAppServer2004  Több komponens akár  Hiba + fejlettségi index: emberi interakciók száma  Egy metrika