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

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ů

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

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

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

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

> Poslední diskuze

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

9.4.2016 9:41 / jiwopene@gmail.com
Re: změna velikosti disk.oddílu

9.4.2016 9:40 / jiwopene@gmail.com
Re: Přenesení starého OS Win7 na virtuál v Debianu

Více ...

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