Dotaz: Zamrzávání KDE při pomalých diskových operacích.

[lertimir]

Mám problém s KDE (OS: Linux 3.1.10-1.9-desktop x86_64 Systém: openSUSE 12.1 (x86_64) KDE: 4.7.2 (4.7.2) "release 5") Při práci s pomalejším diskovým subsystémech a kopírování (dělám to hlavně krusaderem ale jev je i jinde) zamrzne celé KDE a nedá se ovládat. Pomalý znamená třeba NFS filesystém nebo flash disky. naposled jsem udělal chybku a postil do flash dva proudy s mnoha soubory cca 2GB a asi 15 minut byl počítač nepoužitelný. To že to trvá dlouho je sice nepříjemné, ale kopírování nemuže zamrazit okna. Netuším ani kde hledat. (možná to souvisí s tím jak jsem už jednou psal, že nájezd gwenview také zatuhne i kurzor.

Odpovědi

[MadCatX]

Hrozně nerad bych mystifikoval, ale na jaderných novinách i jinde jsem četl, že podobné za problémy může velké množství dirty pages, které se drží v paměti při zápisu na pomalá zařízení. V jádře 3.3+ by toto mělo být z části vyřešené.

Sám jsem podobně fatální záseky v KDE nikdy neměl (občas se mi tohle stane na pár vtěřin při startu KDE, ale nic strašného), takže nemůžu moc posoudit. Kromě novějšího jádra si můžete zkusit pohrát s I/O plánovačem, někteří uživatelé na fórech Archu měli prý dobré výsledky s noop či deadline plánovačem při zápisu na flash paměti.

[pushkin]

Netuším přesně, čím to je, ale je na to velmi citlivé právě kio_file (tj. kopírování přes jakýkoliv KDE program). Kopírování třeba pomocí mc se chová lépe. Jestli jde o závadu jádra nebo KDE netuším, je možné, že kio_file používá nějaký jaderný postup, kterému se mc vyhýbá a výsledek je tento...

[lertimir]

Ano, kio_file to dělá. A asi vyřešení nevidím v dohledné době. Mám i problémy s kopírováním dat na server (gigabitová sít mezi stanicí a serverem, RAID 5 na serveru - stripy na raidu 16kB takže malé) A při kopírování filmů tedy cca 700MB se stejně v průběhu přenosu celá stanice chvílemi zasekne. Typicky ve chvíli, kdy se podle KDE teploměru soubor dokopíruje a asi se provádí sync. Přesto dosahuje rychlost při kopírování v krusaderu cca jednotky MB/s. Pokud jsem zkusil na příkazovém řádku natvrdo kopíroval přes cp byly rychlost cca 10-15 krát vyšší a na 90-95% gigabitové sítě tedy rychlost mezi 90 až 110 MB/s.

Problémy jsou asi horší už podle tohoto a tohoto a tohoto. Status "UNCONFIRMED" znamená, že se s chybou nic nedělá a kašle se na ni?

Kruci mě se tak z KDE nechce. To co používám často a je tvrdě v KDE je digikam, kontact, krusader, kile, kompare, kate, kopete, ale jestli s tím něco neudělají, tak nechci mít se svého čtyřjádra i5 nepožitelnou bednu.

[Luboš Luňák]

http://lists.opensuse.org/opensuse-bugs/2012-04/msg03877.html

[pushkin]

To zní optimisticky zkusím. Jinak existuje vysvětlení, proč je na to tak citlivé právě kio_file?

[Luboš Luňák]

Nemyslím, že by kio_file mělo nějaký takový problém. Spíš to bude tím, že KDE aplikace potřebují X-Server a ten má problém, pokud je přetížené I/O (proto třeba mimo jiné špatně reaguje i jen kurzor). A obecně KDE aplikace jsou komplikovanější než konzolová aplikace a tak zase je přetížené I/O víc poznat.

[pushkin]

I to je možné. Jinak provedl jsem test - kopírování 1GB hudby na Nokii E52 (OS S60) s Class 4 32GB kartou. Celý proces trval zhruba půl hodiny, takže průměrná rychlost kopírování byla 0.5MB/s. KDE trpěly při každé větší akci záseky (i při přepnutí mezi plochami apod.), ale po každém záseku se vzpamatovaly rychleji (do minuty), než s předchozí verzí jádra (aktuálně kernel-desktop-3.1.10-1.9.1.x86_64.rpm, předtím kernel-desktop-3.1.9-1.4.1.x86_64.rpm), KDE 4.8.3. Hodně podobné je to i na Debian Wheezy, KDE 4.7.4, kernel 3.2.0.

[lertimir]

Nejvíce pikantní na celé záležitosti bylo, že jsem kopírováním přenášel fotky na flash disk kamaráda, který pracuje ve Windows. A já už dost let ho přesvědčuji jak je linux a opensource fajn. Už přišel na chuť openoffice, vlc playeru, inkscape. No a po této zkušenosti si už ze mne dělá pár dni srandu, kdy už zahodím ten nepoužitelný systém, který nereaguje ani na čtyřjádrovém procesoru.

[lertimir]

Ale proč to zamrzne i na mnohajádrových procesorech. Podle mne to pak problém designu scheduleru. Systemu by mělo se dát říci, že procesy které pošlu na frontu v kopírování, by mne neměly nijak ovlivnit interaktivitu. V podstatě je jedno jestli kopírování poběží o 10 nebo 25 déle pokud zbytek systému nebude zaseklý. V tomto případě v těch widlích kamarád kopíruje total commanderem a tak že všechny kopírování hází do fronty. A interaktivitu to nikdy neovlivní.

[Prcek]

Jo taky se mi to stává (Gentoo, linux 3.2.12, KDE 4.8.1), na pár vteřin všechno zamrzne.