Názory k článku
Tmpfs dostane v jádře 6.6 kvóty
-
Ondřej KolínZlatý podporovatelNejen pro /tmp podle všeho (Fedora 38):
tmpfs 32G 76M 32G 1% /dev/shm
tmpfs 13G 2.2M 13G 1% /run
tmpfs 32G 7.6M 32G 1% /tmp
tmpfs 6.3G 200K 6.3G 1% /run/user/1000 -
FíkZlatý podporovatelAno, ale můžete mít i více jak 50 % RAM zaplněné programy a pak k tomu 50 % tmpfs a najednou jste na suchu.
-
DannyStříbrný podporovatelSwap na SSD... po tom pri omezenem poctu zapisovych cyklu kazdy touzi, aneb proc si to uloziste neoddelat driv... :-)
-
Swap na SSD... po tom pri omezenem poctu zapisovych cyklu kazdy touzi, aneb proc si to uloziste neoddelat driv
Příklad ze života: ještě jsem se nedokopal vyndat ze svého hlavního desktopu (používán nejen pro osobní účely, ale od března 2020 i prakticky stoprocentní home office) minulý NVMe disk, na kterém jsem měl od října 2019 do července 2023 všechny aktivně používané filesystémy kromě velkého uložiště na věci, které jsou potřeba jen občas, a také swap. Tak jsem na něj ze zvědavosti pustil
smartctl:Data Units Read: 23,953,299 [12.2 TB] Data Units Written: 66,891,618 [34.2 TB] Host Read Commands: 958,435,861 Host Write Commands: 951,717,901 ... Power On Hours: 8,294
Životnost udávaná výrobcem je 300TBW, takže i kdybych pro jistotu počítal s polovinou, mohl bych ho tam při stejné intenzitě provozu mít ještě něco přes 12 let. Tož tak…
-
To je výstup ale ze skriptu, ne?
Je to část výstupu "
smartctl -a /dev/nvme0".A poradí si to s různými logickými a fyzickými sektory?
Měl by, jsou to informace přímo od toho disku a u klasického disku ty velikosti také ukazuje. Tady u toho NVMe ne, ale nevím, jestli tam vůbec dvě různé velikosti jsou.
-
U SATA to totiž u mě v takovém formátu výstup neprodukuje.
Obecně se poskytované informace mezi různými disky dost liší. Mimochodem, když si ta čísla vydělím, tak mi vychází, že data unit je u tohoto disku 0.5 MB (Samsung 970 EVO Plus 500GB), takže logické sektory to určitě nejsou.
Případně jakou máte verzi smartmontools? Mám 7.2.
Také 7.2 (openSUSE Leap 15.5).
-
Hlavně jsem se chtěl ujistit, když mám logik 512 a fyzik 4096, že mám počítat s těmi 4096. :-)
Jinak se divím jaký výpis vám to dává. Mně to jen vyblije u "tabulku" jako je to všude na obrázcích.
Ale v případě jednoho starého SSD teď nějak nemohu v té tabulce najít ten údaj zapsaných, ač to v něm je a někdy jsem to i viděl.A u obou SSD i to ukazuje nějak malá procenta u životnosti. Nedávno ještě byly 100% a 90%? Je to podezřelé. Zkusím na to ještě mrknout.
Novější má zapsáno 312.85 TB.
-
Strašák upsání SSD k smrti při běžném provozu nebyl ani před 10 lety.
Pro představu náhodný dnešní SSD disk pod 800 kč
AORUS Gen4 SSD 500GB - Limited warranty based on 5 years or 850TBW, whichever comes first.
https://www.gigabyte.com/us/SSD/AORUS-Gen4-SSD-500GB/sp#sp
Pro porovnání ne úplně levný disk pro velká NAS WD Red Plus NAS Hard Drive - Up to 180TB/yr workload rate
180 x 5 let = 900 TB (což mimochodem asi bude zápis + čtení dohromady).
https://www.westerndigital.com/products/internal-drives/wd-red-plus-sata-3-5-hdd#WD30EFPXTedy i úplně levné SSD vydrží dnes více nějaký lepší disk. Až nevydrží tak se holt po letech plácnete přes kapsu a koupíte si za pár stovek nový. V každém případě nějak dnešní SSD "šetřit" při běžném provozu nedává žádný smysl.
-
DannyStříbrný podporovatel
On ten strasak je ale z praxe... tech SSD, kde Wear Leveling dosel k cislu nikoliv vzdalenemu od nuly jsem uz videl taky dost :-) A fakt se nebavime o lowcost desktopovych SSD. Ono i dost zalezi, co je podle vas bezny provoz... on ten legitimni workload muze mit spoustu podob a jsou veci, kde na ten disk proste zapisovat potrebujete neco vic, nez logy u nejakeho LAMPu. Ale setrit krecovite na RAMce s tim, ze to kdyztak doswapuju mi prijde tak trosku jako chyba v sizingu hardware...
-
k3dARStříbrný podporovatelty hybernujes do RAMdisku ? jestli si odepsal SSD protoze si mel mene RAM nez potreboval tak chapu, ze sis to spatne navrhl ;-)
ale bezne se SWAP pouziva na obcasne uswapnuti a hlavne na hibernaci na disk a to opravdu SSD neoddela...
a z me praxe tedy SSD z NB ktery se hibernoval X let kazdy den sem menil vzdy se zlomkem opotrebeni jen kvuli tomu ze daval kapacitne vetsi ;-)
-
FíkZlatý podporovatel
Když chci paměť bez swapu, tak třeba mlock. Když udělám malloc, tak je na OS, co odswapuje. Pokud teda swap mám. V současnosti spousta lidí swap ani nemá.
-
S tím hintem pro malloc je problém. Co přesně by měl dělat? Selhat když je moc paměti zabrané? Ale rozumný OS udržuje paměť plnou a vyhazuje věci až podle potřeby, protože prázdná paměť je k ničemu.
A pak jsou tam i další divočiny. Třeba Linux vám fyzickou paměť nedá při volání toho mallocu, ale až ve chvíli kdy se do té paměti pokusíte něco zapsat.
-
Hlavně samotný
malloc()je čistě v režii glibc, alokace z OS se obvykle provádí pomocímmap().Alokace "já tu paměť vlastně nutně nepotřebuju, tak mi ji dej jen kdyby nebylo potřeba něco odswapovat" moc smysl nedává. I kdyby to tak fungovalo, hned vzápětí si někdo jiný naalokuje další kus paměti a jsem tam, kde jsem byl.
-
Že je malloc v režii glibc je už vedlejší. Stejně jenom přerozděluje mmapované bloky, takže by ten hint mohl jen předat dál.
Jiná věc je, k čemu by to vůbec bylo dobré. Použít nějaký pomalejší algoritmus bez pomocné paměti? Takové možnosti se podle mých zkušeností vyskytují minimálně. Řídit tím nějakou aplikační cache? Taky nic moc. Navíc jakákoliv větev programu, která přijde na řadu jen ve vzácných případech, bude nadprůměrně zabugovaná.
-
Ano - selhat.
viz vyse Fik-ovo mlock(), je tam rezim ze po mlockall() pak malloc() selze, ale jestli dobre chapu tak se to odviji od soft limitu pro locked pages, ne od dostupne pameti.
Ono celkove je malloc malo flexibilni, treba kdyby jste se snazili zapinovat svuj proces do urciteho numa nodu a pak alokovat pamet blizkou (a zde znova - kdyby nebyla blizka, selhat.. ale alokace vzdalenejsi uz je tedy dost ulet.. co pripomina pokusy s TTL na tcp, protoze "cena" muze byt ve vice nez 2 urovnich)
-
je tam rezim ze po mlockall() pak malloc() selze, jestli dobre chapu tak se to odviji od soft limitu pro locked pages, ne od dostupne pameti
Ono to není navrženo pro ten účel, který si představujete. Typické použítí jsou třeba citlivá dočasná data, u kterých nechcete, aby se náhodně zapisovala někam na disk.
Ono celkove je malloc malo flexibilni, treba kdyby jste se snazili zapinovat svuj proces do urciteho numa nodu…
malloc() je jednoduché vysokoúrovňové rozhraní, které většinou jen přerozděluje paměť naalokovanou jiným mechanismem. Pokud chcete něco složitějšího, pro co je potřeba spolupráce s operačním systémem, nezbývá než na
malloc()zapomenout a použít přímommap()a případně další související funkce. -
A k čemu přesně takové selhání má být? Co vlastně ten program má (nebo může) udělat, pokud nemůže alokovat paměť? Třeba v C++ má std::bad_alloc obvykle speciální podporu, aby ji při selhání alokace šlo vůbec vyhodit a nebyly potřeba další alokace. I blbé vypsání zprávy pro uživatele si v dnešní době často alokuje nějaké pomocné řetězce.
Ale možná je jen problé, že selhání toho mallocu chápu jako něco lepšího než tvrdý pád procesu na hubu.
-
Treba adaptivni zpracovani velkeho souboru dat - bez nutnosti uzivatelske konfigurace poctu ci velikosti "bloku".
Rekneme pattern matching v obrazcich, kde srovnavate kazdy-s-kazdym, tj. neni to obycejne proudove zpracovani dat, ale potrebujete drzet co nejvetsi matici.
Alternativne napr. render cache ve video editoru - jak program pozna, kolik dekomprimovanych frejmu si muze pamatovat v ram, kdyz neexistuje nejaky soft-fail-malloc (takze vlastne aplikacni cachovani mezivysledku).
-
Ten velký soubor dat si můžu mmapnout celý a alokovat si jen to, co potřebuju pro zpracování. Pak mi celé cachování řeší OS za mně.
Ten video editor si může pamatovat jen nutné minimum framů. Dekomprese videa není zas tak drahá, obzvlášť s hw akcelerací. Drahé jsou samotné úpravy a následná komprese. Ale tam už je zase docela pevně dané, kolik paměti bude potřeba.
Ten pattern matching by se dal. Ale i tady můžu mít konfigurovatelné množství použité paměti - a default nastřelit podle velikosti fyzické paměti. Přijde mi to daleko míň křehké, než ten soft fail malloc. Adaptivně reagovat na zmenšení dostupné paměti ten malloc taky nemůže.
-
Ten velký soubor dat si můžu mmapnout celý a alokovat si jen to, co potřebuju pro zpracování. Pak mi celé cachování řeší OS za mně.
Nemuzete. Viz treba metody vypoctu linearnich rovnic - muzete na to jit naivne jak vas to ve skole ucili, ale to vam zadna OS cache nepomuze, protoze vzdy budete pristupovat k prvku ktery v cache neni.
Anebo muzete na to jit chytreji, podle nejakeho paperu, kde se resi pocitani skrze lokalni sub-bloky, ktere se vejdou do prime pameti a nenastava cache-trashing.
-
Ten video editor si může pamatovat jen nutné minimum framů. Dekomprese videa není zas tak drahá, obzvlášť s hw akcelerací. Drahé jsou samotné úpravy a následná komprese. Ale tam už je zase docela pevně dané, kolik paměti bude potřeba.
Ano, bude potreba presne X pameti na 1 frame, a pokud jich chci cachovat N v okoli kurzoru, tak je to N*X. Vy znate X, ale neznate N, ktere lze odvodit od velikosti volne ram. Dnes se to bohuzel resi cachovanim na disk, protoze 1/ cena za spocteni frame je vetsi nez disk io a 2/ disk vam udela soft-fail, kdyz mu dojde misto - a tohle je to co resim, proc se tak nechova i ram, bez nutnosti nastavovat limity predem.
-
Reagovat na zmenseni pameti malloc fakt nemusi, - typicky neprovozujete memory hotplug aby ram byla fakticky odebrana, a i v pripade RAS je pamet predem/live mirrorovana, takze pri vyrazeni vadne dimm to pojede ze zalozni a pak musi operator rest co s tim.
-
Pokud mate namapovane bloky do fyzicke pameti, tak vam je nema jak kdo sebrat. Ten dalsi proces pak holt nespustite, resp. jeho alokace skonci swapovanim, nebo padem. A dokud nezasahne OOM a neodkrouhne ten nas pametove zravej proces, tak plati pravidlo prvni bere - samozrejme pocitam s tim ze se tam zavola mlock()
Ta virtualni pamet a stav "mozna to bude swapovat, mozna to spadne, mozna to zabije jine procesy" neni uplne prijemna - stejne tak jako velikost int-u v C, ze si nemuzete byt jisti, zda je to 32 nebo 64bit, takze se na takovem plytkem zaklade nedaji stavet zadne robustni reseni. Nuz na typy alespon existuje stdint.h
-
Tu paměť ale nemusí chtít jen další proces. Stačí další stránka pro zásobník, nebo nějaká podobná alokace v rámci vlastního procesu.
Pořád nevidím důvod, proč se babrat s tím zamykáním. Když mám ten stroj pro sebe a pod kontrolou, pak zjistím limit pro alokace celkem jednoduše z množství dostupné fyzické paměti. A když ho pod dostatečnou kontrolou nemám, tak nejspíš při nějakém brutálním zamykání skončím procházkou po minovém poli.
-
"Ano, ale můžete mít i více jak 50 % RAM zaplněné"
A neni to nahodou uplne jedno? tmpfs se pouziva primarne proto, ze hloupe aplikace misto aby pouzily ram zapisuji na disk.
Rek bych ze je uplne jedno jestli ramka dojde proto, ze ji zaplni tmpfs nebo proto, ze ji zaplni aplikace. Ani v jednom pripade jakekoli kvoty nic neresi. Tak maximalne zabiji vykon.
-
SinuhetStříbrný podporovatel
Ta už, ehm, je.
Kromě toho, že existuje safe-rm jako bezpečný wrapper pro rm, tak rm, pokud vím, už docela dlouho má parametr --no-preserve-root, bez kterého nefunguje rm -rf /. -
Vždycky je rozumné předpokládat, že obsluha chybuje. "Design induced operator error", nebo specifičtější "design induced pilot error" jsou docela známé věci.
I správce je jen olysalá opice s omezenou mentální kapacitou. V ideálních podmínkách zvládneme udržet v hlavě tak 10 věcí. Rozdíl mezi nějakou jednoduchou a bezpečnou akcí a ničivým průserem by měl bít do očí. Pokud stačí překlep, je to špatně.
A proto má i to rm přidané pojistky :)
-
To je něco jiného, RDa mluví o tom, že nepoužije-li se u tmpfs filesystému parametr
size, který určuje jeho maximální velikost, default je hodnota "50%", což znamená polovinu velikosti fyzické paměti. Takže i když nejsou nastavené kvóty, nemůže neprivilegovaný uživatel zaplněním tmpfs spotřebovat veškerou fyzickou paměť. Tedy aspoň za předpokladu, že je na systému jen jeden tmpfs s defaultní hodnotousize, na kterém má právo zápisu.
ČLÁNKY DO MAILU
