Hlavní navigace

Vlákno názorů k článku Výkon databáze na různých souborových systémech od Jan Schermer - No offense, ale to je tedy benchmark... 1) nobarrier...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 10. 2015 11:11

    Jan Schermer (neregistrovaný)

    No offense, ale to je tedy benchmark...

    1) nobarrier zapne jenom sebevrah (neverte pohadkam o konzistenci s persistentni write cache) - navic to s Intel S3700 ani neni potreba, protoze cache je zalohovana a flush se vicement ignoruje.

    2) discard je uplne zbytecny a zpomaluje vsechny zapisy - porovnavat filesystem s discard a bez discard je uplne k nicemu

    S3700 je velice dobre SSD, tim se tyto problemy trochu smazou, ale vezmete cokoliv jineho a vysledky budou _dost_ jine

    3) Na zacatku prezentace se zminuje alignment na SSD, ale uz neni receno jaky teda pro ten benchmark byl

    4) jak se vytvarely filesystemy? Jake jsou completni pouzite mount options (neni default jako default).

    4) kde je graf CPU a IO po dobu tech benchmarku? Bez nich chybi podstatna cast pohadky...

  • 19. 10. 2015 12:27

    ByCzech (neregistrovaný)

    2) discard je uplne zbytecny a zpomaluje vsechny zapisy - porovnavat filesystem s discard a bez discard je uplne k nicemu

    U nového PRÁZDNÉHO disku možná, ale u když už disk nemá prostor kde zapisovat do nepoužitých oblastí, tak je provedení trimu (i jednorázově) jako injekce adrenalinu.

  • 19. 10. 2015 13:21

    Jan Schermer (neregistrovaný)

    U opravdu levnych SSD pomuze obcas udelat fstrim. Snad na nich ale nikdo neprovozuje databaze - jejich vykon je v tomhle smeru klidne nizsi nez u obyc disku.

    U modernich SSD, zvlast tech urcenych do serveru (DC rada Intel, Samsung...) fstrim vykonu nepomuze vubec a zivotnosti take spis marginalne (a az na konci zivota tech SSD). Dulezite to muze byt ve chvili, kdy potrebuju aby disk s 3 DWPD ratingem prezil o neco vic.

    Discard a fstrim je ale neco jineho, a discard zapinat je jednoznacne kontraproduktivni.

  • 20. 10. 2015 1:10

    ByCzech (neregistrovaný)

    Používám SSD, které umí queued TRIM a nemůžu s vámi souhlasit. Možná kdyby jste to něčím doložil, má zkušenost ať už s desktopem/note­bookem nebo serverem je opačná (navíc Samsung SSD je kapitola sama o sobě, ale marketing mají výborný, jen co je pravda).

  • 20. 10. 2015 14:59

    Jan Schermer (neregistrovaný)

    Pokud je ten NCQ Trim opravdu funkcni (co je to za SSD?) tak se nebude blokovat jine IO po dobu discardu a o vykon neprijdete - ja jsem takove SSD ale zatim v ruce nemel a ani jsem nevidel/nehledal benchmarky. Nulovy overhead tam nebude, ale v realu to bude opravdu neviditelne.

    Ano, pak ma cenu discard pouzivat misto fstrim - ja ale radeji jeste chvili pockam aby mi to kvuli nejake chybe tise nesezralo data.

  • 19. 10. 2015 16:10

    Tomáš Vondra

    1) nobarrier

    Prosím o nějaké odkazy nebo reference s informacemi - vždycky slyším akorát výkřiky jak je to špatně, ale žádné relevantní informace které by usvědčovaly nobarrier jsem zatím neviděl.

    Tvrzení že nobarrier na S3700 není potřeba (protože se stejně ignoruje) mi nedává smysl, protože vypnutím write barrier (tj. použitím nobarrier při mountu) vzroste výkon o ~30%. Což naznačuje že ono to s tím ignorováním nebude až tak úplně pravda.

    2) discard

    Pokud tvrdíte že TRIM zpomaluje všechny zápisy, bylo by fajn doložit to nějakými daty. V testech které jsem dělal já je dopad TRIM zanedbatelný - víceméně plus/minus 1% (alespoň na EXT4 a XFS). Takže jaké zpomalení?

    To že na různých SSD může být dopad různý - moje hypotéza je že to závisí mimo jiné na množství volného místa (ať už nevyužité místo na fs nebo overprovisioning od výrobce). Provedené benchmarky pracovaly s relativně malým objemem dat (vzhledem ke kapacitě disků) a moje očekávání je že při zaplnění bude mít TRIM větší význam (plánuji to otestovat).

    To že na nekvalitních consumer-level SSD se TRIM chová divně mne nijak nevzrušuje protože na OLTP databázi bych je nepoužil.

    3,4) alignment, mount options apod.

    Veškerá data jsou tady: https://bitbucket.org/tvondra/fsbench-i5

    Je to trochu hromada, ale v každém adresáři by měly být informace o alignmentu i mkfs volbách. Je fakt že "default" znamená různé věci podle kernelu, v tomto případě to znamená "jako ve 4.0.4 na gentoo".

    5) CPU a I/O

    Tohle nemám (ano, není to ideální) nicméně obecně platí že kromě small a medium r/o benchmarků je všechno I/O bound. V dalších testech napravím a mám v plánu sbírat i další metriky.

  • 19. 10. 2015 17:38

    Jan Schermer (neregistrovaný)

    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