PostgreSQL történelem
2009.09.29. 09:00
You can read this article in english!
Nem, nem az a történelem, amely arról szól, hogy miként lett Ingresből PostgreSQL, hanem az, amely elmondja mennyivel lett gyorsabb a lassabb nyílt forrású adatbáziskezelőként ismert RDBMS.
A PostgreSQL-t nem kell bemutatni, hiszen az a két tábor, amely már találkozott vele, szentül, és megváltoztathatlanul meg van győződve a saját igazáról. Az egyik szerint a PostgreSQL lassú, és a MySQL-ben már úgyis vannak tárolt eljárások (bár használni még sosem használta), így az mindent tud, amit a PostgreSQL. A másik szerint a MySQL buta, és ahogy egyre-másra kerülnek bele az újabb funkciók, úgy lassul. Persze a PostgreSQL is egyre funkciógazdagabb lesz, így ezen elmélet szerint annak is egyre lassabbnak kell lennie.
Ennek próbálok meg utánajárni azzal, hogy végigpróbálom az öt utolsó kiadást mindkét szerverből, és változatlan hardver- és szoftverkörnyezetben megmérem a teljesítményüket.
A változatlan hardver- és szoftverkörnyezet esetünkben egy 24 magos (2,4 GHz-es, hat magos Intel E7450 CPU-k, 3x3 MiB L2 és 12 MiB L3 cache-sel), 128 GiB RAM-mal ellátott pécé szervert és a rajta futó FreeBSD 8/amd64 operációs rendszert jelenti.
A "Dunnington" kódnevű CPU felépítése és a CPU-k száma fontos tényező mind az OS-nek, mind pedig az adatbázisnak, hiszen ennél a processzornál rengeteg mag osztozik a szűkös FSB-n, amelyen keresztül a lassú memóriát, és a még lassabb perifériákat kell, hogy elérje. A több szintű cache-hierarchia és a lassú FSB-kapcsolat miatt különösen fontos szerepet kap az ütemező, és a memória-allokátor, amelyek a jó kiterheltség érdekében úgy kell balanszírozzanak az adatokkal, hogy azok minél nagyobb részét a cache-ekből tudja elérni az adott mag.
Ez komoly feladat, és a FreeBSD még messze nincs az út végén (sőt, amit azt illeti, épp csak rálépett), de itt alapvetően az volt a kérdés, hogy az adatbázis milyen utat járt be az egyes verziók között, nem pedig az, hogy az adott platformból az adott adatbázissal mekkora teljesítmény hozható ki. Utóbbi azt is magyarázza, hogy az adatbázis(ok)nál és az OS-nél minimális tuning volt csak, hiszen erre sajnos sem idő, sem erőforrás nem állt rendelkezésre.
A FreeBSD-re egyébként -azon kívül, hogy szeretem- azért esett a választás, mert a portjaiból könnyen elérhetők a PostgreSQL (és MySQL) korábbi verziói(-nak legfrissebb kiadásai). A tesztet magát a sysbench 0.4.12-es verziójával, annak is az OLTP tesztjével végeztük, 1 millió sorral, amely természetesen belefért a gép memóriájába. Az adatok két darab 15kRPM-es SAS diszken (RAID1-ben) voltak, amely azért messze van egy komolyabb adatbázis storage hátterétől, viszont kb. tipikusnak mondható egy egyszerűbb, webszerveres környezetben, ahol a gépekben lévő belső diszkekkel kell főzni.
A tesztek minden esetben egy percig futottak, ötször egymás után, és az ezen futások során keletkezett eredmények 95%-os konfidencia szint melletti értéke szerepel.
Nézzük:
A grafikon jobb oldalán lévő színkód-magyarázatról látszik, hogy a tesztelt PostgreSQL verziók a következők voltak: 8.0.21, 8.1.17, 8.2.13, 8.3.7 és 8.4.1.
A teszteknél a sysbench localhoston, UNIX socketen érte el a szervert, azaz ugyanazon a gépen futott, mint maga az adatbázis. Fontos lehet még, hogy a sysbench RDBMS-kliens libraryja megegyezett a szerverével, azaz például a 8.1.17-es szervert a 8.1.17-es libpq-val hajtottuk.
A fenti grafikon a sysbench OLTP tesztjének read only verziójával készült eredményeket mutatja. Egy példa a futásra (ez mondjuk pont a read-write teszt):
/usr/local/bin/sysbench --test=oltp --db-driver=pgsql --pgsql-host=/tmp --oltp-read-only=off --oltp-test-mode=complex --oltp-table-size=1000000 --num-threads=2 --max-time=60 --max-requests=0 run
Ha megnézzük a grafikont, jól látható, hogy a PostgreSQL nem lassul, hanem épp ellenkezőleg: gyorsul.
Érdekes lehet áttekinteni a kiadások megjelenési dátumait:
| branch/version/release date | First release | Tested release |
| 8.0 | 2005-01-19 | 2009-03-16 |
| 8.1 | 2005-11-08 | 2009-03-16 |
| 8.2 | 2006-12-05 | 2009-03-16 |
| 8.3 | 2008-02-04 | 2009-03-16 |
| 8.4 | 2009-07-01 | 2009-09-09 |
Az egyes kiadások közti változások pontos és részletes listáját a "Release Notes" tartalmazza, amelynél kevésbé részletesen, de sokkal átláthatóbban magyarázza el az egyes verziók által behozott újdonságokat a "Feature Matrix".
Mint az látható, a 8.0-ás PostgreSQL bár jól kezd egy szálon, már két szálnál elkezd leszakadni, négynél után pedig nem hogy nőne a teljesítmény, hanem erőteljesen csökken. Gyakorlatilag az adatbázis képtelen két magnál (CPU-nál) tovább skálázódni, nagyobb kliensszámnál pedig szinte értékelhetetlen teljesítményt nyújt.
A 8.1-es PostgreSQL már sokkal szebben szerepel, a letörés négy szál helyett 14-nél jön el, ahonnan 32 szálig erősen zuhan, viszont utána már többé-kevésbé tartja magát 1024 szálig.
A 8.2-es verzió újabb előrelépést jelent, hiszen ennek a csúcsteljesítménye már 18 magnál van, ahonnan sajnos ez is ugyanúgy megkezdi a zuhanását, mint a korábbi verziók (a 64 szál feletti mérési eredmények sajnos hiányoznak).
Masszív előrelépést jelent a 8.3-as, amely majdnem a gépben lévő CPU-k számáig (24) tolja a maximális teljesítményt jelző 14000 TPS értéket, azaz 22 szálon teljesít a legjobban. A korábbi verziókhoz képest rendkívül pozitív üzenet, hogy mind az abszolút teljesítmény, mind pedig a teljesítménycsúcs kitolódott.
Sajnos a 8.4-es ehhez képest némi visszalépést jelent, egyedül a 256 feletti kliensszámnál tudott nagyobb teljesítményt leadni, mint az elődje, máshol pedig némileg elmarad attól.
A fenti adatok a jobb áttekinthetőség érdekében táblázatos formában:
| Peak TPS | Peak performance at # of clients | |
| 8.0.21 | 1256 | 4 |
| 8.1.17 | 5620 | 14 |
| 8.2.13 | 8109 | 18 |
| 8.3.7 | 13984 | 22 |
| 8.4.1 | 13546 | 22 |
A PostgreSQL bebizonyította tehát, hogy olvasni nagyon tud, nézzük mi a helyzet, ha írni is akarunk!
A sysbench RW tesztjének eredménye:
Természetesen a read only teszthez képest jóval alacsonyabb számokkal találkozhatunk, hiszen itt már a diszkeket is mozgatni kellett. Az arányok viszont hasonlóak, ami mindenképpen jó hír, hiszen látható, hogy a PostgreSQL az elmúlt öt verzió alatt (a 8.4 kivételével) folyamatosan gyorsult, a 8.3-mal pedig szinte hihetetlen, több mint 100%-os teljesítménynövekedést ért el!
Lássuk ugyanezt táblázatban:
| Peak TPS | Peak performance at # of clients | |
| 8.0.21 | 361 | 2 |
| 8.1.17 | 873 | 10 |
| 8.2.13 | 1358 | 14 |
| 8.3.7 | 2795 | 18 |
| 8.4.1 | 2713 | 12 |
Itt a kép már vegyesebb, hiszen a 8.3-as verzió csúcssebessége távolabb került az optimális 24 klienses értéktől, ráadásul a 8.4-es nem csak csúcssebességben, hanem a csúcs balra tolódásában is romlott, viszont a mindössze 3%-os teljesítménycsökkenést hat CPU-val "odébb" tudta produkálni, ami a későbbiekben akár azt is jelentheti, hogy abszolút teljesítményben is megverheti majd a korábbi verziót.
Összefoglalásként azt hiszem elmondható, hogy ha a PostgreSQL-t lassúnak ismertük (vagy tapasztaltuk) a múltban, ideje lehet újragondolni (vagy -mérni), hiszen az elmúlt három évben óriásit javult a sebessége és a skálázhatósága. Az általa nyújtott szolgáltatásokról már nem is beszélve.
Hamarosan jön a MySQL történelem is!
Update: postgresql.conf
datestyle = 'iso, mdy'
default_text_search_config = 'pg_catalog.english'
lc_messages = 'C' # locale for system error message
lc_monetary = 'C' # locale for monetary formatting
lc_numeric = 'C' # locale for number formatting
lc_time = 'C' # locale for time formatting
listen_addresses = '' # what IP address(es) to listen on;
log_destination = 'syslog'
maintenance_work_mem = 64MB
max_connections = 1064 # (change requires restart)
shared_buffers = 1024MB
silent_mode = on
unix_socket_directory = '/tmp' # (change requires restart)
unix_socket_group = 'pgsql' # (change requires restart)
unix_socket_permissions = 0777 # begin with 0 to use octal notation
update_process_title = off
work_mem = 16MB
Szerző: blackshepherd
4 komment
Címkék: performance postgresql freebsd mysql benchmark sysbench oltp
Ajánlott bejegyzések:
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
Mr. Big 2009.09.29. 19:26:15
- Kizárólag primary key-en végez műveleteket. Kiváncsi lennék az egyéb indexeken történő műveletvégzésre is, hiszen nagy különbségek lehetnek.
- Egyáltalán nincsenek join-ok, sem kevésbé hatékony queryk. Tapasztalataim szerint durva különbségek lehetnek az egyes adatbázis kezelők (ez lehet akár ugyanazon termék verziói) optimalizálói között.
- Csak fix méretű rekordokat használ. Mi van akkor, ha pl varchar is van a táblában? Hogyan reagál az adatbázis kezelő a sok törlésre+írásra? (régen a PostgreSQL híres volt a vacuumozási gondjairól, szerencsére ezt mára nagyjából megoldották)
- Mi van a karakterkódolással? Kis hazánkban elengedhetetlen az, hogy a DB-nek jó kódolási lehetőségei legyenek, és az átkódolás is egy jelentős performancia faktor (főleg ezen a szinten)
Összefoglalva: a SysBench tesztjét nagyon a valóságtól elrugaszkodottnak érzem. Ráadásul az általa szimulált felhasználása ma már nem RDBMS-t hanem valamilyen kulcs-érték adatbázist célszerű használni.
A tesztelés menete szempontjából nem találom szerencsésnek azt, hogy a kliens is ugyanazon a gépen futott. Ekkora kapacitás mellett számottevő lehet a kliens terhelése is. Elképzelhetőnek tartom, hogy például emiatt nem a magok számánál volt a csúcsteljesítmény, hanem előtte. (Plusz a hálózati protokol is számíthat a teljesítmény mérésénél)
Továbbá kíváncsi lennék ezekre a számokra akkor is, ha az adatbázis nem fér el a memóriában. Ez még ma is gyakori szituáció, és a disk használat módja, az elérési, párhuzamosítási, cache-elési algoritmusok rengeteget számíthatnak.
Megjelenítés szempontjából szerintem jelölhetnéd a grafikonokon a 24 klienst. Optimális esetben itt lenne ugye a terhelés csúcs, de most nehéz leolvasni, hol is helyezkedik ez el.
Mr. Big 2009.09.29. 19:42:47
A görbék alakjával sem vagyok igazán megelégedve. Az ideális kliensszámot elérve drasztikusan csökken a sebesség, számomra nem ezt jelenti a "graceful degradation". Kicsit ilyesztő, hogy írási sebességben a 64 kliens esetén nagyjából csak azt kapom a 24 magos szerveren, mintha a csak két magom lenne, ideális terhelésen. Nem tudom, hogy ezt vajon a disk keresztmetszet, vagy belső limitek adják. Az olvasás szebben degradálódik, bár azért az azonnal elvesztett 3-4ezer TPSt kicsit sajnálom.