Je suis perplexe et j'espère que quelqu'un d'autre reconnaîtra les symptômes de ce problème.
Matériel: nouveau Dell T110 II, Pentium G850 2,9 GHz double cœur, contrôleur SATA intégré, un nouveau disque dur câblé de 500 Go à 7200 tr / min dans la boîte, d'autres disques à l'intérieur mais pas encore montés. Pas de RAID. Logiciel: nouvelle machine virtuelle CentOS 6.5 sous VMware ESXi 5.5.0 (build 1746018) + vSphere Client. 2,5 Go de RAM alloués. Le disque est la façon dont CentOS a proposé de le configurer, à savoir en tant que volume dans un groupe de volumes LVM, sauf que j'ai ignoré avoir un / home séparé et simplement avoir / et / boot. CentOS est corrigé, ESXi corrigé, les derniers outils VMware installés sur la machine virtuelle. Aucun utilisateur sur le système, aucun service en cours d'exécution, aucun fichier sur le disque mais l'installation du système d'exploitation. J'interagis avec la machine virtuelle via la console virtuelle de machine virtuelle dans vSphere Client.
Avant d'aller plus loin, je voulais vérifier que j'avais configuré les choses plus ou moins raisonnablement. J'ai exécuté la commande suivante en tant que root dans un shell sur la machine virtuelle:
for i in 1 2 3 4 5 6 7 8 9 10; do
dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done
C'est-à-dire, répétez simplement la commande dd 10 fois, ce qui entraîne l'impression du taux de transfert à chaque fois. Les résultats sont inquiétants. Ça commence bien:
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...
mais après 7 à 8 d'entre elles, il imprime ensuite
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s
Si j'attends beaucoup de temps, disons 30 à 45 minutes, et que je l'exécute à nouveau, cela revient à 105 Mo / s, et après plusieurs tours (parfois quelques, parfois 10+), il tombe à ~ 20- 25 Mo / s à nouveau.
Sur la base d'une recherche préliminaire des causes possibles, en particulier VMware KB 2011861 , j'ai changé le planificateur d'ES Linux pour qu'il soit " noop" au lieu de la valeur par défaut. cat /sys/block/sda/queue/schedulermontre qu'il est en vigueur. Cependant, je ne vois pas que cela a fait une différence dans ce comportement.
En traçant la latence du disque dans l'interface de vSphere, il montre les périodes de latence de disque élevée atteignant 1,2 à 1,5 seconde pendant les périodes qui ddsignalent le faible débit. (Et oui, les choses ne répondent plus pendant que cela se produit.)
Qu'est-ce qui peut causer cela?
Je suis à l'aise que cela ne soit pas dû à la défaillance du disque, car j'avais également configuré deux autres disques en tant que volume supplémentaire dans le même système. Au début, je pensais avoir fait quelque chose de mal avec ce volume, mais après avoir commenté le volume à partir de / etc / fstab et redémarré, et essayé les tests sur / comme indiqué ci-dessus, il est devenu clair que le problème est ailleurs. C'est probablement un problème de configuration ESXi, mais je ne suis pas très expérimenté avec ESXi. C'est probablement quelque chose de stupide, mais après avoir essayé de comprendre cela pendant plusieurs heures sur plusieurs jours, je ne trouve pas le problème, alors j'espère que quelqu'un pourra m'orienter dans la bonne direction.
(PS: oui, je sais que ce combo matériel ne gagnera aucun prix de vitesse en tant que serveur, et j'ai des raisons d'utiliser ce matériel bas de gamme et d'exécuter une seule machine virtuelle, mais je pense que c'est en plus le point de cette question [à moins c'est en fait un problème matériel].)
ADDENDA # 1 : lecture d' autres réponses telles que celui - ci m'a fait essayer d' ajouter oflag=directà dd. Cependant, cela ne fait aucune différence dans la structure des résultats: au départ, les chiffres sont plus élevés pour de nombreux tours, puis ils tombent à 20-25 Mo / s. (Les nombres absolus initiaux sont dans la plage de 50 Mo / s.)
ADDENDUM # 2 : Ajouter sync ; echo 3 > /proc/sys/vm/drop_cachesdans la boucle ne fait aucune différence.
ADDENDUM # 3 : Pour supprimer d'autres variables, je lance maintenant de ddtelle sorte que le fichier qu'il crée est plus grand que la quantité de RAM sur le système. La nouvelle commande est dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Les nombres de débit initiaux avec cette version de la commande sont ~ 50 Mo / s. Ils tombent à 20-25 Mo / s lorsque les choses tournent au sud.
ADDENDUM # 4 : Voici la sortie de l' iostat -d -m -x 1exécution dans une autre fenêtre de terminal pendant que les performances sont "bonnes", puis à nouveau quand elles sont "mauvaises". (Pendant que ça continue, je cours dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) Premièrement, quand les choses sont "bonnes", cela montre ceci:
Quand les choses vont "mal", iostat -d -m -x 1cela montre:
ADDENDA # 5 : À la suggestion de @ewwhite, j'ai essayé d'utiliser tunedavec différents profils et j'ai également essayé iozone. Dans cet addendum, je rapporte les résultats de l'expérimentation pour savoir si différents tunedprofils ont eu un effet sur le ddcomportement décrit ci-dessus. J'ai essayé de changer le profil en virtual-guest, latency-performanceet throughput-performance, en gardant tout le reste identique, en redémarrant après chaque changement, puis à chaque exécution dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Cela n'a pas affecté le comportement: comme auparavant, les choses commencent bien et de nombreuses exécutions répétées ddaffichent les mêmes performances, mais à un moment donné après 10 à 40 exécutions, les performances diminuent de moitié. Ensuite, j'ai utilisé iozone. Ces résultats sont plus étendus, donc je les mets dans l'addendum # 6 ci-dessous.
ADDENDA # 6 : À la suggestion de @ewwhite, j'ai installé et utilisé iozonepour tester les performances. Je l'ai exécuté sous différents tunedprofils et j'ai utilisé un très grand paramètre de taille de fichier maximale (4G) pour iozone. (La machine virtuelle dispose de 2,5 Go de RAM alloués et l'hôte dispose de 4 Go au total.) Ces tests ont pris un certain temps. FWIW, les fichiers de données brutes sont disponibles sur les liens ci-dessous. Dans tous les cas, la commande utilisée pour produire les fichiers était iozone -g 4G -Rab filename.
- Profil
latency-performance:- résultats bruts: http://cl.ly/0o043W442W2r
- Feuille de calcul Excel (version OSX) avec tracés: http://cl.ly/2M3r0U2z3b22
- Profil
enterprise-storage:- résultats bruts: http://cl.ly/333U002p2R1n
- Feuille de calcul Excel (version OSX) avec tracés: http://cl.ly/3j0T2B1l0P46
Ce qui suit est mon résumé.
Dans certains cas, j'ai redémarré après une exécution précédente, dans d'autres cas, je ne l'ai pas fait, et j'ai simplement iozonerecommencé après avoir changé le profil avec tuned. Cela ne semble pas faire de différence évidente dans les résultats globaux.
Différents tunedprofils ne semblaient pas (à mes yeux certes inexpérimentés) affecter le large comportement rapporté par iozone, bien que les profils aient affecté certains détails. Tout d'abord, sans surprise, certains profils ont changé le seuil auquel les performances ont chuté pour l'écriture de très gros fichiers: en traçant les iozonerésultats, vous pouvez voir une falaise à 0,5 Go pour le profil, latency-performancemais cette baisse se manifeste à 1 Go sous le profilenterprise-storage. Deuxièmement, bien que tous les profils présentent une variabilité étrange pour des combinaisons de petites tailles de fichier et de petites tailles d'enregistrement, le modèle précis de variabilité diffère entre les profils. En d'autres termes, dans les graphiques ci-dessous, le motif escarpé du côté gauche existe pour tous les profils, mais les emplacements des fosses et leurs profondeurs sont différents dans les différents profils. (Cependant, je n'ai pas répété les exécutions des mêmes profils pour voir si le modèle de variabilité change sensiblement entre les exécutions de iozonesous le même profil, il est donc possible que ce qui ressemble à des différences entre les profils soit vraiment juste une variabilité aléatoire.)
Ce qui suit sont des tracés de surface des différents iozonetests pour le tunedprofil de latency-performance. Les descriptions des tests sont copiées à partir de la documentation de iozone.
Test de lecture: ce test mesure les performances de lecture d'un fichier existant.
Test d'écriture: ce test mesure les performances d'écriture d'un nouveau fichier.
Lecture aléatoire: ce test mesure les performances de lecture d'un fichier avec des accès à des emplacements aléatoires dans le fichier.
Écriture aléatoire: ce test mesure les performances d'écriture d'un fichier avec des accès à des emplacements aléatoires dans le fichier.
Fread: Ce test mesure les performances de lecture d'un fichier à l'aide de la fonction de bibliothèque fread (). Il s'agit d'une routine de bibliothèque qui effectue des opérations de lecture tamponnées et bloquées. Le tampon se trouve dans l'espace d'adressage de l'utilisateur. Si une application devait lire dans des transferts de très petite taille, la fonctionnalité d'E / S tamponnée et bloquée de fread () peut améliorer les performances de l'application en réduisant le nombre d'appels réels du système d'exploitation et en augmentant la taille des transferts lors du système d'exploitation. des appels sont effectués.
Fwrite: ce test mesure les performances d'écriture d'un fichier à l'aide de la fonction de bibliothèque fwrite (). Il s'agit d'une routine de bibliothèque qui effectue des opérations d'écriture en mémoire tampon. Le tampon se trouve dans l'espace d'adressage de l'utilisateur. Si une application devait écrire dans des transferts de très petite taille, la fonctionnalité d'E / S tamponnée et bloquée de fwrite () peut améliorer les performances de l'application en réduisant le nombre d'appels réels du système d'exploitation et en augmentant la taille des transferts lors du système d'exploitation. des appels sont effectués. Ce test est en train d'écrire un nouveau fichier donc encore une fois les frais généraux des métadonnées sont inclus dans la mesure.
Enfin, pendant le temps qui iozonefaisait son travail, j'ai également examiné les graphiques de performances de la machine virtuelle dans l'interface client de vSphere 5. J'ai basculé entre les tracés en temps réel du disque virtuel et la banque de données. Les paramètres de traçage disponibles pour la banque de données étaient supérieurs à ceux du disque virtuel, et les tracés de performances de la banque de données semblaient refléter ce que faisaient les tracés de disque et de disque virtuel, donc ici, je joins uniquement un instantané du graphique de la banque de données pris après la iozonefin (sous tunedprofil latency-performance). Les couleurs sont un peu difficiles à lire, mais ce qui est peut-être le plus notable, ce sont les pointes verticales nettes en lecturelatence (par exemple, à 4:25, puis à nouveau légèrement après 4:30, et à nouveau entre 4: 50-4: 55). Remarque: l'intrigue est illisible lorsqu'elle est intégrée ici, donc je l'ai également téléchargée sur http://cl.ly/image/0w2m1z2T1z2b
Je dois admettre que je ne sais pas quoi penser de tout ça. Je ne comprends surtout pas les profils de nids-de-poule étranges dans les petites régions d'enregistrement / de petite taille des iozoneparcelles.
iostatet il a montré une utilisation de ~ 90% avant et après. Mais je ne suis pas un expert dans le jugement de ces choses - peut-être que la saturation se produit quelque part. Je mets à jour ma question pour afficher la iostatsortie au cas où cela serait utile.
