Adatbázis teszt
Az első tesztalany egy saját adatbázis. Ez általam összeszedett mérési adatokat tartalmazó adatbázis, a pg_dump-pal készített dumpja 26855701 sor. 3 nagy tábla és pár apró szösszenet van benne. Az adatbáziskezelő a memória méreteknek megfelelően lett hangolva, a fizikai ram felét kapja a postgres, a másik felét a linux block cache. Egy későbbi tesztre ad lehetőséget, hogy melyik postgres paraméter állítása hogyan befolyásolja a teljesítményt.
A full sql insert formátumú dump betöltése nem sikerült, 15 óra alatt kb. a negyede ment be, miközben az amd egyik magja unatkozott, a másik IO-Wait állapotban volt. A tesztet végül copy formátumú dump-pal végeztem.
(Érdekesség kedvéért betoltam a 990x-be azt a teljes sql formátumú dumpot is, amivel a microserver becslés szerint 60 órát görcsölt volna, ennek eredménye van a harmadik oszlopban.)
N40L I7-990X I7-990X/full
real 7m16.358s 2m32.027s 81m11.430s
user 0m14.965s 0m4.508s 9m7.462s
sys 0m5.128s 0m1.024s 5m40.137s
Ez a teszt gyakorlatilag a bemeneten jövő input minél gyorsabb értelmezését és utána az adatbázis írási képességét méri. A copy formátumú dump esetén csak a numerikus adatokat kell binárissá alakítani, a full sql formátumú dump esetén a teljes sql parancsot értelmezni kell.
Ez az oka a lényeges sebességkülönbségnek.
Ez már elsőre is egy kisebb meglepetés, hogy a microserver nagyjából 3x rosszabb eredményt ér el az erőmű ellen. Félreértés ne essék, ez igen jó eredmény, a két cucc nagyon nem egy kategória.
(A kép forrása fgr at virten.net cikkéhez mellékelt illusztráció)
Első teszt: select és update.
Egy szkript futtatásával tesztelek, amely keres 10 ezer olyan rekordot egy táblában, amely rekordokban az egyik mező kitöltetlen, megkeresi a hozzá tartozó adatot egy másik táblából és kitölti. Ez egy psql fork a 10 ezer rekordra, ciklus, egy psql fork keresés minden rekordra és összesen egy psql fork a 10 ezer rekordra az update. Valahogy így:
psql -c 'select ...' | while read id; do
ujertek=$(psql -c ' ...' );
printf "update ... set mezo=$ujertek where ;\n"
done | psql
Ezt futtatom a három gépen.
Gép mérés real user sys
N40L 1 16m26.576s 9m54.189s 2m57.799s
N40L 2 16m26.276s 9m56.085s 2m55.907s
N40L 3 16m25.285s 9m54.481s 2m56.303s
IBM 1 12m7.536s 8m18.699s 2m7.484s
IBM 2 12m59.986s 8m49.777s 2m11.848s
IBM 3 12m14.432s 8m21.059s 2m10.932s
990X 1 5m8.635s 3m56.011s 0m50.423s
990X 2 4m56.887s 3m47.374s 0m48.515s
990X 3 5m8.254s 3m54.811s 0m51.067s
A mérési eredményekből jól látszik, hogy amelyik gép terheletlenül vett részt a teszten (a microserver), az relatíve kis szórással csinálta végig, amely gépeken más is történt, ott azért volt valamennyi eltérés.
Az eredményekből az is látszik, hogy a 206m, bár belépő szintű szerver volt, azért nem rossz architektúra. Derekasan megverte a nála kb. 5 évvel fiatalabb, 4x annyi rammal, sokkal gyorsabb diszkekkel felszerelt N40L-t. Mivel csak a prociban erősebb, ezt ennek a számlájára írhatjuk
A darálóval, a temérdek rammal és a számolatlan lóerővel természetesen nem bírtak, de ez megint csak egy másik kategória.
Következő teszt:
select count(*) egy 12 millió soros táblára:
N40L: 10.585s 3.160s
IBM: 41.549s 40.117s
990X: 4.590s 0.948s
select count(*) egy másik 12 millió soros táblára:
N40L: 9.298s 3.190s
IBM: 30.943s 33.854s
990X: 4.061s 0.923s
select mezo,count(*) group by 1 order by 1 az előbbi 12 millió soros táblára:
N40L: 8.259s 8.216s
IBM: 38.982s 38.833s
990X: 2.880s 2.861s
Az első oszlopban az első lekérdezés eredménye, a másodikban ugyanaz, még egyszer. Világosan látszik, hogy a diszken kb. 4.1 GB-ot elfoglaló adatbázist az ibm nem tudta cachelni, a másik két gép igen, ezzel jelentősen csökkentve a feldolgozási időt.
Emellett az ibm-en más adatbázisok is vannak, aktív használatban, ez tovább rontotta az eredményét. A harmadik teszt egyforma adatait a korábbi futtatás cachelése okozhatta.
Az is világosan látszik, hogy a microserver processzorát nem adatbázis mókolásra találták ki, bár a 2-3 közötti szorzók a 990x-hez képest nem véres probléma.
A cikk még nem ért véget, kérlek, lapozz!
