iotop affichant 1,5 Mo / s d'écriture sur disque, mais tous les programmes ont 0,00 B / s


18

Je ne comprends pas la iotopsortie: elle affiche ~ 1,5 Mo / s d'écriture sur le disque (en haut à droite), mais tous les programmes ont 0,00 B / s. Pourquoi?

entrez la description de l'image ici

La vidéo a été prise alors que je supprimais le contenu d'un dossier contenant quelques millions de fichiers à l' aide perl -e 'for(<*>){((stat)[9]<(unlink))}' de Kubuntu 14.04.3 LTS x64.

iotopa été lancé à l'aide de sudo iotop.

Réponses:


22

Les informations affichées par iotop ne sont pas collectées de la même manière pour les processus individuels et pour le système dans son ensemble. Les chiffres globaux «réels» ne sont pas la somme des chiffres par processus (c'est ce qu'est le «total»).

Toutes les informations sont collectées à partir du système de fichiers proc .

  • Pour chaque processus, iotop lit les données , en particulier les valeurs et . Ce sont le nombre d'octets transmis dans et appels système (y compris des variantes telles que , , , , etc.)./proc/PID/iorcharwcharreadwritereadvwritevrecvsend
  • Les valeurs globales «réelles» sont lues /proc/vmstat, en particulier les valeurs pgpginet pgpgout. Ceux-ci mesurent les données échangées entre le noyau et le matériel (plus précisément, ce sont les données mélangées par la couche de périphérique de bloc dans le noyau).

Il existe de nombreuses raisons pour lesquelles les données par processus et les données de couche de périphérique de bloc diffèrent. En particulier:

  • La mise en cache et la mise en mémoire tampon signifient que les E / S se produisant sur une couche peuvent ne pas se produire en même temps ou le même nombre de fois sur l'autre couche. Par exemple, les données lues dans le cache sont comptabilisées comme une lecture du processus qui y accède, mais il n'y a pas de lecture correspondante sur le matériel (qui s'est déjà produite plus tôt, peut-être au nom d'un autre processus).
  • Les données au niveau du processus incluent les données échangées sur les canaux, les sockets et autres entrées / sorties qui n'impliquent pas de disque sous-jacent ou autre périphérique de bloc.
  • Les données au niveau du processus ne représentent que le contenu des fichiers, pas les métadonnées.

Cette dernière différence explique ce que vous voyez ici. La suppression de fichiers n'affecte que les métadonnées, pas les données, donc le processus n'écrit rien. Il peut être en train de lire le contenu du répertoire pour répertorier les fichiers à supprimer, mais c'est suffisamment petit pour qu'il puisse défiler inaperçu.

Je ne pense pas que Linux offre un moyen de surveiller les mises à jour des métadonnées de fichier. Vous pouvez surveiller les E / S par système de fichiers via les entrées sous /sys/fspour certains systèmes de fichiers. Je ne pense pas que vous puissiez comptabiliser les E / S de métadonnées par rapport à des processus spécifiques, ce serait très compliqué à faire dans le cas général, car plusieurs processus pourraient entraîner la lecture ou la modification des mêmes métadonnées.


1
Très belle réponse, merci. Recommanderiez-vous un moyen plus fiable de suivre l'évolution de la sortie?
Rui F Ribeiro

1
@RuiFRibeiro Vous pouvez voir quel fichier rm -rest en cours de traitement en l' straceengageant, mais cela ne vous donnera pas une estimation très utile du pourcentage d'achèvement car l'ordre de parcours dans chaque répertoire est quelque peu imprévisible. S'il n'y a qu'une seule opération massive en cours dans ce système de fichiers, et qu'il n'y a pas trop de liens durs impliqués, regarder df -ivous indique combien de fichiers ont été traités.
Gilles 'SO- arrête d'être méchant'
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.