Proč linux při kopírování obsadí včechnu paměť.
Nejdřív popíšu důsledky. Linux obecně snáší nedostatek paměti tragicky, začne sekat myš, v chromu začnou padat rozšířenéní a systém je lenivý - až neovladatelný.
Mám 4GB RAM
Mám iso obraz připojené do nějaké složky. Z té kopíruji do další složky (vše leží dokonce na exteráku)
využití paměti během kopírování ale i během něj je:
total used free shared buffers cached
Mem: 3,9G 3,7G 152M 0B 1,6G 807M
-/+ buffers/cache: 1,3G 2,5G
Swap: 0B 0B 0B
Dělám něco špatně, nebo kde je problém, že si na kopírování souborů linux vezme 2GB. Já vím, jde o mezipaměť, ale už jsem cítil, jak to na něj jde (to náznaky zatuhávání).
Do háje už zase dostal zásek. Tentokrát jsem vážně nic nekopíroval. 4 minuty svítící kontrolky HDD, ledově pomalý kurzorm, žádné reakce na klávesy, pak jekési uvolnění, kde se mi najednou zrychleně provedly všechny operace, která během záseku se neprovedly( kontextové nabídky, vyskakovací konzole přepnutí oken).
Pak zase 2 minuty zamrzntutí a pak se mi konečně povedlo přepnout na vt2. Ovšem mě uzemnilo, že systém měl volných celých 2.6GB RAM (cache a buffers mělo 200MB dohromady). Nevíte, co může být na vině? Předtím dal otevřít asi 100 tabů v Opeře. (Systém jel bez problému, jen opera zaseklá, ale vím, že to asi po 30 s vydýchá a začne reagovat). Potom jsem spustil wireshark a nahrával traffic (live capture) , ukládá do tmp. Němohlo tedy dojít k zaplnění tmp?
Další otázka, neexistuje nějaký program, který hlídat zaplnění RAM, a případně zakáže zápis do /tmp, aby systém takhle katastrofálně nezhavaroval?
Tak po zapnutí swapu bohužel problém přetrvává. Při rozbalování rar souboru (zdrojový i cílový soubory byly na jednom NTFS externím USB disku) programem 7z opět došlo ke spotřebování skoro celé paměti, systém opět zatuhával... Sledoval jsem jak se plní paměť během "rozbalování" (ono když je to uložené metodou store, tak tam toho moc na rozbalování není). Při volných 100MB opět se zasekávala myš a i systém jako celek... Navíc by mě zajímalo kde je problém: i kdyby byl použitý nějaký hustý kompresní algoritmus, tak přece při rozbalování se nebude stávat, že se volná paměť se bude donekonečna zmenšovat(podrobnosti jsou na konci)..
Napadají mě tedy tyhle možnosti:
1. NTFS ovladač je blbý, že nepodporuje něco jako MMAP
2. kromě toho je i pomalý (na 1.5GHz atomu při kopírování NTFS-RAM má 50% CPU load)
3. linux má blbou správu paměti (když už vím, že radši neodstřelí nenasytný proces,aby prý nedošlo ke ztrátě dat, ve výsledku dojde zatuhnutí PC) tak třeba prostě nějak neuvolňuje pamět
4. v nějakém mezi článku nefunguje bufferované čtení souboru a prostě se snaží celý soubor narvat do RAM
Nevím, ale mám pocit, že v linuxu ohledně správy paměti (ale i mj. třeba i záseků způsobeného zahlcením video RAM ) je něco shnilého.
PS: když už jsem psal o přenosu souboru nadisk, umí nějaké systémy (spíš řadiče HDD) třeba při kopírování, že OS dá příkaz na kopírování určitých bloků na HDD, tak, že řadič HDD kopíruje, ale bez nutnosti aby SATA/USB rozhraním OS ty data četl a ty SAMÁ nová data zase do rozhraní posílal k zápisu?
A poslední věc... Od zapnutí swapu při vysokém obsazení paměti pozoruji vysoké zatížení CPU procesem [kswapd0]
co pouzivas ke kopirovani? dela to v terminalu nebo nejakym programu?
jaky file system maji ty disky mezi kteryma je kopirovano?
kdy to dela? pouze pri kopirovani na externi disk nebo i na internich?
---
setkal sem se s tim taky, pri kopirovani na USB flashku (USB2.0) naformatovanou na NTFS se system zacal sekat, nemel jsem cas to blize studovat, nicmene mam v tom PC datovej SATA disk s NTFS (prehozenej z windowsu) a tam to nic takovyho nedela, takze ovladac NTFS bych z chyby nepodeziral.
na pozadí jsem spustil while true ; do echo 3 | sudo tee /proc/sys/vm/drop_caches ; sleep 9 ; done
Tady je vidět, jak systém vyžírá paměť. Je to graf každou sekundu, kolik je volné paměti (sloupec free). Prostě systém vyžírá paměť nade všechny meze (asi 100MB /s) Jednotky: sekundy, kB.
To propadlo je místo, kde jsem spustil programy, takže došlo k vyššímu zaplnění paměti. 9sekundový nestačil už na to aby promazal caches paměť byla totálně zaplněnéá (kromě nějaké 100MB rezervy) a systém byl opět díky zpomalenotsti nepoužitelný.
Samozřejmě s tímto skriptem, který promazává bordel z paměti, tak je PC svižný. Jo a proč mi ještě ksysguard hlásí zatížení 70-80%, zatímco htop pro 40%, 50% pro jádra, to nějak nesedí... htop taky hlásí, že mount.ntfs žere 35%CPU, zatímco ksysguard 16%..
A vlastně je normální, aby kopírování souborů takhle žralo procák?
Preco je to rozdielne ? No pretoze nie su percenta ako percenta.
Mozu byt vyjadrene okamzitou hodnotou samplovanou "nejakym intervalom", alebo hodnotou priemerovanou. Aka to vlastne je hodnota sa nikde nedocitas, jedine, ze si nastudujes zdrojaky. Dokonca ani priemer nemusi byt rovnaky. Existuje viacej metod priemerovania.
Ak ti to velmi vadi doporucujem nastudovat ako sa chova system pri saturacii RAM. V systeme existuje proces, ktory sa vola zabijak a pracuje len pri kritickom nedostatku RAM. NTFS by som na Linuxe moc neskumal (ak to nemas v umysle opravit), pretoze to nieje nativny FS pre Linux a bol robeny reverznym ingeeringom, tudiz pracuje este horsie ako original na Windowse.
Další, a vzhledem k množstvím "dotazů", to vysokoškoláček totálně roz*dal! Jen tak mimochodem, jinde se "chlubil", jak je bez "zbytečného" swapu a pak si stěžoval, že při narvané RAM os zpomaluje a vůbec,... ten Linux je prostě eaný a on, vysokoškoláček, to neustále "dokazuje"...
Máš nějaké zdroje, kde bych se mohl dočíst, ako sa chova system pri saturacii RAM? U mě ten proces je asi laxní, protože by podle mě neměl dopustit takhle extrémně zasekat systém. (i když jsem nastavil /proc/sys/vm/oom_kill_allocating_task)
Evidentně swap tady nehraje roli, při zaplnění VM dojde k zasekávání tak jako tak (rozdíl je bez swapu dojde k totálníhu zatuhnutí po čase, kdežto takhle je systém "jen extrémně pomalý", třeba reakce na ovládání jde po 5sekundách, chvíli to jde, pak se to zase sekne)
A nedostatak RAM je jen důsledek nějaké chyby při kopírování.... Přece kopírovat soubory jde i s v využitím minima RAM a růst položky caches je nějaký bug.
A máte mozek? Na to lze dojít i logickou úvahou.
Operační systém má holt už plné zuby toho neumětelského betatestování...
Tebe nejde o zravost, ale o to, ze ti to zatuhava. Na zravost sa vykasli.
Zatuhavanie je nieco ine ako "zravost". Precitaj toto:
http://www.abclinuxu.cz/blog/pht/2010/2/low-latenc y-aneb-dalsi-krap-do-krapojadra
Tam mas kopu napadov, co mozes "ladit", aby to chodilo lepsie.
Tady si fakt myslím, že něco není v pořádku:
Zapisuji takto na disk: pv /dev/zero -s 1348G >>/run/media/u/disk/soubor
Naštěstí se systém zázračně neseká tentokrát.
4GB RAM se postupně zaplňuje takto (zaplnění trvá 30s)
Znamená to tedy, že jakési mezipaměti se zapisují samé nuly? Z jakého důvodu? A proč rovnou dvakrát nebo třikrát? (2*(731-101)=2*630=1260),(1800-686=1124) , 1260~=1124M
OD:
DO:
To se opravdu tak nudis, ze musis psat priblb2 otazky kazdy den, nebo ses tak blbej?