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

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ů

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ář

24.8.2016 6:44 /Ondřej Čečák
Poslední týden CFP LinuxDays 2016; pokud byste rádi přednášeli na LinuxDays 2016 8. a 9. října v Praze, můžete svůj příspěvek přihlásit, následovat bude veřejné hlasování.
Přidat komentář

9.8.2016 22:56 /Petr Ježek
Zařazení souborového systému reiser4 do jádra 4.7 znamená konečně konec patchování jádra jen kvůli možnosti použít reiser4.
Přidat komentář

12.7.2016 13:14 /František Kučera
Spolek OpenAlt zve na 130. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 21. července od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

11.7.2016 16:53 /Redakce Linuxsoft.cz
Konference LinuxDays hledá přednášející. Přihlášky poběží do konce prázdnin, v září bude hlasování a program. Více na https://www.linuxdays.cz/2016/cfp/.
Přidat komentář

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.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í, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

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

> Poslední diskuze

19.9.2016 21:04 / Marek Schoř
Poděkování

1.9.2016 13:07 / Walker
hardwood floor refinishing

12.8.2016 11:51 / Josef Zapletal
Jak udělat HTML/Javascript swiping gallery do mobilu?

8.8.2016 14:58 / Adams
fairies for hire

28.7.2016 15:51 / pepan
Re: NetBeans vs Eclipse

Více ...

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