Vlákno názorů k článku
Linus měl problémy s vadnou pamětí v pracovním počítači
od martinpoljak - Na druhou stranu, přemýšlím, kolik počítačo-let mi RAM...
-
Tady nejde o to, jak dlouho paměť vydrží, to ECC neřeší. Smyslem ECC je předejít "silent data corruption", tedy poškození dat v důsledku chyby paměti, kterého si nevšimnete, protože nemáte žádný kontrolní mechanismus, který by ho odhalil. Tady to způsobilo ICE, ale ten může mít i spoustu jiných příčin a vadná paměť není obvykle to první, co by člověk prověřoval (aspoň pokud se to nestane krátce po instalaci nových modulů). V horším případě ale může dojít k tomu, že poškozená data uložíte a pak se s nimi dál pracuje, aniž by kdokoli věděl, že jsou poškozená.
-
Zjistit to mohu tak, že něco nefunguje jak má (tak, jako Linusovi). Což se ostatně už někdy stalo určitě i vám. A pokud to fungovalo jak má, pak mi může být jedno, že byl/je nespolehlivý a spolehlivost je tedy zjevně pro běžné desktopové použití dostatečná. Nikde jsem nepsal, že jsem si něčím byl jistý. Ani to není podstatné.
Běžný desktop není server pro sto zákazníků, nemá na něm být SLA 99.99 % ani na něm neběží kritická infrastruktura. A ano, samozřejmě vím, že pro ne úplně malou část čtenářů root.cz je zcela nepochopitelné, že lze bez ECC spokojeně žít.
-
Vtip je v tom, že zapíšeš 1 a přečteš 0. Nemáš žádnou šanci zjistit, že to je špatně. Může se to stát i na úplně perfektně fungujících modulech. Klidně jen jednou nebo jednou za několik měsíců. A samozřejmě bude trvat roky, než přijdeš na to, že je něco špatně, pokud na to vůbec přijdeš. Proto se tomu říká silent data corruption. Ne vždycky se chyba projeví tak jako Linusovi.
-
Já to samozřejmě chápu. Ale pokud mě to nějak neobtěžuje, může mi to být celkem jedno. A protože to je desktop a ne server s daty zákazníka, ani mě nikdo nezažaluje za to, že mu přehozenej bit poškodil třeba databázi.
Moc ale nechápu, co řešíme. Celým tím jsem chtěl říci, že výrobci desek ECC paměti neřeší možná třeba proto, že se bez ECC dá docela spokojeně žít. Reálně ho atokonto velká část uživatelů prostě nepotřebuje. Takže proč by z něj neudělali prémiovou vlastnost?
-
Zjistit to mohu tak, že něco nefunguje jak má (...) A pokud to fungovalo jak má, pak mi může být jedno, že byl/je nespolehlivý a spolehlivost je tedy zjevně pro běžné desktopové použití dostatečná.
Nepoznáte to, není to pass/fail.
V consumer aplikacích je drtivá většina obsahu paměti multimedia (buffery videa, framebuffery, textury, 3D geometrie, ...) ve které se náhodný bit flip projeví jako lokální málo postřehnutelný artefakt: prsknutí v hudbě, "kostičky" ve videu, proužek na textuře, ostrý polygon na modelu ve hře. Pokud k tomu dojde při zápisu na disk, tak je škoda trvalá. Děje se to běžně (několik událostí za měsíc a GB v DDR4).
-
Tohle si pamatuju z dávných dob. Člověk udělal zálohu fotek (JPG) ze starého disku nebo počítače na nový a po letech si všiml, že v nějaké je chyba (pokud větší, tak od půlky obrázku dolů např. nesmyslné barvy). Byl problém v RAM, přes kterou ta data tekla? Ve zdrojovém nebo cílovém disku? V přenosu po LAN? Tohle v domácích podmínkách člověk nemá přímo ošetřené. I když stabilita jednotlivých komponent asi vzrostla, protože se s tím v posledních letech setkávám méně až vůbec (ale je fakt, že toho na PC takto dělám méně).
17. 10. 2022, 16:44 editováno autorem komentáře
-
FíkZlatý podporovatelNevím o tom. Toto je sice staré, ale mají tam DDR2 a vliv teploty taky. Asi je rozdíl, jestli chcete detekovat náhodné překlopení třeba 1 bit za rok v 1 TB RAM, s čímž se asi nedá nic dělat (kosmické záření, radioaktivní pozadí). Nebo chcete ECC použít k tomu, abyste našel a vyměnil vadný DIMM, který chybuje daleko častěji.
-
Dnešní paměti jsou tak spolehlivé, že ECC se nevyplácí. za dva roky s 64GB DDR4 ECC jsem v logu neviděl žádnou událost.
DDR5 mají on-die ECC, takže bit rot ne v podstatě vyloučený.
Největším nepřítelem dat dneska je porucha napájení, porucha celého DIMM, porucha CPU.Pokud se bavíme o RAM, mnohem větší smysl má zrdcadlení kanálů RAM, protože dokáže ochránit proti selhání DIMM a selhání paměťového řadiče.
-
Muzete nejak dolozit to "deje se to porad"? Mam v serverech dohromady 1TB pameti s ecc, zapnuty memory patrolling a reportivani 1bit chyb a za poslednich 5 let nic.
Doma mam pocitac s 256GB RAM bez ecc z toho bezne 128+ obsazeno (cele stado virtualnich pocitacu). Statisticky by se za ~3 roky co ten pc mam neco muselo trefit do mista, ktere by zpusobilo pad hosta nebo nektereho z guestu ... a take nic.
-
a jaké chyby to reportuje, jen ty urecoverable?
Asi nejrozsáhlejší studie je 12 let stará, http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf, probíhala dva a půl roku s několikatisíci servery. Vyšel jim průměr mezi 14 - 40 1bit chyb na každý gigabit paměti. Ty tady tvrdíš, že 5 let nemáš žádnou chybu, z mých zkušeností to je těžko uvěřitelné číslo, spíše koukáš na jinou metriku než o které se bavíme.
Stejně tak tady už nějakou dobu máme útok Rowhammer/ECCPLOIT, který způsobuje právě flip bitů sousedících buněk, tady na rootu se o tom píše pravidelně již několik let. Ukázkových a testovacích nástrojů máš celou řadu, můžeš si sám vyzkoušet jak je tvůj monitoring spolehlivý a jak probíhá silent corruption pamětí.
Na tohle se těžko argumentuje, protože pořád se bavíme o statistice a šanci, že něco nastane. Vždy v takovýhle případech můžeš vytáhnout příklad, který podpoří kteroukoliv verzi.
-
Ok, pojdme pryc od statistiky a vyzkousejme tvoje cisla aplikovat do praxe.
Pojdme odhadnout, kolik pameti je natolik kriticke, ze flip bitu v ni zpusobi pad OS. Dovolim si tvrdit, ze bit flip v executable casti jadra vetsiny pouzivanych subsystemu a ovladacu bude znamenat oops, bit flip v kodu syscalu zpusobi, ze se bude hroutit userspace. Dale jsou kriticke datove struktury, kde bitflip zpusobi skoro jiste pad. Ignorujme male veci jako tabulky procesu atd. a zamerme se na velke. Nejvetsi bude na tuty tabulka PTE stranek. To je steuktura velka 32bit na kazdou 4KB stranku + nejaky overhead. Separatne uvazme exe/lib casti softu v userspace a jejich data (interni datove struktury, nikoliv multimedia), ty budou pusobit pady tech aplikaci. Separatne uvazme velke struktury ve SLABu, treba DENTRY cache atd. kde by flip mohl pusobit divne chovani a to jeste jen nekdy (kdyz se zrovna dana DENTRY pouzije).
Dovolim si tvrdit, ze takovy bezny desktop bude mit minimalne 128MiB pameti (tedy jeden gigabit), kde flip zpusobi brzky pad OS. Dale pak 512MiB (4 gigabity) pameti, kde flip bitu zpusobi s velkou pravdepodobnosti problemy v userspace.
Pri 14 flipech na gigabit na mesic to znamena v prumeru 14 padu OS na mesic a 56 mist, ktere s velkou pravdepodobnosti zpusobi problem v userspace (pri dlouhem uptime a/nebo suspend to roam/hibernaci) se tohle navic bude kumulovat. A to jsem bral minimalni odhady uplne u vseho.
Slucuje se ti to s realitou, kterou pozorujes v beznem svete, nebo jsi ochoten uznat, ze to je cele jeden velky BS?
-
Jeste jedna snadno overitelna metrika, kterou si ostatne kazdy muze snadno vyzkouset, me napadla. Po sestaveni sveho PC jsem ho nechal projet 24h memtestem. 2 terabity po dobu jednoho dne pri 14-40 flipech na mesic a gigabit - statisticky mel memtest odhalit 955 az 2730 chyb. Odhalil 0. Dooost divne, ne? Jakoze doooost dost divne. Kolik smerodatnych odchylek by bylo treba, aby se tohle to stalo?
Nebo pro lidi, kteri by namitali, ze flip nastane v situaci, kdy je hodnota v pameti dlouho (coz bude spis nesmysl, pac se jedna o dynamickou pamet, ktera se refresuje kazdych par ms) navrhuji vyvtorit ramdisk a nakopirovat tam soubor s 1GB nul. Po mesici by tam melo byt 112-320 bajtu s nenulovou hodnotou. Spoiler alert -budou tam same nuly ;-)
-
tohle je pěkný bias. Ta statistika 14 - 40 výskytů na měsíc mluví o souhrnném čísle za 2,5 roku provozu několika tisíc serverů. Vůbec nic ti ale neříká o jediném serveru v dvoudenní zátěži.
Dokud budeš konfrontovat statistická data s jediným vzorkem a jiným způsobem měření, asi se nemáme o čem bavit.
-
Tvá definice pádu (OS, aplikace) je příliš katastrofická, většina dat v paměti je obsah, data, která se někam zapisují nebo čtou, nikoliv instrukce samotné.
Mám přístup do nižších stovek serverů, kde přes EDAC tohle sledujeme a vidím, že to CE vyskakuje průměrně v jednotkách na server denně (jsou ale servery, které nemají měsíc nic). UE tam za posledních 6 měsíců (více dat nemám) není.
To je ale strašně malý vzorek a pořád se jedná o nějakou pravděpodobnost, dokonce tak malou, že jí měřit na jednom serveru je velice obtížné.
Ne ECC servery nikde po ruce nemám a doma na notebooku mám tak malý provoz, že nestabilitu asi nemá šanci pozorovat.
-
To je mi jasne, ze vetsina bitflipu problem nezpusobi (to je aegument proti nutnosti ecc btw). Proto jsem celou pamet redukoval na kritickych 128MiB.
Fajn, takze se z 14-40 chyb na gigabit dostavame na 1 chybu na server a mesic. Pokud mas zapnuty patroling (a tedy kazdy flip je odhalen a to i u bunek, ktere by se normalne nikdy neprecetly) a servery maji v prumeru 64GB tak to uz se dostavame do teritoria, se kterym jsem ochoten souhlasit - 0,015 chyby na GB a mesic. To je o nekolik radu mene nez v tom paperu.
Pro PC s 16GB ram vychazi 3 flipy na rok pri 24/7 provozu, pricemz (cucam z prstu) 90 % flipu je benignich -> ergo kladivko ecc je pro bezneho uzivatele zbytecna. S timto vysledkem souhlasim a neni treba dale o tom diskutovat :)
18. 10. 2022, 16:38 editováno autorem komentáře
-
"kolik pameti je natolik kriticke, ze flip bitu v ni zpusobi pad OS. "
V závislosti na konkrétnom použití môže byť oveľa kritickejšie ak dôjde k poškodeniu dát, než k tomu, že sa zrúbe OS s následným rollbackom otvorených transakcií.
Opäť sa mi vynára ironická veta, ktorou si robili chalani supportujúci SAP určitú srandu z linuxákov (podporujúcich OS/HW) a ich prístupu k veci: "Operačný systém je na to, aby bežal."
-
Já bych řekl, že silně záleží na use case. My máme po světě mraky serverů a ecc chyby se objevují jen když ty moduly "zestárnou", zato kolega, co dřív dělal SAPy mi říkal, že na prakticky identickém hardwaru měnili RAM skoro denně, protože ho tlačili na hranici, a řekl bych, že zrovna Linus s kompilací jádra se tomuhle blíží taky.
