J'ai des E / S CPU qui attendent régulièrement autour de 50%, mais quand je l'exécute, iostat 1il montre peu ou pas d'activité sur le disque.

Quelles sont les causes d'attente sans iops?

REMARQUE: Il n'y a pas de système de fichiers NFS ou FUSE ici, mais il utilise la virtualisation Xen.

NFS peut le faire, et cela ne me surprendrait pas si d'autres systèmes de fichiers réseau (et même des appareils basés sur FUSE) avaient des effets similaires.

Y a-t-il une chance que d'autres machines virtuelles sur le serveur débordent le disque?

Je sais qu'avec la virtualisation, vous pouvez obtenir des résultats étranges si le nœud hôte est surchargé.

S'il s'agit de l'environnement Amazon EC2 Xen utilisant un stockage basé sur une instance, demandez à Amazon de vérifier la santé de l'hôte contenant cette image.

S'il s'agit d'un environnement Xen auquel vous pouvez accéder à l'hyperviseur, vérifiez alors l'IOwait de l'extérieur pour l'image disque (fichier, réseau, tranche LVM, peu importe) utilisée pour les périphériques xvda et xvdb. Vous souhaiterez également vérifier le système d'E / S, en général, pour l'hyperviseur, car d'autres périphériques de disque peuvent monopoliser les ressources du système.

iostat -txk 5

est généralement un bon outil de diagnostic de départ. Il prend des résumés d'E / S de 5 secondes pour TOUS les périphériques à sa disposition et est donc utile à la fois avec et sans l'image de la machine virtuelle.

Vérifiez vos descripteurs / inodes de fichiers disponibles. Lorsque vous atteignez la limite, ils échangent et imitent iowait

Éditer

J'ai vu que vous utilisez xen, jetez un œil à vos interruptions actuelles, vous pourriez trouver que blkif est plus élevé que la normale.

Un peu en retard maintenant, mais installez munin et cela aidera vraiment le futur débogage.

sudo sysctl vm.block_dump=1

Ensuite, vérifiez dmesg pour voir ce qui effectue la lecture / écriture de bloc ou le salissement des inodes.

Vérifiez également la limite de nofile dans limits.conf, un processus pourrait demander plus de fichiers qu'il n'est autorisé à ouvrir.

AVERTISSEMENT: HDPARM EST DANGEREUX, TOUJOURS LIRE LA COMMANDE QUE VOUS ALLEZ UTILISER!

Si aucune autre machine virtuelle ne sollicite le ou les disques durs, faites

hdparm -f

sur le ou les disques physiques sous-jacents. Il est possible que le cache disque ne fonctionne pas correctement. Cela videra les données stockées dans le cache et vous pourrez surveiller en permanence les E / S, si elles sont sur le point de remonter après le vidage. Si oui, ce sera un problème de cache.

Avec la moyenne de charge, j'ai vu les opérations de mise en réseau bloquées (c'est-à-dire les appels longs vers un serveur de base de données externe) augmenter. Je ne sais pas avec certitude, mais je suppose que les E / S réseau peuvent provoquer une augmentation du processeur? Quelqu'un peut-il confirmer?

Il peut s'agir de périphériques de bouclage, eux-mêmes montés sur le réseau.

Sur mes machines, NFS est le plus grand "producteur" IO-WAIT. J'ai un SSD dans mon ordinateur portable qui est rapide comme l'enfer, donc le "vrai IO" n'est pas le problème. Néanmoins, j'ai parfois beaucoup d'attente d'E / S en raison de mes partages nfs montés.

SCP semble parfois conduire à IO Wait mais dans une bien moindre mesure.

Cela peut être n'importe quoi. Cela signifie simplement que quelque chose attend la fin de l'opération d'E / S. Vous pouvez déterminer de quel processus il s'agit via ps, puis y attacher gdb et vérifier la trace pour déterminer quel appel est bloqué (il s'agit généralement de choses liées au réseau ou d'un disque soudainement déconnecté). Pour plus d'informations sur fd, consultez / proc.

J'ai également rencontré un problème similaire juste avant l' échec d' un disque dans un RAID et certains câbles SATA avec des virages serrés ont commencé à échouer.

L'utilisation du processeur était proche de 0%, mais un ou plusieurs processeurs sur un système à 4 cœurs passaient 100% de leur temps dans IOwait pendant des périodes prolongées (trouvées via topun affichage CPU multi-lignes) avec des IOps et une bande passante très faibles (trouvés via iostat), mais une activité d'interruption élevée et éclatante. L'utilisation interactive de la ligne de commande a été pénible lors de tout accès au disque (c'est-à-dire la sauvegarde automatique de la emacssession de quelqu'un ) mais autrement tolérable une fois les périodes d'IOwait passées (et probablement les opérations ont réussi après de nombreuses tentatives).