Dotaz: Ubuntu 16.04 problem s rychlost kopirovani na USB klic

[kafi]

Zdravim panove, pouzivam Ubuntu 16.04 a pri kopirovani dat na USB klicenku dochazi ke kompletnimu zaseknuti systemu, pohyby mysi jsou trhane na klavesnici temer nereaguje. Po prekopirovani vsechno v normalu. Ma sestava: Intel i5 3GHz, 8GB RAM, SSD disk KINGSTON SUV400S37120G + 2 HDD disky v raidu 1. Kopirovani dela problem jen z ssd do usb flash nebo z hddd do usb flashdisku. mezi disky v pohode. Test rychlosti SSD disku:

Timing cached reads:   21460 MB in  2.00 seconds = 10740.94 MB/sec
Timing buffered disk reads: 1446 MB in  3.00 seconds = 481.51 MB/sec

Test rychlosti HDD disku v raidu 1:

Timing cached reads:   18802 MB in  2.00 seconds = 9409.83 MB/sec
Timing buffered disk reads: 468 MB in  3.07 seconds = 152.23 MB/sec

Odpovědi

[lertimir]

Asi je to tento problém. Co mě tedy udivuje, že to v ubuntu není ošetřeno tolik let po identifikaci (a řešení) problému.

[gurr]

A já si myslel, že mi blbne GUI (mám Nvidia :( GPU). A ono je to tohle, hmm.

[kafi]

Super ted vim v cem je problem, ale reseni se nedari najit a vypada to, ze ani neni. Nebo snad je a jsem slepy!?

[kafi]

Jeste bych doplnil - presel jsem na Ubuntu z Debianu a tam jsem tento problem nemel. Napadlo me prelozit vanila jadro, ale to jsem od dob Slackware 9 nedelal a vubec se mi do toho nechce. Neda se nekde sehnat nejake jine jadro, ve kterem by to bylo opraveno/upraveno a fungovalo? Dalsi otazkou je jestli vubec to je ve vanile opravene/upravene. Je to strasne otravne a nechce se mi prechazet zase na Debian.

[MadCatX]

Nastav si hodnoty dirty_bytes a dirty_background_bytes na rozumná čísla a zkus to. Nevím, jak moc zde pomůže zapnout paralelní fronty pro bloková zařízení, taky by to možná stálo za pokus.

[kafi]

"rozumná čísla" co to je? Jak je urcit? Pohral jsem si s hodnotami uz pred mou odpovedi a nepripada mi, ze by to melo nejaky efekt. Nasel jsem ke stazeni kernel od Debiana. Zkusim jej narvat do Ubuntu a uvidim. Prjde mi to lepsi nez laborovanim s hodnotami.

[lertimir]

Rozumné hodnoty můžeš zkusit mezi 30-100MB pro dirty_bytes a background na polovinu zvolené hodnoty. (To je tak 1 sekudna až 3 sekundy zápisu do toho pomalého zařízení. Pokud to nepomůže tak stáhnout ještě trochu méně.)

[MadCatX]

Debianí jádro bude podle mě dost podobné Ubuntímu. Já už jsem tenhle problém dost dlouho nepozoroval a to jsem měl jednu dobu dost hloupou flashku, kterou jsem často používal ve strojích s 16 a 32 GB RAM. Na obou strojích jsem měl povolené blk_mq, možná to má nějaký efekt...

[lertimir]

Ještě doplním jak ten článek chápu. Normálně se nic neděje, buffer funguje jak má, vše je normální a počítač reaguje. Problém nastane, když nějaký proces zavolá sync. V tom případě musí špinavé stránky do disků. Pokud jsou buffery takové, že se zapisují dlouho, tak vše stojí, protože nejdříve je třeba dosynchronizovat disky. (na mém domácím desktopu mám 24GB a když by to bylo 20% tak jsou buffery skoro 5GB a při rychlosti flash disku -dobry 20MB/s špatny 8MB/s je to fakt dlouho) Pak se všechno uvolní, nicméně procesy, které píší na tu flash díky tomu že berou data s rychlých SSD/HDD poměrně rychle naplní buffery, pak zase něco zavolá sync a vše stojí než se dosynchronizuje. Snížení velikosti bufferů způsobí dvě věci. Jednak buffery jsou malé a tím pádem sync zapisuje málo dat a bude rychle hotovo. Za druhé proces čtení dat do bufferů je zpomalen, protože buffer se zalní a read musí počkat. Tím pádem očekávám, že sync spuštěný uživatelským programem se pustí "méně často". Pustí se z pohledu množství přečtených/zapsaných dat ve stejném místě programu, ale z pohledu času uživatele to bude ve větších intervalech protože data se tak rychle nečtou. Obojí změní poměr mezi situací "počítač pracuje normálně" a situací "synchronizují se disky počítač stojí" silně ve prospěch první situace.