La proc(5)page de manuel décrit iowait comme "le temps d'attente pour que les E / S se terminent". Cela a été principalement expliqué dans une question précédente. Ma question est la suivante: en attendant de bloquer les E / S, cela inclut-il d'attendre sur les E / S réseau bloquantes ou uniquement les E / S locales?
Réponses:
Cela signifie attendre "File I / O", c'est-à-dire tout appel en lecture / écriture sur un fichier qui se trouve dans le système de fichiers monté, mais compte également probablement le temps d'attente pour échanger ou charger des pages en mémoire, par exemple les bibliothèques non encore en mémoire, ou des pages de fichiers mmap () qui ne sont pas dans le ram.
Il ne compte PAS le temps passé à attendre les objets IPC tels que les sockets, les tuyaux, les ttys, select (), poll (), sleep (), pause () etc.
Fondamentalement, il est temps qu'un thread passe à attendre un disque-IO synchrone - pendant ce temps, il est théoriquement capable de s'exécuter mais ne peut pas parce que certaines données dont il a besoin ne sont pas encore là. De tels processus apparaissent généralement dans l'état "D" et contribuent à la moyenne de charge d'une boîte.
Confusément, je pense que cela inclut probablement les E / S de fichiers sur les systèmes de fichiers réseau.
le temps d'attente est le temps qu'un processus passe dans le planificateur d'E / S du noyau. Pour autant que je sache, cela n'a rien à voir avec les E / S réseau dans la mesure où les connexions de socket régulières vont. Cependant, cela comprendra le temps passé à attendre les systèmes de fichiers réseau comme NFS.
Cela fait.
Soit dit en passant, l'un des serveurs que je gère connaît un niveau élevé qui est dû à un mauvais montage NFS.
top - 06:19:03 up 14 days, 10:15, 3 users, load average: 9.67, 11.83, 12.31
Tasks: 135 total, 1 running, 134 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st
top - 06:22:55 up 14 days, 10:19, 3 users, load average: 10.58, 11.13, 11.89
Tasks: 137 total, 1 running, 136 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 0.0%id, 99.8%wa, 0.0%hi, 0.0%si, 0.0%st
Et regardez les processus dans l' Détat.
root 27011 0.0 0.0 0 0 ? S 03:12 0:00 [nfsd4]
root 27012 0.0 0.0 0 0 ? S 03:12 0:00 [nfsd4_callbacks]
root 27013 0.0 0.0 0 0 ? D 03:12 0:01 [nfsd]
root 27014 0.0 0.0 0 0 ? D 03:12 0:01 [nfsd]
root 27015 0.0 0.0 0 0 ? D 03:12 0:01 [nfsd]
root 27016 0.0 0.0 0 0 ? D 03:12 0:01 [nfsd]
L'iowait comprend les appels réseau. Je dis cela, car NFS est géré comme autant de systèmes de fichiers locaux Linux du point de vue du noyau:
$ vim linux-2.6.38.2/fs/nfs/file.c
const struct file_operations nfs_file_operations = {
.llseek = nfs_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = nfs_file_read,
.aio_write = nfs_file_write,
.mmap = nfs_file_mmap,
.open = nfs_file_open,
.flush = nfs_file_flush,
.release = nfs_file_release,
.fsync = nfs_file_fsync,
.lock = nfs_lock,
.flock = nfs_flock,
.splice_read = nfs_file_splice_read,
.splice_write = nfs_file_splice_write,
.check_flags = nfs_check_flags,
.setlease = nfs_setlease,
};
Lorsque les processus appellent une écriture sur le descripteur de fichier 5, quelque chose comme cela se produit:
files->fd_array[5]->f_op->write(argv.......)
Ainsi, le processus ne sait pas quel type de système de fichiers utilise (vfs magic) et l'iowait est le même que pour un système de fichiers local.