Solución 1:
Significa esperar por "E/S de archivo", es decir, cualquier llamada de lectura/escritura en un archivo que está en el sistema de archivos montado, pero probablemente también cuente el tiempo de espera para intercambiar o solicitar la carga de páginas en la memoria, p. bibliotecas que aún no están en la memoria, o páginas de archivos mmap() que no están en la RAM.
NO cuenta el tiempo de espera de objetos IPC como sockets, tuberías, ttys, select(), poll(), sleep(), pause(), etc.
Básicamente, es el momento en que un subproceso pasa esperando la E/S de disco síncrona; durante este tiempo, en teoría, puede ejecutarse, pero no puede porque algunos datos que necesita aún no están allí. Dichos procesos generalmente aparecen en estado "D" y contribuyen al promedio de carga de una caja.
De manera confusa, creo que esto probablemente incluye el archivo IO en los sistemas de archivos de red.
Solución 2:
el tiempo de espera es la cantidad de tiempo que pasa un proceso en el planificador de E/S del kernel. Hasta donde yo sé, esto no tiene nada que ver con la E/S de la red en lo que respecta a las conexiones de socket regulares. Sin embargo, incluirá el tiempo de espera de sistemas de archivos de red como NFS.
Solución 3:
Lo hace.
Por cierto, uno de los servidores que administro está experimentando un alto iowait causado por un mal montaje de 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
Y mira los procesos en el D estado.
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]
Solución 4:
El iowait incluye las llamadas de red. Digo esto porque NFS se maneja como muchos sistemas de archivos locales de Linux desde el punto de vista del kernel:
$ 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,
};
Cuando los procesos llaman a escribir en el descriptor de archivo 5, sucederá algo como esto:
files->fd_array[5]->f_op->write(argv.......)
Entonces, los procesos no saben qué tipo de sistema de archivos están usando (vfs magic) y iowait es lo mismo que un sistema de archivos local.