Come rendere "utilizzabile" la GUI di Linux quando si verificano molte attività del disco

Question

Se inizio a copiare un albero di file di grandi dimensioni da una posizione a un'altra o se qualche altro processo inizia a svolgere molta attività su disco, l'app in primo piano (GUI) rallenta fino in fondo. Ad esempio, prendi un albero di file da 2 GB con 100 file al suo interno. Apri una console e fai cp -r bigtree bigtree2. Quindi vai su firefox e inizia a navigare. Firefox è quasi inutilizzabile. Anche se imposto il bel livello di firefox a una priorità molto alta (-20), è ancora molto lento con enormi ritardi.

Mi ricordo che alcuni anni fa, quando lavoravo a una scatola Solaris, il sistema si comportava molto meglio in circostanze simili.

Il mio HD sta utilizzando DMA, non PIO. È SATA. Non montato con la bandiera atime.

Answer 1

Provare ionice -ing o eseguire il processo di copia. Il problema è dovuto al fatto che IO ha la stessa priorità della GUI, che per un desktop influisce sulla reattività percepita.

C'è una Ubuntu brainstorm su questo al momento.

Answer 2

Linux ha avuto a lungo un problema con i programmi che sfruttano tutta la memoria cache "sporca" del sistema. Quello che sta succedendo è che il processo di copia sta riempiendo la cache di scrittura con i dati del file che sta copiando e lo sta facendo molto rapidamente. Quindi, quando Firefox arriva e deve scrivere, deve prima attendere lo spazio del buffer sporco o uno slot di scrittura della coda del disco disponibile. Durante l'attesa è in competizione con il processo di copia e il thread pdflush del kernel, che sposta i dati dai buffer sporchi alla coda di scrittura del disco.

Firefox ha ancora un altro problema in questo scenario. Utilizza SQLite per memorizzare i propri segnalibri, la cronologia e altre cose. SQLite è un database compatibile con ACID e utilizza un sistema di transazione con le sue scritture su disco svuotato sul disco. Quindi, non solo deve attendere lo spazio del buffer, deve attendere che la coda del disco, che è piena di file copiato, venga cancellata prima che possa confermare una scrittura corretta.

C'è stato un lotto di tweaking fatto al sistema di accodamento e buffering del disco Linux. Ci sono cambiamenti in quasi tutte le versioni del kernel. Prova una delle versioni più recenti. Puoi anche provare a modificare i valori di sysctl. Mi sono simile a questi:

vm.dirty_writeback_centisecs = 100 
vm.dirty_expire_centisecs = 9000 
vm.dirty_background_ratio = 4 
vm.dirty_ratio = 80 

Si può anche provare a modificare il numero di slot nella coda del disco. Questo valore è /sys/block/sda/queue/nr_requests. È necessario sostituire sda con qualunque sia l'unità in uso. Più slot significa più possibilità di unire le richieste IO e lo scheduler CFQ IO può fare un lavoro migliore con priorità. Meno slot di solito significa un'attesa più breve per essere scritti su disco per l'I/O sincrono come le transazioni di SQLite. Meno slot significa anche un'attesa più breve per leggere l'I/O nella coda del disco se un processo di scrittura pesante riempie completamente la coda con un IO di scrittura.

Answer 3

Non sei il primo a notare questo problema. L'ex sviluppatore del kernel [Con Kolivas] (http://en.wikipedia.org/wiki/Con_Kolivas) ha riscontrato che molte aziende pagano allo per migliorare le prestazioni del server Linux a scapito delle prestazioni del desktop. Con ha avuto un impressionante set of patches for making the desktop more responsive. Sfortunatamente c'era una sorta di guerra tra codice ed eventualmente Con dropped out.

Mi piacerebbe sapere come inviare una petizione agli sviluppatori del kernel Linux per prestazioni desktop migliori. Nel frattempo, se desideri eseguire il kernel 2.6.22, puoi eseguire con il set di patch -ck.

Answer 4

Assicurarsi che DMA sia abilitato su tutte le unità che lo supportano. A seconda della distribuzione, questo potrebbe non essere l'impostazione predefinita. Leggi man hdparm e controlla il tuo sistema init meccanismo.