Perché i sistemi diventano lenti quando si eseguono scritture di massa su disco?

Voglio sapere perché i sistemi diventano lenti quando si scrivono dati di massa su disco.

Penso che per rendere il sistema lento, ci dovrebbe essere qualche problema con la CPU. Ma la scrittura ha solo un limite I / O.

Si verificano interruzioni hardware durante la scrittura dei dati? In tal caso, potrebbe essere a causa degli interrupt che la CPU commuta sempre il cambio di contesto.

Il motivo principale dietro è il solito: l'I / O è molto più lento della CPU / RAM. Anche se i processi che eseguono operazioni di I / O utilizzano DMA (che scarica la CPU), a un certo punto dovranno probabilmente attendere il completamento delle loro richieste.

Nel caso più comune di un HDD, aggiungi semplicemente diverse applicazioni che provano ad accedere ai file sparsi nell'unità e puoi prepararti un caffè (tè, qualunque cosa). Con gli SSD la situazione migliora, ma anche un SSD - che ha un throughput misurato in centinaia di MB / s su SATA (rispetto alle decine di MB / s di un HDD spin-plate) e tempi di ricerca davvero trascurabili (rispetto ai millisecondi per un piatto rotante) - può diventare un collo di bottiglia.

Il problema, a quanto ho capito, non è solo nel trasferimento dei dati stessi, ma nell'overhead necessario: l'I / O è controllato dal kernel, ma raramente si verifica senza spazio utente. Quindi possono esserci molti cambi di contesto, solo dalle applicazioni in attesa di I / O che controllano se qualcosa sta accadendo (dipende ovviamente dall'implementazione). Nel caso dei trasferimenti su disco, potrebbero esserci diversi thread del kernel in competizione per risorse o attese (che a volte è una strategia appropriata). Ricorda, ad esempio, la copia di dati da una partizione all'altra richiede un moderno filesystem per: scoprire dove si trovano i dati di origine, leggerlo, allocare spazio sul file system di destinazione, scrivere metadati, scrivere dati, ripetere fino al termine.

E se, a un certo punto, il tuo sistema inizia a scambiare (che di solito ha una priorità più alta rispetto al normale I / O), il disastro viene finalizzato.

EDIT : dopo aver parlato con alcuni sviluppatori del kernel Linux la situazione è diventata un po 'più chiara. Il problema principale è lo scheduler I / O, che non ha molta idea su quale I / O dare la priorità. Quindi qualsiasi input dell'utente e il seguente output grafico condividono la coda con l'attività del disco / rete. Di conseguenza, può anche accadere che possa eliminare i dati di processo memorizzati nella cache della pagina (ad esempio librerie caricate) quando conclude che può utilizzare la cache della pagina in modo più efficace su altri I / O. Ciò ovviamente significa che una volta che il codice dovrà essere eseguito di nuovo, dovrà essere recuperato di nuovo, dal disco che potrebbe essere già sotto carico.

Detto questo, per quanto riguarda il kernel Linux, molti di questi problemi sono stati risolti di recente (il problema è stato conosciuto), quindi diciamo che 4.4.xo 4.5.x dovrebbero comportarsi meglio rispetto al passato e che i problemi dovrebbero essere segnalati (generalmente le persone del kernel sono felici quando qualcuno vuole aiutare segnalando bug e test).

La mia esperienza è che l'attività I / O da sola non rallenta un sistema. Questo effetto si verifica quando anche altre attività richiedono I / O. La situazione diventerà davvero malvagia se il sistema sta scambiando (forzato) e quindi causi un carico I / O pesante.

È possibile influenzare l'impatto delle attività pesanti di I / O mediante ionice. Se le metti in idlepriorità, la latenza per altre attività potrebbe comunque aumentare ma non oltre il minimo. L'attività I / O viene immediatamente interrotta se un'altra attività (non inattiva) deve eseguire l'I / O. Se si utilizza uno scheduler che supporta queste impostazioni.

Vedere Selezione di uno scheduler I / O Linux