Dotaz: zpomalení systému (Ubuntu 14.04) při kopírování na USB

[TomasABC32]

Zdravím, včera jsem kamarádovi kopíroval nějaké filmy na USB a stalo se, že v průběhu kopírování dojde k totálnímu zpomalení počítače. Například reakce na klávesnici je taková že trvá dlouho než se písmenka otisknou. Pak přepínání mezi plochama atd.. zkrátka vše co běžně funguje zcela rychle - normálně.

Nevíte proč ?

Jsem jinak s linuxem nadmíru spokojený.

---

---

Odpovědi

[Jamaic]

Že by http://www.abclinuxu.cz/clanky/jaderne-noviny-7.-11.-2013-proc-pomala-flashka-zpomali-64bitovy-stroj (Zákeřný problém se zamrzajícími flashkami) ?

[nobody]

jestli na tom USB je HDD s NTFS, mozna jde o bug s ntfs-3g, kdy pri vetsich souborech zatezuje cpu na 100%, mohlo/melo by pomoci pridat mount parametr big_writes, pokud nejde o format NTFS tak tato uvaha neplati...

obecne co zpomaluje je videt v nejakem "sledovani systemu" bud to graficke gnome-system-monitor nebo konzolove htop a seradit podle CPU a podle MEM, bud to zere CPU nebo RAM a nasledne to swapuje na disk...

[TomasABC32]

nene, NTFC to není. Kam přesně přidat ten parametr ?

Pročtu si ten odkaz co poslal Jamaic a ozvu se.

[NN]

..pridat mount parametr..

[nobody]

pokud nejde o format NTFS tak tato uvaha neplati

[dvdmchl]

Kdysi jsem to resil takto: cat /sys/block/sdb/queue/scheduler
(misto toho sdb si dej spravne oznaceni tveho USB disku)

V zavorkach uvidis aktualni scheduler, pokud je to "cfg" tak ho zmen na "deadline"

sudo mozna nebude fungovat v tomhle pripade, takze udelej heslo roota a pouzij su-

su-
echo deadline > /sys/block/sdb/queue/scheduler

otestuj to...

pokud funguje pak to pridej do rc.local, nebo jako kernel parameter: elevator=deadline
aby to fungovalo i po restartu

[nobody]

zbytecne a z meho pohledu i nevhodne delat heslo roota, dela se to jednoduse takto:

echo deadline | sudo tee /sys/block/sdb/queue/scheduler

nebo

sudo -i
echo deadline > /sys/block/sdb/queue/scheduler

[TomasABC32]

tak jsem to vyzkoušel. Nejdřív jsem si to nechal vypsat pomoci cat /sys/block/sdb/queue/scheduler. Tam jsem zjistil že je to cfg.

Pak jsem použil druhý příkaz viz. echo deadline | sudo tee /sys/block/sdb/queue/scheduler. Bohužel nic se nezmění, jako bych neměl práva. Stále na mě kouká cfg... Proč ?

[nobody]

divne1... pokud bys nemel prava, oznami ze zamitnuto (muzes to zkusit kdyz vynechas to sudo pred tee)
divne2... mam xubuntu 14.04 a USB flash ma nastaven deadline (i bez udev pravidla nize)
muzes si zkusit vytvorit udev pravidlo, ktere bude nastavovat automaticky pro rotacni(HDD) cfg a pro nerotacni(SSD/SD/USB_FLASH) deadline ... (misto gedit pokud ho Ubuntu nema v zakladu, pouzij "svuj oblibeny textovy editor")

[TomasABC32]

Tak se mi povedlo nastavit deadline, díky za rady...

Ale teď když započnu kopírování z HDD na USB vypadá to že všechno funguje tak jak má.

Jenže...

Pokud se film dostane na cca. 1 Gb, všechno se zpomalí a je to stejný problém. To není normální. Přitom mám nastavený ten deadline pro usb (sdb)

[dustin]

Díval ses do dmesg, neháže to nějaké chyby?

[MadCatX]

Skoro určitě jde o problém se zápisem masivního množství dat na pomalé flashky. Pokud máš reprodukovatelný způsob, jak ten problém vyvolat, zkusil bych

sudo su
echo 104857600 > /proc/sys/vm/dirty_background_bytes
echo 209715200 > /proc/sys/vm/dirty_bytes

Jestli to pomůže, budou se muset ty dva řádky přidat do /etc/rc.local, jinak změna nepřežije restart.

[nobody]

btw: neda mi to :) prepsano do "bez su" reseni za pouziti tee, povazuju to za jednodusi/prime/jednoradkove reseni pro predavani informaci/postupu "presmeruj neco jako root":

echo 104857600 | sudo tee /proc/sys/vm/dirty_background_bytes
echo 209715200 | sudo tee /proc/sys/vm/dirty_bytes

[lertimir]

Souhlasím s tím, že je problém ve špinavých stránkách. Nicméně dal bych tam menší hodnoty. Záleží jakou má flashku. Mnohé mizerné flasky mají tragické rychlosti při zápisu většího množství dat. Třeba ze začátku mají 20MB/s, ale po zápisu větsiho množství dat klesnou v rychlosti na 2 MB/s. Vyhození 100MB z dirty_background může být pořád dlouho. Nastavil bych ty hodnoty někde na 16/32 popřípadě na 32/64 MB a ne na 100/200. A pokud bych zaznamenal snížení u běžného použití, tak bych teprve navyšoval.

[TomasABC32]

Díky MadCatX, vyřešeno přesně podle tvého postupu a soubory se nyní kopírují bez problému. !!

[MadCatX]

Nezapomeň si to nastavení přidat do /etc/rc.local, abys to nemusel ručně měnit při každém restartu. Ideálně zkontroluj, že se to nastavení po restartu fakt uplatní

cat /proc/sys/vm/dirty_background_bytes

Kdybys narazil i tak na problémy, můžeš zkusit ty hodnoty ještě snížit. Pokud je ale srazíš moc, utrpí tím výkon, protože se bude častěji po menších kouscích zapisovat na disk. Dej pozor, že ty hodnoty se uvádí v bytech, pro převod z megabytů je třeba je vynásobit 1048576. (32 MB = 33554432 bytes).

Úplně mimochodem, zkusil jsem si na flashku nakopírovat 19 GB adresář s 13 soubory o velikosti cca 1,7 GB. Když byla flashka připojená přes USB 3, žádný zásek jsem nepozoroval, přestože rychlost zápisu spadla někam pod 15 MB/s. Zkoušel jsem to na stroji s Fedorou 23 a 16 GB RAM ve výchozím nastavení, takže jádro mělo povoleno ušpinit až 3,2 GB stránek. Během zápisu bylo konstantně přes 600 000 špinavých stránek, tedy něco přes 2,3 GB. Na USB 2 jsem to zkoušel jen s 1,6 GB souborem a fungovalo to taktéž. Zvláštní, že na Ubuntu to dělá takový chaos...

[MadCatX]

Musel jsem si to zkusit ještě i na notebooku (ThinkPad T420, 8 GB RAM, aktuální Arch Linux s KDE 5). Buď se muselo něco změnit v jádře 4.0 - 4.2 nebo je v Ubuntu 14.04 něco špatně nastavené. Notebook se chová dost podobně jako desktop, během kopírování se ušpiní hodně stránek, ale systém běží dál bez zaškobrtnutí.

[TomasABC32]

díky. Je to zvláštní. Nicméně zatím to běhá dobře. Pokud by byl i v budoucnu problém, pokusím se to vyřešit dle tvých rad.

[lertimir]

Podle mne to ještě není dopracované do LTS jader. 14.04 mělo původně jádro 3.13 a posledním upgrade má mít 3.19. Stejné chování jsem pozoroval na openSUSE 13.2 s jádrem 3.16. Myslím že korektní odstranění problému potřebovalo více času.

[nobody]

na Xubuntu 14.04 jsem na to nenarazil, ani s prvotnim jadrem 3.13, ani pozdejsi 3.16 ani v aktualnim 3.19, nejspis jde zaroven o nejakou kombinaci HW...

[TomasABC32]

Já už mám jádro 3.19.0-43-generic a zlobilo to stejně.