LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> TPC-B test databází

Dneska provedeme TPC-B test databází přesně podle oficiálních TPC-B 2.0 pravidel

9.2.2011 00:00 | Radim Kolář | Články autora | přečteno 3804×

TPC-B test

Dneska provedeme TPC-B test na stejné hardware konfiguraci jako minule, ale budeme respektovat TPC-B pravidlo o škálování dat nad kterými je test prováděn. Dnešní naměřené výsledky již tak nebudou pouhé transakce za sekundu, ale budou to plnohodnotné tpsB jednotky.

Narozdíl od minulého 100 MB testu, který byl spíše rychlostní, je dnešní test zaměřen především na prověření škálovatelnosti databází. Testy by byly zajímavější kdybychom měli více než 2 GB paměti a mohli dodat databázím více bufferů. To bychom ale pak nemohli testovat objektivně Oracle XE, protože má maximální velikost SGA omezenou 1 GB. Jak uvidíme dál tak Oracle na našem testovacím HW stejně moc nepřekvapilo. U Oracle se předpokládá že ten kdo má na Oracle tak má také na odpovídající hardware a enterprise edici.

Abychom měli podmínky testu vyrovnanější a všechny databáze dostaly stejné šance tak jsme omezili maximální velikost buffer cache na 1 GB. Toto omezení je diskutabilní protože můžeme oprávněně namítat, že když má databáze nižší systémovou režii tak by měla mít povolenu tuto výhodu obrátit ve svůj prospěch. Mne ovšem více než absolutní výsledky zajímalo porovnání jednotlivých databázových strojů a tak jsem velikost paměti pro buffery omezil na 1 GB aby dostaly databáze s větší systémovou režií - Oracle a DB2 šanci.

PostgreSQL 8.3

Jako první se podíváme na PostgreSQL. Jeho výsledek nebyl nijak oslňující. PostgreSQL je COW (copy on write) databáze. Když měníte řádku tak se původní řádka nezmění nýbrž se do tabulky a indexů zapíše řádka nová. Akce měnící velké množství dat jsou proto výrazně pomalejší než u ostatních databází, kde se stará řádka přepíše novou.

Kupříklad update numerické hodnoty přes celou tabulku se scale faktorem 110 před začátkem TPC-B trvá u postgresu 2165 sekund zatímco u MySQL jen 35 sekund, což je 61 krát rychlejší. PostgreSQL by pomohlo kdyby jako ostatní databáze neprováděl aktualizace pokud je současný a nový řádek shodný. Tato nedokonalost PostgreSQL je dlouhá léta známá a postoj vývojářů se ten, že by si měli uživatelé opravit u svých dotazů klauzuli WHERE aby se neaktualizovaly řádky zbytečně. Tento příklad taky ukazuje jak důležité je testovat výkon na konkrétních úlohách a nespoléhat se moc na syntetické testy.

Nejhorší byla u PostgreSQL nevyrovnanost jeho výsledků. V praxi totiž musíme garantovat worst case a proto potřebujeme aby nám databáze podávala vyrovnaný výkon. PostgreSQL podává výkon mezi 50-100% nejlepšího dosaženého výsledku, což je dost špatné protože musíme hardware vlastně zdvojit abychom ve finále mohli garantovat uspokojivý service level.

Naměřené hodnoty tpsB v závislosti na scale faktoru. Všimněte si jejich kolísání, které má pravděpodobně na svědomí VACUUM.

scale faktorPostgreSQL tpsB
10583.7, 44.56, 53.52
10096.8, 53.52, 56.69, 100.00
10194.44

Konfigurace databáze:

shared_buffers = 1000MB
work_mem = 1024
maintenance_work_mem = 100MB
wal_buffers = 10MB
commit_delay = 100
commit_siblings = 2
checkpoint_segments = 25
checkpoint_timeout = 1h

MySQL 5.0

Ačkoliv MySQL v minulém a předminulém testu propadlo, tak si zde vedlo mimořádně dobře. Je sice pomalé ale velmi dobře škálovatelné. Škálovatelnost InnoDB enginu mne mile překvapila, protože podával stabilní výkon prakticky nezávislý na objemu zpracovávaných dat.

scale faktorMySQL tpsB
9091.83 88 89.76 96.11
9297.93
9484.0 92.52 103
97104.47
10199.83 120
10782.0 99.17 120
110105.57 96.05 93.23 111.87

Konfigurace databáze:

innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=2M
innodb_buffer_pool_size=1000M
innodb_log_file_size=46M
innodb_thread_concurrency=8

Oracle XE 10r2

Oracle jsem moc netestoval. Stala se mi totiž jedna nečekaná příhoda, která ve světě Oracle zase není tak zřídkavá.

Vzhledem k tomu, že Oracle verze XE je dost stará a léta neaktualizovaná 10.2.0.1, jsem se rozhodl provést aktualizaci na novější Oracle z řady 10. Očekával jsem totiž možné zlepšení výkonu kromě ostatních maličkostí jako oprava bezpečnostních chyb a novější verze administrativního rozhraní.

Aktualizace byla provedena úspěšně, ale namísto očekávaného zlepšení výkonu se výkon propadl. Ačkoliv TPC-B se scale faktorem 90 mi vrátilo u staré verze Oracle 82 tpsB, u nové verze jsem se nedostal mírně přes 50.

Systém neswapoval, ale chtělo by to pravděpodobně více paměti pro SGA, protože výrazně nabobtnal data dictionary. Teoreticky by to nemělo vadit, protože TPC-B test využíval jen 4 tabulky a tak nebyl důvod načítat nepoužívané objekty do paměti. Prakticky to ovšem dopadlo přesně naopak.

Prověřil jsem nejdůležitější výkonové ukazatele databáze a všechny ukazovaly běžné hodnoty a nic nenasvědčovalo tomu že by měla databáze důvod běžet abnormálně pomalu. Po asi půlhodinovém výzkumu se nepodařilo odhalit příčinu a tak jsem šel testovat další databázi.

scale faktorOracle XE tpsB
9082.0 51.27 52.06

Konfigurace databáze:

sga target 1GB

DB2 9.7

S DB2 nebyl co se týče testování větší problém. Ponechal jsem automatické nastavení velikosti bufferů v závislosti na zátěži a volné operační paměti a vypnul archive log režim.

Automatický správce paměti se snaží nastavit paměť využívanou databází tak, aby systém nemusel swapovat (to jest swapfile by měl být ideálně prázdný). Problém s touto strategií je na windows, které velmi rádi swapují i když vůbec nemusí a mají gigabajty volné paměti. Bylo proto nutné pozavírat co nejvíce aplikací aby automatický správce paměti přidělil databázi cca 1 GB RAM.

scale faktorDB2 tps
134135.74
Záznamy o zbytku měření se nedochovaly.

Konfigurace databáze:

 Paměť s vlastním laděním              (SELF_TUNING_MEM) = ON
 Velikost sdílené paměti databáze (4kB)(DATABASE_MEMORY) = AUTOMATIC(30944)
 Velikost souboru žurnálu (4kB)              (LOGFILSIZ) = 4096
 Počet primárních souborů žurnálu           (LOGPRIMARY) = 10
 Počet sekundárních souborů žurnálu          (LOGSECOND) = 246

Apache Derby 10.3

U Apache Derby nepoužíváme pro test stored proceduru, protože Derby umí používat jen stored procedury v Jave a nikoliv v SQL/PSM či podobném jazyku.

scale faktorDerby tps
20347.42
30115.82
4062.42
4561.13
5060.38
5555.37
5656.47
5787.17
6066.24
6362.35

Se stabilní Derby konfigurací je docela problém. Ačkoliv jsme přidělili 1 GB RAM JVM ve které běží tak pokud použijeme cache size větší než 35 tisíc stránek (experimentálně zjištěno) tak dochází k pádu aplikace na chybu Out of memory. 35 tisíc stránek přitom zabírá jen 280MB paměti. Těžko říci zda za pád mohou memory leaky v Derby nebo příliš pomalá garbage collection v JVM.

Konfigurace databáze:

java -Xmx980M -Xms500M
System.setProperty("derby.storage.pageSize", "8192");
System.setProperty("derby.storage.pageCacheSize", "35000");

Výsledky

DatabázetpsB
PostgreSQL100
IBM DB2135.74
MySQL110
Apache Derby62.35
Oracle XE82

Databáze Derby, ačkoliv prodávala v minulém testu dobrý výkon, měla dnes problémy se správou paměti. Je vidět, že není optimalizovaná pro zpracovávání většího množství dat. Překvapením bylo MySQL, které ukázalo vynikající škálovatelnost i když v minulém testu dopadlo špatně. PostgreSQL podal sice výkon ve špičce podobný MySQL, ale nebyl jej schopen trvale udržet. Databázi Oracle se stala díky instalaci patchů nehoda, kterou se mi nepodařilo opravit především díky tradiční značně složité administraci Oraclu. Podle očekávání vyhrála DB2, která byla výborná i v minulém testu.

Verze pro tisk

pridej.cz

 

DISKUZE

Ta konfigurace pg je take mimo 9.2.2011 06:09 Pavel Stěhule
  L Re: Ta konfigurace pg je take mimo 12.2.2011 12:19 Radim Kolář
    L Re: Ta konfigurace pg je take mimo 13.2.2011 07:10 Pavel Stěhule
      L TPC-B 17.3.2011 15:47 Radim Kolář




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

5.3.2017 19:12 /Redakce Linuxsoft.cz
PR: 23. března proběhne v Praze konferenci na téma Cloud computing v praxi. Hlavními tématy jsou: Nejžhavější trendy v oblasti cloudu a cloudových řešení, Moderní cloudové služby, Infrastruktura současných cloudů, Efektivní využití cloudu, Nástrahy cloudových řešení a jak se jim vyhnout.
Přidat komentář

27.2.2017 22:12 /František Kučera
Pozvánka na 137. sraz OpenAlt – Praha: Tentokrát jsme si pro vás připravili neobvyklou akci. Ve středu 1.3. v 17:30 nás přivítá sdružení CZ.NIC ve svých prostorách v Milešovské ulici číslo 5 na Praze 3, kde si pro nás připravili krátkou prezentaci jejich činnosti. Následně navštívíme jejich datacentrum pod Žižkovskou věží. Provedou nás prostory, které jsou běžnému smrtelníkovi nedostupné!
Po ukončení prohlídky se všchni odebereme do hostince U vodoucha, Jagelonská 21, Praha 3 pochutnat si na některém z vybraných piv či dát si něco na zub. Rezervaci máme od 19:30, heslo je OpenAlt.
Ale pozor! Do prostor datového centra máme omezený přístup, dostane se tam pouze 10 lidí! Takže kdo přijde dříve, ten má přednost, a občanky s sebou! Kdo nebude chtít na prohlídku datového centra, může se pomalu přesunout do hostince U vodoucha a u nepřeberné nabídky piv počkat na ostatní.
Přidat komentář

18.1.2017 0:49 /František Kučera
Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.
Přidat komentář

8.1.2017 17:51 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 19. ledna od 18:30 v pražském hackerspacu Brmlab. Tentokrát je tématem srazu ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. K vidění bude mechanická klávesnice dasKeyboard, trackball Logitech nebo grafický tablet (a velký touchpad) Wacom. Přineste i vy ukázat svoje zajímavé klávesnice a další HW. V 18:20 je sraz před budovou, v 18:30 jdeme společně dovnitř, je tedy dobré přijít včas. Podle zájmu se později přesuneme do nějaké restaurace v okolí.
Přidat komentář

1.12.2016 22:13 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.
Komentářů: 1

4.9.2016 20:13 /Pavel `Goldenfish' Kysilka
PR: Dne 22.9.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, provozování ERP v cloudu, o hostování různých typů softwaru, ale třeba i o zálohování dat nabízeném podnikům formou služby.
Přidat komentář

1.9.2016 11:27 /Honza Javorek
Česká konference o Pythonu, PyCon CZ, stále hledá přednášející skrz dobrovolné přihlášky. Máte-li zajímavé téma, neváhejte a zkuste jej přihlásit, uzávěrka je již 12. září. Konference letos přijímá i přednášky v češtině a nabízí pomoc s přípravou začínajícím speakerům. Řečníci mají navíc vstup zadarmo! Více na webu.
Přidat komentář

27.8.2016 8:55 /Delujek
Dnes po 4 letech komunitního vývoje vyšla diaspora 0.6.0.0
diaspora* je open-source, distribuovaná sociální síť s důrazem na soukromý
Více v oficiálním blog-postu
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

16.3.2017 16:33 / BezvaDesign.cz
Re: Hledám grafika do teamu

9.3.2017 11:44 / Jaromir Obr
Re: chyba

18.1.2017 20:18 / martin horky
Spolupraca linuxu a microsoftu

17.1.2017 9:57 / Pavel Hrubeš
Re: Externí USB televizní karta

4.1.2017 11:24 / Marcum
extension to house

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze