Pourquoi les systèmes deviennent-ils lents lors des écritures massives sur le disque?

8

Je veux savoir pourquoi les systèmes deviennent lents lors de l'écriture de données de masse sur disque.

Je pense que pour que le système devienne lent, il devrait y avoir un problème avec le CPU. Mais l'écriture est uniquement liée aux E / S.

Des interruptions matérielles se produisent-elles lors de l'écriture des données? Si c'est le cas, c'est peut-être à cause des interruptions que le CPU est toujours en train de changer de contexte.

kuafu
la source
1
Je pense que presque toutes les applications vont lire / écrire des données à partir du disque, n'est-ce pas?
jilen
1
Peut-être qu'il est en train d'échanger en mémoire et donc de ralentir, lorsque le disque est sous une utilisation intensive autrement. Un plugin de chargement de système pourrait vous dire si vous utilisez le swap de manière graphique. Pour la ligne de commande, utilisez free.
utilisateur inconnu
1
Si sysstat est configuré / en cours d'exécution, vous pouvez consulter les rapports SAR pour les temps lents et il vous montrera ce qui se passe à ce moment-là (changements de contexte, E / S disque, charge CPU, trafic réseau, etc.).
Bratchley
Jetez également un œil à vos $PATHparamètres si vous utilisez la commande-complétion ou faites beaucoup d'erreurs d'orthographe. La consultation de nombreux répertoires, en particulier ceux contenant de nombreuses entrées de répertoire, peut prendre du temps, ce qui est perceptible lorsque les ressources sont rares.
MattBianco

Réponses:

3

La raison principale derrière cela est que l'habituel: les E / S sont beaucoup plus lentes que le CPU / RAM. Même si les processus effectuant des opérations d'E / S utilisent DMA (qui décharge la CPU), à un moment donné, ils devront probablement attendre la fin de leurs demandes.

Dans le cas le plus courant d'un disque dur, ajoutez simplement plusieurs applications essayant d'accéder aux fichiers dispersés autour du lecteur, et vous pouvez vous faire un café (thé, peu importe). Avec les SSD, la situation s'améliore, mais même un SSD - qui a un débit mesuré en centaines de Mo / s sur SATA (par rapport à des dizaines de Mo / s d'un disque dur à plateau tournant) et des temps de recherche vraiment négligeables (par rapport aux millisecondes pour une plaque tournante) - peut devenir un goulot d'étranglement.

Le problème que je comprends n'est pas seulement dans les transferts de données eux-mêmes, mais dans la surcharge nécessaire - les E / S sont contrôlées par le noyau, mais ne se produisent que rarement sans espace utilisateur. Ainsi, il peut y avoir beaucoup de changements de contexte, juste à partir des applications en attente d'E / S vérifiant si quelque chose se passe (dépend de la mise en œuvre, bien sûr). Dans le cas des transferts de disques, il peut y avoir plusieurs threads du noyau en compétition pour les ressources ou en attente occupée (ce qui est parfois la stratégie appropriée). N'oubliez pas, par exemple, la copie de données d'une partition à une autre nécessite un système de fichiers moderne pour: savoir où se trouvent les données source, les lire, allouer de l'espace sur le système de fichiers cible, écrire des métadonnées, écrire des données, répéter jusqu'à la fin.

Et si, à un moment donné, votre système commence à échanger (qui a généralement une priorité plus élevée que les E / S normales), la catastrophe est finalisée.

EDIT : Après avoir parlé à certains développeurs de noyau Linux, la situation est devenue un peu plus claire. Le problème principal est le planificateur d'E / S, qui n'a pas beaucoup d'idée sur les E / S à prioriser. Par conséquent, toute entrée utilisateur et sortie graphique suivante partage la file d'attente avec l'activité disque / réseau. En conséquence, il peut également arriver qu'il jette les données de processus mises en cache du cache de pages (par exemple, les bibliothèques chargées) lorsqu'il conclut qu'il peut utiliser le cache de pages plus efficacement sur d'autres E / S. Cela signifie bien sûr qu'une fois que le code doit être exécuté à nouveau, il devra être récupéré à nouveau - former le disque qui peut déjà être sous une lourde charge.

Cela dit, en ce qui concerne le noyau Linux, bon nombre de ces problèmes ont été corrigés récemment (le problème est connu), alors dites 4.4.x ou 4.5.x devrait se comporter mieux qu'auparavant et les problèmes doivent être signalés (généralement les gens du noyau sont contents quand quelqu'un veut aider en rapportant des bogues et en testant).

peterph
la source
Pourriez-vous expliquer un peu pourquoi le système global est à la traîne lorsque les E / S sont très occupées? Par exemple, je ne vois aucune connexion entre Windows Manager et IO - évidemment, WM ne fait aucune IO, alors pourquoi commencerait-il à être à la traîne (au moins, quand il n'est pas échangé) ?
Hi-Angel
WM peut en fait faire beaucoup d'E / S via le serveur X / compositeur Wayland (pas autant que copier quatre flux de données entre 2 disques durs, mais cela ne doit pas être complètement négligeable - ce qui est probablement l'une des raisons qui awesomesemble travailler un peu mieux que kwindans ce sens).
peterph
Mais quel type d'E / S fait-il? Est-ce simplement à cause de la connexion à xsession-errors/ Xorg.ₙ.log? La journalisation n'est-elle pas simplement mise en mémoire tampon, sans interruption du travail WM? Rien d'autre? UPD: Je viens de regarder le /proc/AwesomePID/fd- le seul fichier ouvert par ma WM est xsession-errors. Tout le reste pas vraiment un fichier - prises, /dev/null, /proc/stat...
Salut-Angel
1
Mais vous dites que WM peut en fait faire beaucoup d'E / S via le serveur X / compositeur Wayland . Mais peu importe, pourquoi pensez-vous qu'il n'obtient pas assez de CPU. Lorsque cela se produit, le processeur est généralement assez libre - je peux voir la charge dans le widget CPU sur mon panneau, et décompresser une archive ne prend pas beaucoup de temps.
Hi-Angel
1
@ Salut-Angel vérifier la mise à jour de réponse si cela clarifie un peu les choses.
peterph
2

D'après mon expérience, l'activité d'E / S seule ne ralentit pas un système. Cet effet se produit lorsque d'autres tâches nécessitent également des E / S. La situation deviendra vraiment mauvaise si le système est échangé (forcé de) et que vous causez alors une lourde charge d'E / S.

Vous pouvez influencer l'impact des tâches lourdes d'E / S par ionice. Si vous les mettez en idlepriorité, alors la latence pour d'autres tâches peut encore augmenter mais pas au-delà du minimum. La tâche d'E / S est interrompue immédiatement si une autre tâche (non inactive) doit effectuer des E / S. Si vous utilisez un planificateur qui prend en charge ces paramètres.

Voir Sélection d'un planificateur d'E / S Linux

Hauke ​​Laging
la source
1
Mon expérience est le contraire: c'est-à-dire que je peux commencer à déballer une grande archive - provoquant une charge d'E / S - et en essayant à ce moment de basculer vers un autre «bureau», je sens des retards de la commutation. Comment le gestionnaire de fenêtres est-il même pertinent pour les E / S ?? Et oui, j'ai une RAM gratuite, donc elle n'est pas échangée (et même si je ne l'ai pas - WM n'a-t-il pas échangé au dernier tour?) . FWIW, j'utilise un Awesome WM léger, et plus tôt avec kwin, les choses étaient encore pires.
Hi-Angel