Kapcsolódás az adatbázishoz, fájl tárolás tesztelése

Egy java-ban írt program segítségével kapcsolódtam a tanszéki szerverhez, valamint méréseket végeztem az ottani Oracle 11g adatbázison. A méréseket különböző fájltárolási módok mellett végeztem:
„keep_duplicates” / „deduplicate” – az azonos tartalmú fájlokat elmentse-e még egyszer, vagy csak egy mutatót használjon helyette
„cache” / „nocache” – a gyorsítás érdekében tegye-e gyorsítótárba a legutóbb használt adatokat, vagy sem
„compress” / „nocompress” – helymegtakarítás érdekében tömörítse-e a fájlokat

A program futása közben létrehoz egy táblát, amibe véletlenszerűen generált fájlokat illeszt be, majd visszaolvassa azokat, végül kiírja a kérés kiadását követő és a feladat végrehajtás utáni idő különbségét, vagyis leméri a folyamat válaszidejét.

A teszt kimutatta, hogy a fájltárolás hatékonyságának növelésével jelentősen növekszik a fájl lementési ideje, kiolvasáskor azonban nem számottevők a különbségek. Tárhely takarékossági szempontból tehát mindenképp ajánlott a duplikációk szűrése, a gyorsítótár használata, valamint a tömörítés alkalmazása. Így az azonos fájlokat nem szükséges többször tárolni, elég csak mutatóval hivatkozni rájuk, a gyakran használt fájlok elérési ideje a gyorsítótár révén lecsökken, valamint az adatblokkok kihasználtsága is növekszik a tömörítés áltál.

Az adatbázishoz kapcsolódó program elkészítésének menete itt olvasható.

A teszteléshez az adattáblában LOB-okat, vagyis nagy objektumokat hozunk létre, melyeket SecureFile-ként tárolunk. Dokumentáció szerint a LOB (Large Object) nagyméretű adatok tárolására létrehozott adattípus, az adatbázis konfigurációjától függően 8TB – 128TB maximális adat tárolására képes.

Példaképp egy adattábla létrehozása magas szintű tömörítést használva a következőképp történik:

CREATE TABLE t1 ( a CLOB)

LOB(a) STORE AS SECUREFILE (

COMPRESS HIGH

CACHE

);

A LOB-okról és a SecureFile-okról további információk az alábbi oldalakon érhetők el:
Introduction to Large Objects
Using Oracle SecureFiles

Linuxos naplózó fájlrendszerek sebességtesztje

A teszt során négyféle Linuxos naplózó fájlrendszeren (EXT3, ReiserFS, JFS, XFS) végeztem sebességméréseket az IOzone nevű fájlrendszer tesztelő program segítségével. A program kifejezetten fájlrendszerek tesztelésére optimalizált, vagyis az eredmények nem a merevlemez adatátviteli sebességét tükrözik, hanem adott konfiguráció mellett az egyes fájlrendszerek teljesítményét mutatják. Mindegyik fájlrendszer azonos méretű, fizikailag egymást követő, egyenként 9GB méretű partíciókon kapott helyet, melyek a tesztprogramon kívül más adatot nem tartalmaztak.

A teszt négyféle sebesség mérésére terjedt ki, melyek a következők voltak: írás és újraírás, valamint véletlenszerű írás és véletlenszerű olvasás sebessége. A véletlenszerű írás/olvasás esetében nem a teljes fájlt, hanem annak véletlenszerűen kiválasztott rekordjait írja/olvassa a program, amely így egy adatbázis kiszolgáló háttértár működését szimulálja. Az első körben többféle rekordmérettel (4KByte – 16MByte), valamint különböző méretű fájlokkal (64KBbyte – 512MByte) végeztem méréseket. Mivel ekkora fájlok még beleférnek az operációs rendszer gyorsítótárába, így ez a teszt nem a tényleges lemezműveleti sebességeket mutatja, viszont jól tükrözi az egyes fájlrendszerek sebességviszonyait.

A mérések rámutattak, hogy az EXT3 fájlrendszer írási sebessége jelentősen alulmarad a másik három fájlrendszerhez képest, melyeken az írás több mint kétszer gyorsabban zajlik, ez a különbség azonban valamelyest csökken az újraolvasás vizsgálatánál. Ezen felül a másik három fájlrendszer teljesítménye sokkal kiegyensúlyozottabb, lényegesen kevesebb a sebességbeli ingadozás. Megfigyelhetjük, hogy adott konfiguráció esetén a legnagyobb sebességet a 128KByte-os rekordok esetén érjük el (adatok a leni táblázatban). Legszembetűnőbben ez a ReiserFS fájlrendszernél látszik, ahol ez az adatátviteli sebesség háromszorosa, illetve kétszerese a 4KByte-os, illetve 8KByteos rekordok esetén mért átviteli sebességnek. Ez a jelenség a kisebb rekordok magasabb fajlagos beviteli költségének tudható be.

Átlagsebességek 128KByte rekordméretnél
	EXT3 MB/s	RFS MB/s	JFS MB/s	XFS MB/s
Írás	277,57	611,99	619,30	611,62
Arányok	44,82%	98,82%	100%	98,76

Véletlenszerű írás esetén a sebességviszonyok a következőképp alakultak: Szintén a JFS végzett az élen, amelyet a ReiserFS, majd az XFS követett 10, illetve 20%-os lemaradással. A sort ismét az EXT3 zárta, azonban a sebessége itt már megközelíti a JSF sebességének 70%át. Véletlenszerű írás során a legnagyobb átviteli sebességek 32KByte-os rekordméretet használva adódtak, az ekkor mért adatokat az alábbi táblázat foglalja össze:

Átlagsebességek 32KByte rekordméretnél
	EXT3 MB/s	RFS MB/s	JFS MB/s	XFS MB/s
Véletlenszerű írás	1011,76	1319,7	1454,09	1182,1
Arányok	69,58%	90,76%	100%	81.29%

A teszt második felében egy, az operációs rendszer gyorsítótáránál nagyobb méretű fájllal végeztem a méréseket, fix rekordméret mellett. Ezzel elkerülhető volt, hogy a teszt folyamán a teljes fájl a fizikai memóriába kerüljön, felgyorsítva a műveletek sebességét, így valós képet kaphatunk a fájlrendszerek közti tényleges teljesítménybeli különbségekről. Az eredményeket az alábbi táblázat foglalja össze.

Sebességmérés 128KByte rekordmérettel, 3GByte-os fájllal MB/s
	EXT3	RFS	JFS	XFS
Írás	29,58	29.79	33,93	31,89
Újraírás	29,11	30,1	36,15	32,13
Véletlenszerű olvasás	18,29	19,09	19,5	18,375
Véletlenszerű írás	17,84	38.39	36,95	31,03

Szekvenciális írás esetén a másik három fájlrendszer sebessége valamivel elmarad a JFS 33,93 MB/s-os értékétől, a legkisebb sebességű EXT3 fájlrendszerhez képest ez 14,7%-kal nagyobb sebességet jelent. Újraírás esetén ez a különbség még számottevőbb, 24,2%-os. Véletlenszerű olvasás és írás esetén értelem szerűen a sebességek a legtöbb esetben drasztikusan csökkennek. Meglepő lehet azonban, hogy a véletlenszerű írás sebessége a véletlenszerű olvasásénál két fájlrendszer esetében is jóval nagyobb értékeket mutat. Ez annak a következménye lehet, hogy írás esetén nem közvetlenül a merevlemezre történik az írás, hanem a rendszermemóriába, kiolvasáskor pedig a véletlenszerűen választott rekordok, igen kis valószínűséggel lesznek benne a gyorsítótárban. A JFS fájlrendszer, igaz csak 6,6%-kal a véletlenszerű olvasás esetén is megőrzi vezető pozícióját, azonban a véletlenszerű olvasásnál már az RFS fájlrendszer nyújtotta a legnagyobb sebességet, több mint kétszer gyorsabbnak bizonyult a leglassabb EXT3 fájlrendszernél.

A teszt rámutatott arra, hogy általánosságban JFS, vagy ReiserFS fájlrendszereket érdemes használni, mivel ez a két fájlrendszer nyújtja összességében a legnagyobb sebességeket. Kerülni kell azonban adatbázis kiszolgáló esetén az EXT3 fájlrendszer alkalmazását annak gyenge véletlenszerű íráskor nyújtott teljesítménye miatt.

Sikeres telepítés, fájlrendszer teszt

A szükséges .NET Framework és Windows installer telepítését, valamint a tűzfal megfelelő beállításait követően sikeresen felinstalláltam a 11G Windows kompatibilis változatát.

Sajnos a Debian Etch Linuxszal egyelőre nem sikerült a 11G számára megfelelő környezetet kialakítani, ugyanis a a gépemben levő Marvell Yukon Ethernet kártyát nem ismeri fel a rendszer, a driver utólagos telepítése, majd a kernel lefordítása után pedig sikertelen a bootolás.

Emellett négyféle Linuxos naplózó fájlrendszert (ext3, reiserfs, jfs, xfs) teszteltem le az IOzone nevű fájlrendszer sebességmérő program segítségével. Megmértem az írás, az újraírás, a véletlenszerű írás és a véletlenszerű olvasás sebességeit. Utóbbi két teszt nem a teljes fájlt írja, illetve olvassa, hanem annak bizonyos, véletlenszerűen kiválasztott részeit, amely így jól szimulálja az adatbázis kezelők működését. A teszt részletes eredményeiről hamarosan beszámolok.

Újabb telepítési kísérletek:

Időközben megjelent az Oracle 11g Windows kompatibilis változata, ám ennek telepítése során többféle probléma is jelentkezett. Egyrészt a service pack típusa okozott gondot („The system is not at the correct Service Pack level for installing Oracle Database 11g.”), annak ellenére, hogy a követelményeknek megfelelően Service Pack 2-es Windowst használok. Másrészt figyelmen kívül hagyva ezt a problémát a telepítés elindul, azonban 86%-nál nem találja az oci.dll fájlt, pedig az addig felrakott fájlok között megtalálható, ám elérési utat nem lehet megadni hozzá. Ezt követően újabb hibaüzenet kíséretében lefagy a telepítés. Egyelőre próbálok megoldást találni ezen problémákra, valamint az Oracle Linux helyett Debian Etch-el kísérlem meg a 11g telepítését.

A kezdetek:

Legelső lépésként letöltöttem az Oracle Enterprise Linux 5.0-t, valamint az Oracle 11g linux kompatibilis változatát. A linux azonban nem támogatta a gépemben levő videokártyát, még a legfrissebb driver installálása után sem sikerült behoznom a grafikus kezelői felületet, amely az egyik alapkövetelménye lenne a 11g installálásának, ezért egy másik linux disztribúció telepítésével fogok próbálkozni. Alternatív megoldásként VMware segítségével virtuális rendszerként is feltettem az Oracle linuxot. A grafikus kezelői felület itt már rendesen funkcionál, viszont a 11g telepítője nem futott le ebben a környezetben.

Bemutatkozás, téma leírása:

Üdvözlök minden kedves látogatót! Nevem Papp Gábor, a Budapesti Műszaki és Gazdaságtudományi Egyetem negyedéves villamosmérnök hallgatója vagyok. Ezt a blogot abból a célból hoztam létre, hogy az infokommunikációs laboratórium című tárgy keretén belül választott témámat ilyen formában is dokumentáljam, a félév során végzett munkámat közzétegyem, az eredményeimről beszámoljak. Választott témám az "Adatbázis alapú fájltárolás", amelynek során többféle fájlrendszeren fogom tesztelni a különböző méretű és mennyiségű fájlok hozzáférési idejét és másolási sebességét.