# [IO WAIT] Mon PC lags ...

## loopx

Bonjour, 

Voilà, je viens à vous pour une question d'IO WAIT ... Je ne comprend pas trop le pourquoi du comment ...

En gros, voici ce que je fais actuellement :

- effacement d'un disque USB2 (shred) => 30Mo/s

- copie NFS => NAS (gros fichiers) => 10 bon Mo/s

Au niveau de l'IO WAIT, je constate que :

- uniquement avec le shred, j'ai déjà 1/4 d'IO WAIT ... (~25% donc)

- avec shred + NFS, je fais des pics à 60% ... et mon pc se met à freezer pendant un temps ...

Alors, voici voilou, je ne comprend absolument pas le rapport entre, par exemple, Chromium et la copie NFS ou la destruction via Shred ... Et pourtant, mon chromium freeze, le scrooling bloque ... C'est horrible et honnêtement, je ne trouve pas ça normal ...

Bon alors, niveau matos et autre :

- core i7 930 avec hyper threading => 8 cores ...

- 6Go de mémoire ...

- utilisation de AutoFS pour le mount des shares de mon NAS synology (me dite pas que c'est mon NAS : c'est le DS411+II ... un truc d'entreprise ...)

- mon réseau est en 100Mbits ...

Les mouts actuel ? :

```

loopx@loop ~ $ df -h

Sys. de fichiers      Taille Util. Disp. Uti% Monté sur

rootfs                   58G   20G   36G  36% /

/dev/root                58G   20G   36G  36% /

rc-svcdir               1,0M  120K  904K  12% /lib64/rc/init.d

udev                     10M  344K  9,7M   4% /dev

shm                     3,0G  2,3M  3,0G   1% /dev/shm

/dev/sdb4               516G  478G   12G  98% /mnt/data

tmpfs                   3,0G   24K  3,0G   1% /tmp

tmpfs                   3,0G   35M  2,9G   2% /var/tmp

cargo:/volume1/toto    5,4T 1004G  4,4T  19% /mnt/cargo/toto

```

Bon alors, quelqu'un aurait-il une idée ??? Parce que je comprend pas de trop .. peut être mon kernel qui débloque ... Est-ce que le comportement que je décrit est, pour vous, normal ???

Il m'est arrivé, l'autre jour d'avoir le pointeur de la souris qui se figeait .... sur une telle machine, laissez-moi vous dire que ça dégoûte un peu ... 

Merci   :Razz: 

----------

## guilc

Tu pourras avoir la machine la plus puissante du monde que ça ne réduira pas ton I/O wait pour autant !

Dans les 2 cas que tu évoques : écritures USB et copie réseau, ce sont 2 opérations couteuses en IO. Le kernel découpe les taches en opération "minimales" qu'il ne peut pas interrompre. Si ces taches sont de l'IO (une attente d'un paquet réseau, une opération d'IO sur l'USB), ces opérations peuvent être longues, notamment à cause des latences sur ces supports.

Du coup, les tâches qui attendent derrière sont bloquées et subissent toutes cette latence ! L'iowait, c'est ça : le CPu est monopolisé à attendre les IO plutôt qu'à faire des calculs.

Pour améliorer ça, quelques pistes :

- ne plus utiliser l'USB mais quand c'est possible une connexion e-SATA qui a une bande passante très supérieure et des latences infiniment plus basses. Utiliser aussi un disque le plus rapide possible.

- Pour le réseau, travailler sur du gigabit qui permettra là encore d'améliorer la bande passante du réseau et de repousser le facteur limitant. Accessoirement, que ton NAS ait des disques rapides aussi, car oui, ça pourrait être ton NAS  :Wink: 

- Essayer un autre scheduler. Si comme je le supposes tu utilises le défaut standard, CFQ, tu devrais peut-être tenter AS, qui devrait réduire les latences précisément dans ce cas ou une tache mobilise la bande passante.

- Faire un tour du côté des cgroup (http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt) pour affiner le comportement du scheduler.

[EDIT]

Arf, l'AS a été retiré du kernel... Dommage.

Une autre piste : t'assurer que ton kernel est bien préemptible : CONFIG_PREEMPT_VOLUNTARY voire CONFIG_PREEMPT.

----------

