MySQL teljesítményösszehasonlítás, ext3, ext4, xfs és btrfs

MySQL, MariaDB

A MySQL sysbenches tesztelésével kapott adatok elemzésének majdnem a végére értem, az utolsó előtti összehasonlításban az a kérdés, hogy ext3-on, ext4-en, xfs-en, vagy btrfs-en gyorsabb a MySQL?

Linux+MySQL: milyen fájlrendszeren?

( Dgzt | 2009. 10. 12., h – 12:50 )

Ext4-en azért van még mit csiszolni. Gondolkoztam, hogy kipróbálom, de úgy látom még túl korai lenne.

Nálam desktopon sima PATA vinyón (udma5 mód) láthatóan gyorsabb volt, mint az ext3 (delayed allocation bekapcsolva). Ez persze teljesen más, mint a cikk mérése.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

Nagy fájlokkal (1-10GB) össze se lehet hasonlítani a kettőt, nagyságrenddel gyorsabb az ext4 pl. file törlésnél. Ext3-nál beleőszültem ilyenkor mire végzett, ext4 egy pillanat alatt megvan. Pár hónapja használok ext4-et, eddig teljes megelégedéssel, ritka hogy ennyire látványos gyorsulást okozzon egy új szoftver használata ugyanolyan hardveren.

ezt4-en ráadásul az fsck is sokkal-sokkal gyorsabb. Néhány másodperc alatt végez, az ext3 percekig darált. Ok, ez az eltérő felépítés meg naplózás miatt van, de nekem már megérte váltani miatta. Különösebben nem zavar desktop gépen a többprocesszoros többszálú mysql teszten való leszerepelése. Destopon pl érezhetően gyorsabb.

Egyébként meg szerintem a mysql-t is be lehetne úgy állítani, hogy azon a nagyvason ext4-en is jól szerepeljen. Ha jól tévedek most azért ilyen lassú, mert a fájlrendszer továbbolvassa az adatokat, vagy más hasonló okokból.

( Zahy v | 2009. 10. 12., h – 13:24 )

Nekem azért az IBM-féle, és a killerFS is hiányzott a készletből.

( airween v | 2009. 10. 12., h – 13:26 )

mkfs.ext4 /dev/cciss/c0d1p1
...

end_request: I/O error, dev cciss/c0d1, sector 0
...ismételve néhány 10000x...

reboot után a partíciós tábla sehol.
Hello ext4.

(Ubuntu 9.10, 2.6.31-10)

( uid_17626 | 2009. 10. 12., h – 14:46 )

Fasza, hogy csinálsz ilyen teszteket! Respect!

ps.: jó lenne dokumentálva lenne a teszt is stepbystep. ha ez extra és sok melót vesz igényben akkor felejtsd el, hogy leírtam ezt :)

Valami ilyesmi: 


mkfs
mount
dbinit
dbstart
for thr in threads
  sysbench cleanup
  sysbench prepare
  for run in runs
    sysbench run
dbstop
umount

Öt run van, ezek közül ministat -n -c 99.5-tel kerül kiválasztásra a "legjobb".

A sysbench paraméterek benne vannak a cikkekben.

suckIT szopás minden nap! Linux+MySQL: milyen fájlrendszeren?

( syntern | 2009. 10. 12., h – 15:10 )

Ezt írod: "Meglepő, hogy az ext3 ilyen fölényesen gyaláz mindenkit, a feltörekvő, új generációs FS-ek (btrfs, ext4) pedig mennyire rosszul teljesítenek..."

Szerintem nincs ebben semmi meglepő. Mondjuk a zfs-ből indulok ki, de a btrfs is eléggé hasonló akar lenni hozzá:

Szerintem (hasracsapásos megérzés) egy olyan fájlrendszer, ami a módosításokat mindig új blokkba írja, teljesen más karakterisztikával bír, mint egy olyan, amelyik helyben felülír. A mai adatbázis-kezelők az utóbbira vannak IO-optimalizálva. Az append-only storage-ok (google fs vagy a hozzá hasonló merítések) jobban teljesítenek azokon a fájlrendszereken, amik maguk is mindig új blokkra írnának. (Ez utóbbi már kevésbé hasracsapás, dolgozok valami hasonlón).

szerk., mert kihagytam a lényeget: tök jók a méréseid, kudos!

Lehet abban valami, amit mondasz, köszönöm az észrevételt. (bár itt: http://suckit.blog.hu/2009/10/10/freebsd_zfs_vagy_ufs_a_my_postgre_sql_… azért a ZFS-nek szinte semmilyen hátránya sincs)
Persze nem csak adatbázisból áll a világ.

suckIT szopás minden nap! Linux+MySQL: milyen fájlrendszeren?

( honorshark | 2009. 10. 12., h – 16:29 )

XFS-rol csak annyit hogy jobban melegedett tole a gep es a vinyo mint ext3 alatt. Reiser-t nem hasznaltam miutan reiser4 mar doglott volt, gondoltam nincs sok ertelme egy "csak eletben van tartva" fs-t hasznalni. Aztan sokan arra eskusznek es VMben nagyon jol teljesit, de mint eles... felek hasznalni.

Jelenleg ext4 van. Ubuntu-n volt egy bug nemreg, korrupciot illetve "in the future" problemat okozott. A sajat VM-emben ez konnyu volt, csak elindult a gep, fsck maintance modban. De ismerosomnek ezt elmagyarazni...ajj.. az a hires deskto ev.. :/

( lgb | 2009. 10. 13., k – 14:23 )

Bar teny, hogy default beallitasokrol volt szo, de ext4 eseten erdekes lenne a barrier=0 modon mountolt esetet is megvizsgalni pl, meg hasonlok.