Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem 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í).

Jsou zobrazeny jen nové odpovědi. Zobrazit všechny
Předmět Autor Datum
už ho to zase bere! vyžraná volná paměˇt na 170MB (přitom -bufferes/cache 1.GB) A TO I POdokončení k…
mnua.al 23.10.2013 18:43
mnua.al
to s tím ecryptfs byl jiný dotaz/problém....(že se náhle odpojil) ecrypfs nemám povrch SSD jsem nek… nový
mnua.al 24.10.2013 13:21
mnua.al
Nemuze byt problem v tom encryptfs, ze trva prilis dlouho, nez vsechno zakodujes? Ze se ti to seka n…
gilhad 23.10.2013 20:42
gilhad
Taky bych se k tomu přikláněl. nový
FixExa 23.10.2013 21:12
FixExa
Opět jsem u toho. Po delší době kopírování mi zběsile bliká kontrolka HDD. (Dá se zjistit, co konkrt… nový
mnua.al 09.11.2013 19:51
mnua.al
Do háje už zase dostal zásek. Tentokrát jsem vážně nic nekopíroval. 4 minuty svítící kontrolky HDD,… nový
mnua.al 16.11.2013 21:02
mnua.al
Tak po zapnutí swapu bohužel problém přetrvává. Při rozbalování rar souboru (zdrojový i cílový soubo… nový
mnua.al 20.01.2014 04:27
mnua.al
Nevím, máš nějaký podivný linux. Když jsem v televizním serveru měl VLC, které obsahovalo chybu (mem… nový
JR_Ewing 20.01.2014 06:27
JR_Ewing
co pouzivas ke kopirovani? dela to v terminalu nebo nejakym programu? jaky file system maji ty disk… nový
RedMaX 20.01.2014 06:35
RedMaX
na pozadí jsem spustil while true ; do echo 3 | sudo tee /proc/sys/vm/drop_caches ; sleep 9 ; done… nový
mnua.al 29.01.2014 14:25
mnua.al
Preco je to rozdielne ? No pretoze nie su percenta ako percenta. Mozu byt vyjadrene okamzitou hodnot… nový
KiloViktor 29.01.2014 17:54
KiloViktor
Další, a vzhledem k množstvím "dotazů", to vysokoškoláček totálně roz*dal! Jen tak mimochodem, jinde… nový
ms 29.01.2014 18:23
ms
Máš nějaké zdroje, kde bych se mohl dočíst, ako sa chova system pri saturacii RAM? U mě ten proces j… nový
mnua.al 29.01.2014 19:45
mnua.al
A máte mozek? Na to lze dojít i logickou úvahou. Operační systém má holt už plné zuby toho neumětels… nový
ms 29.01.2014 20:55
ms
Tebe nejde o zravost, ale o to, ze ti to zatuhava. Na zravost sa vykasli. Zatuhavanie je nieco ine a… nový
KiloViktor 29.01.2014 22:01
KiloViktor
Tady si fakt myslím, že něco není v pořádku: Zapisuji takto na disk: pv /dev/zero -s 1348G >>/run/me… nový
mnua.al 31.01.2014 09:20
mnua.al
To se opravdu tak nudis, ze musis psat priblb2 otazky kazdy den, nebo ses tak blbej? poslední
Plzenske Pivo 31.01.2014 09:38
Plzenske Pivo

už ho to zase bere! vyžraná volná paměˇt na 170MB (přitom -bufferes/cache 1.GB) A TO I POdokončení kopírování!
swappiness je 60. Systém pak byl nepoužitelný asi 4 minuty! myš se pomalu pohybovala, a nabídky byly extrémně pomalé, že jsem nezvládl ani ukončit aplikaci.
Neexistuje nějaký patch, nebo nastavení, které hlídá, aby systém nevyčerpal tolik paměti, když to nezvládá?

PS: při kopírování velkého souboru z USB naSSD se sekal dokonce i FILM. Nechápu proč, když z USB data proudí max 30MBps, a rezerva na SSD je ještě nějakých 150MBps!

to s tím ecryptfs byl jiný dotaz/problém....(že se náhle odpojil)

ecrypfs nemám
povrch SSD jsem nekontroloval, ale běží svižně...
notebook USB 3.0 nemá, protože v té době nebylo.

Jinak zde jsou pro orientaci údaje o rychlosti komprese:
encfs 15-30 MBps
ecryptfs 40-80 MBps
ecryptfs aes 74 best
luks-ext4 90-130MBps

Nemuze byt problem v tom encryptfs, ze trva prilis dlouho, nez vsechno zakodujes? Ze se ti to seka nikoli kvuli nedostatku pameti (furt tam nejaka jeste je volna), ale kvuli vytizeni CPU, ktere se snazi zakodovat prilis mnoho dat?

Opět jsem u toho. Po delší době kopírování mi zběsile bliká kontrolka HDD. (Dá se zjistit, co konkrtétně ukazuje? Vztahuje sevůbec k jen syst HDD nebo i připojeným?)

výpis iostat, naleznete tam něco divného?

Linux 3.11.6-1-MANJARO (dq)   9.11.2013       _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          14,64    0,63    5,93   14,39    0,00   64,42

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             116,84      5982,96      5496,08   18765138   17238085
dm-0            118,54      5981,97      5496,08   18762037   17238076
sdb              82,51      3922,62      4316,37   12303009   13537996
sdc              13,29       326,32       794,02    1023469    2490396

a jako tradičně paměť zaplní buffers, nezsouvisí to spolu?

             total       used       free     shared    buffers     cached
Mem:          3,9G       3,7G       212M         0B       7,5M       2,4G
-/+ buffers/cache:       1,3G       2,6G
Swap:           0B         0B         0B

Kopírování probíhá z ext4 na LVM na interním SSD na externí NTFS(MBR)

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.

@dell ~ % free -h
             total       used       free     shared    buffers     cached
Mem:          3,9G       3,8G       110M        85M       761M       559M
-/+ buffers/cache:       2,5G       1,4G
Swap:          75M        75M         4K

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]

Nevím, máš nějaký podivný linux. Když jsem v televizním serveru měl VLC, které obsahovalo chybu (memory leak), tak to ten proces zabíjelo.

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?

[17162-zjebanapametvlinuxu-png]

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.

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:

             total       used       free     shared    buffers     cached
Mem:          3,9G       1,9G       2,0G        28M       686M       101M
-/+ buffers/cache:       1,1G       2,7G
Swap:          75M       2,1M        73M

DO:

             total       used       free     shared    buffers     cached
Mem:          3,9G       3,7G       130M        28M       1,8G       731M
-/+ buffers/cache:       1,2G       2,7G
Swap:          75M       2,1M        73M

Zpět do poradny Odpovědět na původní otázku Nahoru