Solution 1 :
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 aussi probablement le temps d'attente pour permuter ou charger des pages en mémoire, par ex. des bibliothèques pas encore en mémoire, ou des pages de fichiers mmap() qui ne sont pas en RAM.
Il ne compte PAS le temps passé à attendre des objets IPC tels que sockets, pipes, ttys, select(), poll(), sleep(), pause() etc.
Fondamentalement, c'est le temps qu'un thread passe à attendre le disque-IO synchrone - pendant ce temps, il est théoriquement capable de fonctionner mais ne le peut pas car 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 charge moyenne d'une boîte.
De manière confuse, je pense que cela inclut probablement les E/S de fichiers sur les systèmes de fichiers réseau.
Solution 2 :
le temps d'attente correspond au temps qu'un processus passe dans le planificateur d'E/S du noyau. 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 inclura le temps passé à attendre les systèmes de fichiers réseau comme NFS.
Solution 3 :
Cela fait.
Incidemment, l'un des serveurs que je gère connaît un iowait élevé causé par 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 le D Etat.
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]
Solution 4 :
L'attente inclut 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 ceci se produit :
files->fd_array[5]->f_op->write(argv.......)
Ainsi, les processus ne savent pas quel type de système de fichiers utilise (magie vfs) et l'attente est la même pour un système de fichiers local.