Dotaz: DM-cache (nejasnosti)

[PetebLazar]

Má někdo zkušenost s nastavením thresholdu dm-cache ve smyslu, že se tato nebude vyhýbat cachování sekvenčních IO operací? Idea je před RAID5(mdadm) pole (4x8TB) předřadit 2TB NVMe dm-cache ve snaze zajistit rychlejší náhodný/sekvenční přístup k naposledy uloženým/využívaným datům (cca 1-2TB záběrů)?

Je správný předpoklad, že po nahrání dat na origin device zkrze dm-cache bude vlastně předcachováno ve prospěch následných čtecích operací (těchto dat)?

Netuším nakolik ZFS (ARC/L2ARC/SLOG/ZIL/..) jsou funkční alternativou bez výrazně vyšších HW nároků. Cílem je v ideálním případě dosáhnout při čtení průchodnosti v řádu GB/s (na cachovaných datech).

Odpovědi

[Max]

Nemám s tím zkušenosti, ale podle dokumentace si myslím, že tebou zamýšlené funkcionality docílit nejde. Kromě toho, že sekvenční operace se nekešují, tak i dost těžko ovlivníš, co v té keši chceš mít. Samozřejmě můžeš zkusit nastavit nějakou monstrózní velikost u "sequential_threshold", aby se kešovaly i sekvenční operace a "read_promote_adjustment" nastavit na něco malého, aby se ti kešovalo skoro všechno, co budeš číst, ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci :-/. Navíc na to SSD pak budeš i ve velkým zapisovat i jen při samotném čtení, což nebude asi také moc ok.
Dále tím, že zapisuješ, děláš write keš, nikoli read keš. Takže samotným zápisem dat si read keš nevytvoříš. Read keš si vytvoříš opakovaným čtením stejných dat.

Nemůžeš si udělat workflow dat v rámci userspace? Něco v tom smyslu, že když budu s něčím potřebovat operovat, tak si to nejdříve nahraju na to NVMe, tak si s tím budu hrát a pak to hodím zpět na to pole?

Pokud jde o ZFS, tak tam pro kešování slouží L2ARC, ale opět, jedná se o kešování dat, která často používáš. Tj. podobný případ jako výše. Ale také nemám reálné zkušenosti, nepoužívám L2ARC, jen SLOG (= write cache).
Zdar Max

[PetebLazar]

aby se kešovaly i sekvenční operace a "read_promote_adjustment" nastavit na něco malého, aby se ti kešovalo skoro všechno, co budeš číst, ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci

Já měl za to, že metadata-device udržuje seznam bloků uložených v cache-device, tj. jak těch načtených při čtení tak těch určených k zápisu na origin-device(dirty blocks). Proč by se muselo znova cachovat čtením z origin-device, když úspěšně propsaný dirty block obsahuje shodná data (jako origin-device).

Navíc na to SSD pak budeš i ve velkým zapisovat i jen při samotném čtení, což nebude asi také moc ok.

Pokud se budou číst stejná data (scrubbing po timeline), mělo by to na základě existence daných bloků v metadata-device snad pouze přečíst odpovídající bloky z cache-device?

ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci

Pokud diskové operace v rámci aktivního projektu probíhají na 1TB+ dat z obsahu filesystému mělo by cache-device 2TB být schopno obsahovat prakticky vše k čemu se přistupuje? Prakticky "FIFO", pokud by vše mělo stejnou váhu.

Nemůžeš si udělat workflow dat v rámci userspace?

Ano to mám jako náhradní řešení. Aktivní data leží v /NVMe/xyz a je na ně vytvořen symbolický link z /mount_raid5/xyz, který se využívá v rámci projektu (kromě toho leží stejná data ještě v /mount_raid5/xyz.hdd jako redundance). Po ukončení zpracování se link zrusi a přejmenuje xyz.hdd na xyz, cimz je v budoucnu zajisteno zachovani schodne cesty jako te pouzite v rámci referenci na klipy v projektu.

Bude to chtit praktický pokus.

[Max]

Rozlišuje se keš pro zápis a keš pro čtení. Aby se ti něco dostalo do keše pro čtení, musíš to nejdříve přečíst. Tím, že něco zapisuješ nedostaneš data do keše pro čtení.

Nejspíše je tedy pak průběh následující :
1) pošleš zapsat soubor "test.txt"
2) dostane se do write cache (seznam dirty blocks určený pro zápis), tedy pokud bude zápis odpovídat definovaným politikám
3) na pozadí se data dozapíší na origin device
4) až budou data úspěšně zapsána, v keši nic nebude (metadada-device a metadata-cache by měly být prázdná)
5) přečteš jednou soubor "test.txt" z origin device
6) pokud budeš mít "read_promote_adjustment" nastaven na velkou hodnotu, tak se soubor do keše nemusí dostat
7) v keši vydrží tak dlouho, dokud ho z ní nevytlačí nějaká jiná data, což se stane až se začne keš plnit na max

Hodnoty se definují v rámci IO, aspoň tak je to ve zdrojákách:

read_promote_adjustment:    READ io, default 4
write_promote_adjustment:   WRITE io, default 8
discard_promote_adjustment: READ/WRITE io to a discarded block, default 1

Takže nezajistíš, aby se zapisovaný soubor udržel v cache hned automaticky pro čtení. Aspoň tak mi to dle dokumentace vychází. Každopádně asi si zkusím ve volné chvíli udělat nějaký test, docela mě to zajímá, jak se to reálně umí chovat.
A nebo se tu k tomu vyjádření opravdu někdo, kdo to blíže zkoumal a testoval.
Zdar Max

[PetebLazar]

Díky za detailní rozbor.

Vyhradil jsem na pokusy 500GB SATA III SSD (to by v sekvenčních rychlosti čtení mělo cca odpovídat RAID5 ze čtyř 7200rpm disků) a 1TB NVMe Samsung 970 Pro (MLC 2-bit).

metadata/cache-device

dev/nvme0n1:
 Timing buffered disk reads: 9414 MB in  3.00 seconds = 3137.43 MB/sec

origin-device
/dev/sdf:
 Timing buffered disk reads: 1526 MB in  3.00 seconds = 508.19 MB/sec

[PetebLazar]

Pouzit LVM postup

Zápis prakticky rychlostí SSD (WD500 Blue)
time dd if=/dev/zero of=/raid5/bigshit2  bs=1M count=32768 
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 117,671 s, 292 MB/s

real	1m57,677s
user	0m0,020s
sys	0m23,641s

Prvni cteni (cache na NVMe se dle iostat  plni)
time cat /raid5/bigshit2  >/dev/null 

real	2m8,042s
user	0m0,110s
sys	0m12,518s

prvni cteni nacachovanych dat 32GB file
time cat /raid5/bigshit2  >/dev/null 

real	0m33,120s
user	0m0,050s
sys	0m9,654s

druhe cteni nacachovanych dat 32GB file
time cat /raid5/bigshit2  >/dev/null 

real	0m14,718s
user	0m0,037s
sys	0m6,437s

(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 
real	0m28,535s
user	0m0,046s
sys	0m8,966s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m14,718s
user	0m0,037s
sys	0m6,437s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m11,885s
user	0m0,029s
sys	0m6,244s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m13,743s
user	0m0,045s
sys	0m6,997s

dle iostat cteni z NVMe(cache device) spickove presahuje 2GB/s

Pozn. RAM je 32GB, takze by se tam 32GB soubor nemel soubor vejit (zkusim radeji soubor 96GB).

[PetebLazar]

test na 96GB file

zapis na origin storage (limit SATA SSD)
time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304
98304+0 records in
98304+0 records out
103079215104 bytes (103 GB, 96 GiB) copied, 375,234 s, 275 MB/s

real	6m15,255s
user	0m0,041s
sys	1m13,642s

prvni cteni (plneni cache)
time cat /raid5/bigshit3  >/dev/null 

real	6m14,875s
user	0m0,310s
sys	0m35,797s

prvni cteni s vyuzitim cache prumerne >1,5GB/s
time cat /raid5/bigshit3  >/dev/null 

real	0m58,806s
user	0m0,113s
sys	0m27,762s

druhe cteni s vyuzitim cache
time cat /raid5/bigshit3  >/dev/null 

real	0m51,978s
user	0m0,107s
sys	0m26,724s

Vypada to, ze dochazi k aktualizaci metadat (zapisy na NVMe pri cteni), asi pro statistiky cetnosti vyuzivani dat (idealni by bylo kdyby toto slo vypnout, donutit to aby to nedavalo prednost zadnym datum).

Potvrdilo se, ze zapsane informace se nepouziji pro read-cache. Znamenalo by to v ramci naplneni cache je po nakopirovani jednorazove vycist do /dev/null. Pokud se to ovsem nebude chovat jako ciste FIFO (proc jinak ty zapisy pri cteni), neni garance ze se s novym projektem nova data dostanou do cache (statistiky vyuzivani dosavadnich dat by mohly prevazit?). V pripade takoveho chovani by se cache by se asi nejspis musela znovu reincializovat, aby se umoznilo naplneni novym obsahem.

Pri praci s timeline nemusi byt cten cely soubor (scrubbing jde po datově vzajemne vzdalenych snimcich). Bez prednaplneni cache by se stridaly rychle dostupne (jiz nacachovane snimky) a ty pomale (ktere jeste nebyly nacteny/obsazeny v cache).

Vypada to, ze to funguje, ale pro dany ucel mam obavu ze to bude z hlediska cache-hit ratio asi nevypocitatelne. Dana uloha je asi prilis vzdalena cilum tohoto reseni.

[Max]

Díky za info, takže se to chová dle předpokladu.
Jinak pokud jde o ten větší zápis při dalších čtení, může to být tím, že při prvním čtení není celý soubor v read cache . Ostatně to by pak i vysvětlovalo, proč další čtení (v příkladu třetí) jsou o kapánek rychlejší, než to první z cache (v příkladu to druhé čtení).
Zdar Max

[PetebLazar]

Jestli to používá LRU tak to pravděpodobně musí občas aktualizovat metadata (pouze v RAM si to asi neudrží). Chtělo by to samostatný device pro metadata, pak by to bylo ještě zřejmější.

[j]

Rek bych, ze ten tvuj test je dost postavenej na vode.

1) neco zapisujes => laduje se to do cache (nejen na SSD, ale i pripadne do RAM). 1,5) .... ta cache se v ocekavani dalsich zapisu prubezne vyprazdnuje 2) zacnes neco cist, ale z cache to uz bylo vyhozeno.

Tvuj problem spociva v tom bode 1,5, coz IMO muzes pomerne razantne ovlivnit (= jak rychle se ti misto v cache bude vyprazdnovat).

A mimochodem 292 MB/s by odpovidalo tomu, ze se zadna cache pri zapisu nepouzije, coz je i standardni nastaveni pri linearnim zapisu (da se to zmenit). I Satovy SSD by prelezlo 500MB/s. Takze jak chces zjistovat, jestli v ni neco je, kdyz si do ni nic neulozil?

---

Dete s tim guuglem dopice!

[PetebLazar]

Bavíme se stále o fungování dm-cache?

Ty hodnoty v testech odpovídaly průběžným hodnotám z iostatu (jak při plnění obsahu na SSD-origin-device .. sustain write cca 250MB/s jde o levné TLC SSD, zápis do NVMe cache-device při prvním čtení dat z origin-device, tak následné čtení cca 2GB/s+ z NVME cache-device při opakovaných čteních z origin device.

[Max]

Podle mě "j" nepochopil, jak dm-cache funguje a o čem je tu řeč, jinak si tu jeho poznámku nedokážu vysvětlit.
Zdar Max

[PetebLazar]

Taky jsem získal ten dojem.

Teď se vyprodávají malé M.2 Optane 32GB, ten by jako metadata device mohl být vlastnostmi zajímavý. Je to dnes asi mrtvá technologie, ale za zkoušku stojí.

[PetebLazar]

32GB M.2 Optane dorazil

Jak zmiňuje specifikace rychlost sekvenčního čtení je okolo 1350MB/s (zápis asi 290MB/s).

sudo hdparm -t  /dev/nvme1n1
/dev/nvme1n1:
 Timing buffered disk reads: 4008 MB in  3.00 seconds = 1335.94 MB/sec

Výdrž má být 182,5TBW, což při velikosti 32GB znamená cca 5840 úplných přepisů.

Velikost struktur metadata-device se údajně stanovuje výpočtem 4M + (16 * velikost_cache_device / velikost bloku), což by při 1TB cache-device a 256KB bloku představovalo asi 65MB (0,2% kapacity Optane).

Zařízení disponuje dvěma PCIe 3.0 linkami, což ukazuje i lspci.

41:00.0 Non-Volatile memory controller: Intel Corporation Device 2522 (prog-if 02 [NVM Express])
	Subsystem: Intel Corporation Device 3806
...
		LnkCap:	Port #0, Speed 8GT/s, Width x2, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited
			ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 8GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
...
	Kernel driver in use: nvme

[PetebLazar]

Stejný pokus jako včera, pouze cache-meta umístěna na M.2 Optane.

Plnění origin-device daty, u cache=device a meta-device drobné zápisy (asi čtení struktur FS). Včerejší pokus byl patrně zpočátku ovlivněn LAZY mkfs.ext4. Dnes jsem nechal přípravu FS odeznít.

time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304
98304+0 records in
98304+0 records out
103079215104 bytes (103 GB, 96 GiB) copied, 377,044 s, 273 MB/s

real	6m17,111s
user	0m0,046s
sys	1m12,945s

První čtení souboru z origin-device a plnění cache-device

time cat /raid5/bigshit3  >/dev/null

real	6m8,772s
user	0m0,280s
sys	0m36,910s
 

Druhé čtení souboru z origin-device (vypada to, že při prvním čtení se nenacacheovala všechna data, čte se i z origin) .. průměrná rychlost 96GB/83s cca 1GB/s+

time cat /raid5/bigshit3  >/dev/null

real	1m23,199s
user	0m0,123s
sys	0m29,300s

Třetí čtení souboru z origin device

 time cat /raid5/bigshit3  >/dev/null

real	1m18,568s
user	0m0,140s
sys	0m30,340s

Čtvrté čtení (podíl nacachovaných dat se zvětšuje)

time cat /raid5/bigshit3  >/dev/null

real	1m6,874s
user	0m0,148s
sys	0m30,356s

Páté čtení

time cat /raid5/bigshit3  >/dev/null

real	0m53,109s
user	0m0,114s
sys	0m30,113s

Šesté čtení

time cat /raid5/bigshit3  >/dev/null

real	0m46,084s
user	0m0,120s
sys	0m29,251s

Sedmé čtení

time cat /raid5/bigshit3  >/dev/null

real	0m42,074s
user	0m0,124s
sys	0m29,348s

Sedmé čtení

time cat /raid5/bigshit3  >/dev/null

real	0m40,288s
user	0m0,104s
sys	0m29,255s

Osmé čtení (z originu se čtou v průměru pouze jednotky MB/s)

time cat /raid5/bigshit3  >/dev/null

real	0m38,916s
user	0m0,123s
sys	0m29,540s

Deváté čtení (z originu se během celého čtení 96GB načetlo odhadem asi 10MB) .. 96GB/40s = 2,4GB/s

time cat /raid5/bigshit3  >/dev/null

real	0m38,644s
user	0m0,130s
sys	0m29,469s

Algoritmus pro cachování má svou hlavu.

Perlička na závěr, mountpoint /raid5 nebyl nejšťastnějším. Právě mi do něj vlezl TimeShift a pokouší se bigshit3 zálohovat.

[Max]

Cache slouží k urychlení přístupu k datům, tj. nelze očekávat, že tam budeš mít celý soubor 1:1, což ale nijak nevadí.
Zdar Max

[Aleš Kapica]

No. Hlavně by asi mělo zaznít, že hlavním cílem je urychlit práci se soubory. Rotačním diskům vyhovuje sekvenční zápis, takže ta keš by měla podle nějakých parametrů shromáždit blok dat k zápisu a ten následně zapsat.

Systém předá data DM-cache, ta mu potvrdí příjem a tím považuje I/O operaci za dokončenou. Bez DM-cache by musel čekat, až příjem potvrdí všechny disky RAIDu.

Jestli to funguje i pro čtené nevím. Blbnul jsem s tím už hodně dávno. Každopádně pokud tam někdo navalí tolik dat, že zaplácne kapacitu toho kešovacího disku, tak to stejně bude čekat, než se to zapíše na ty disky rotační.

A taky je na místě upozornit, že se tímto způsobem ten NVME disk extrémně rychle opotřebovává, pokud je těch I/O operací moc a ve velkých objemech.

[PetebLazar]

O urychlení zápisu v tomto use case nejde, takže se vystačí s defaultní write-thru policy (nepozoroval jsem zapisy do cache-device při nahrávání dat na origin-device).

Cílem je umožnit maximálně procachovat na poli umístěnou podmnožinu velkých souborů (B-RAW) využívaných v rámci aktivního projektu (NLE). Tyto soubory dosahují bitrate v řádu stovek MB/s. S ohledem na pokles sekvenční rychlosti HDD s úbytkem počtu sektorů směrem ke středu zajištění vyšších rychlostí ~1GB/s vede k polím s větším počtem členů (latence typické). V případě umístění zájmových souborů v NVMe cache je možné docilit zajímavých rychlostí čtení (včetně latencí) i při HW slabším poli. Amortizace NVMe zápisem by nemusela být problémem, ve zcela ideálním případě se do něj zapíše pouze objem odpovídající souhrnu objemu aktivních projektů. Samozřejmě za předpokladu, že aktivní(zpracovávaná) data v daném okamžiku nepřesáhnou velikost NVMe cache.

[Max]

Má poznámka se vztahovala k read cache, která se tu řeší.
Zdar Max