ARCHIV

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

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 faktor	PostgreSQL tpsB
105	83.7, 44.56, 53.52
100	96.8, 53.52, 56.69, 100.00
101	94.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 faktor	MySQL tpsB
90	91.83 88 89.76 96.11
92	97.93
94	84.0 92.52 103
97	104.47
101	99.83 120
107	82.0 99.17 120
110	105.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 faktor	Oracle XE tpsB
90	82.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 faktor	DB2 tps
134	135.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 faktor	Derby tps
20	347.42
30	115.82
40	62.42
45	61.13
50	60.38
55	55.37
56	56.47
57	87.17
60	66.24
63	62.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áze	tpsB
PostgreSQL	100
IBM DB2	135.74
MySQL	110
Apache Derby	62.35
Oracle XE	82

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

DISKUZE Ta konfigurace pg je take mimo 9.2.2011 06:09 Pavel Stěhule   Re: Ta konfigurace pg je take mimo 12.2.2011 12:19 Radim Kolář     Re: Ta konfigurace pg je take mimo 13.2.2011 07:10 Pavel Stěhule       TPC-B 17.3.2011 15:47 Radim Kolář Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.