Názor k článku Výkon databáze na různých souborových systémech od Jan Schermer - Diky za reakce. 1) nobarrier (mimochodem, barriery uz nikde...

Diky za reakce.

1) nobarrier (mimochodem, barriery uz nikde nejsou, dokonce ani v RHEL6 kde je odstranili tusim pocatkem 2014, dnes je to FUA/explicit flush).

Primou referenci nemam, ale v SSD se velice intenzivne hrabu posledniho pul roku (benchmarky, chovani pri vypnuti za chodu, TRIM).
U nobarrier jsem dospel k nazoru, ze si nikdo neni jisty jestli to je 100% bezpecne - prosel jsem hromadu diskuzi na mailing listech (xfs, ext4, lkml) a udelal par vlastnich testu ze kterych jsem nezjistil v zasade nic. Nejzajimavejsi debata byla tusim kolem ext4 option journal_checksum - obcas se jeste divim ze mam data.

Ano, vetsinou to funguje a i vendori databazi (treba Oracle) tvrdi ze se muzou barriers vypnout, jenze ty databaze si taky resi dost veci samy pres O_DIRECT* a filesystem je jim sumak. Ono totiz nejde jen o to, jestli disk flushne data z cache (to nas u S3700 netrapi), ale hlavne o to, ze bez barier neni zarucene poradi tech operaci co tam posila OS. A zatimco s barierami se o poradi stara pagecache/sche­duler, tak bez barier za to neruci vlastne nikdo.
"Dokazat" ze se to chova nebo nechova jak ma je temer nemozne - je potreba vyrobit IO pattern a k tomu odpojit napajeni, a i kdyz to udelate 1000x bez problemu tak to neznamena jistotu. Me se nepovedlo rozbit filesystem bez barier ani na disku ktery zalohovanou writecache nema (nutno podotknout ze to byl dost podivny SSD disk...), protoze vyrobit takovy IO pattern bylo moc prace. Jednim procesem v jednom threadu (nebo databazi, ktera ma jako bottleneck jeden transakcni log) se to hned nerozbije.

Navic to, ze vypnuti barrier zrychli IO, muze byt krasnym dokladem ze jsou potreba** - S3700 rozhodne nepise data z writecache pri kazde bariere, ale zaroven je to s nimi pomalejsi - proc? Mimochodem tohle zrovna dost zavisi i na radici (zkuste LSI a XFS a bude to nejspis pomalejsi, a to i v IT rezimu kdy to ma byt jenom hloupy adapter. A taky nemusi fungovat spravne TRIM...).
Efekt barier se nejlepe testuje (tedy spis netestuje) pres FIO a je to velika divocina protoze IO muze hnit nekde v kernelu 5ms aniz by disk neco delal, a jiny filesystem to delat nebude nebo bude jindy.
(to je ale na jinou debatu, pokud vas to zajima tak si muzeme nekde pokecat mimo Roota).

* mimochodem O_DIRECT si hodne lidi vyklada jako synchroni blokujici operaci ale tahle zaruka v linuxu take neni - v praxi se to tak chova a nikdo to neresi.

** nemusi to byt diskem ale radicem, ktery nestiha tolik IO operaci . V pripade barrier jich tam tece proste vic (napriklad 2x tolik kdyz se testuje pres fio) a samotny pocet saturuje CPU radice. U 4KiB IO se to nepozna protoze tech ~140K IO operaci (=550MB/s) to pro benchmark da, jenze bariera je NOOP a hned je jich 280K... Da se pak rict, ze je pomala bariera?

2) mkfs defaultne dela TRIM celeho block device, filesystem pri prepisu souboru alokuje pouze nove (clean) bloky takze neni co TRIMovat. Jenze zkuste ten filesystem zaplnit a pak se zapnutym discardem psat do tablespace - zpomali se to zasadne.
Zalezet bude ale take na velikosti IO operace, protoze ne kazda spusti discard.

Starsi data zde:
http://people.redhat.com/lczerner/discard/ext4_discard.html

(dnes to bude o neco rychlejsi protoze disky podporuji NCQ/TRIM - pokud tedy mate spravny firmware, jinak vam to ani sezere data :))

3,4) diky - je videt ze jste na to myslel. Erase block size bude IMO mnohem vetsi nez 1MB, ale v realu je to uplne jedno.

5) takovy tip - zkuste sar. Na ad-hoc veci to uplne staci (a defaultne je to casto zapnute a nikdo o tom nevi).

Par zajimavosti co si muzete zkusit (a pak premyslet wtf, dopredu nelze rict co to udela a na cem to zavisi)

1) pouzit cfq scheduler s rotational=1 na SSD disku - nektere benchmarky vyjdou lepe :-) proc?
2) vypnout write cache na disku - nektere veci budou paradoxne rychlejsi
3) vyrobit RAID 1 na jednom disku - na starem kernelu to bude rychlejsi (a s nekterymi disky...)
4) pohrat si s rq_affinity scheduleru
5) predalokovat (zero, ne fallocate, pokud databaze umi) misto pro tablespace