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 4205×

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ů

20.5.2018 17:45 /Redakce Linuxsoft.cz
Ve čtvrtek 31. května 2018 připravuje webový magazín BusinessIT ve spolupráci s Best Online Média s.r.o. pátý ročník odborné konference Firemní informační systémy 2018. Akce proběhne v kongresovém centru Vavruška (palác Charitas), Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 15 hod. odpoledne. Konference je zaměřena na efektivní využití firemních informačních systémů a na to, jak plně využít jejich potenciál. Podrobnější informace na webových stránkách konfrence.
Přidat komentář

14.5.2018 7:28 /František Kučera
Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 17. 5. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: Audio – zvuk v GNU/Linuxu.
Přidat komentář

7.5.2018 16:20 /František Kučera
Na stránkách spolku OpenAlt vyšla fotoreportáž Pražské srazy 2017 dokumentující srazy za uplynulý rok. Květnový pražský sraz na téma audio se bude konat 17. 5. 2018 (místo a čas ještě upřesníme).
Přidat komentář

17.4.2018 0:46 /František Kučera
Dubnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 4. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tématem tohoto srazu bude OpenStreetMap (OSM) aneb svobodné mapy.
Přidat komentář

16.3.2018 22:01 /František Kučera
Kulatý OpenAlt sraz v Praze oslavíme klasicky: u limonády a piva! Přijďte si posedět, dát si dobré jídlo a vybrat z mnoha piv do restaurace Kulový blesk, který najdete v centru Prahy nedaleko metra I. P. Pavlova na adrese Sokolská 13, Praha 2. Sraz se koná ve čtvrtek 22. března a začínáme v 18:00. Heslo: OpenAlt. Vezměte s sebou svoje hračky! Uvítáme, když si s sebou na sraz vezmete svoje oblíbené hračky. Jestli máte nějaký drobný projekt postavený na Arduinu, nějakou zajímavou elektronickou součástku, či třeba i pěkný úlovek z crowdfundingové akce, neváhejte. Oslníte ostatní a o zábavu bude postaráno.
Přidat komentář

13.2.2018 0:41 /František Kučera
Únorový pražský sraz OpenAltu se koná 15. 2. 2018 a tentokrát se vydáme na návštěvu do jednoho pražského datacentra. Sejdeme se v 17:50 v severovýchodní části nástupiště tramvajové zastávky Koh-I-Noor. Po exkurzi se přesuneme do restaurace U Pštrosa (Moskevská 49), kde probereme tradiční témata (svobodný software a hardware, DIY, CNC, SDR, 3D tisk…) a tentokrát bude k vidění i IoT brána od The Things Network.
Přidat komentář

11.2.2018 23:11 /Petr Ježek
Hledáte lehký a rychlý prolížeč PDF souborů? Pokud vás již omrzelo čekat na načítání stránek či jiné nešvary, zkuste xreader.
Přidat komentář

11.2.2018 20:35 /Redakce Linuxsoft.cz
Třetí ročník odborné IT konference na téma Cloud computing v praxi proběhne ve čtvrtek 1. března 2018 v konferenčním centru Vavruška, v paláci Charitas, Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 16 hod. odpoledne. Konference o trendech v oblasti cloud computingu nabídne i informace o konkrétních možnostech využívání cloudů a řešení vybraných otázek souvisejících s provozem IT infrastruktury.
Přidat komentář

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

> Poslední diskuze

20.2.2018 18:48 / Ivan Majer
portal

20.2.2018 15:57 / Jan Havel
Jak využíváte služby cloudu v podnikání?

16.1.2018 1:08 / Ivan Pittner
verejna ip od o2 ubuntu

15.1.2018 17:26 / Mira Harvalik
Re: Jak udělat HTML/Javascript swiping gallery do mobilu?

30.12.2017 20:16 / Michal Knoll
odmocnina

Více ...

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