Analyse des performances du serveur NFS Linux


22

Je voudrais faire une analyse de notre serveur NFS pour aider à détecter les goulots d'étranglement potentiels dans nos applications. Le serveur exécute SUSE Enterprise Linux 10.

Le genre de choses que je cherche à savoir sont:

  • Quels fichiers sont consultés par quels clients
  • Débit de lecture / écriture par client
  • Frais généraux imposés par d'autres appels RPC
  • Temps passé à attendre d'autres demandes NFS, ou des E / S disque, pour entretenir un client

Je connais déjà les statistiques disponibles /proc/net/rpc/nfsdet en fait j'ai écrit un article de blog les décrivant en profondeur. Ce que je recherche, c'est un moyen de creuser plus profondément et d'aider à comprendre quels facteurs contribuent à la performance vue par un client particulier. Je souhaite analyser le rôle joué par le serveur NFS dans les performances d'une application sur notre cluster afin de réfléchir aux moyens de l'optimiser au mieux.


Cela semble être le genre de chose pour laquelle le système tap a été écrit. Les documents sont un peu merdiques, mais je suppose que vous pourriez préparer quelque chose pour faire ce genre d'analyse en l'utilisant. sourceware.org/systemtap/examples/keyword-index.html
Cian

Réponses:


2

Juste une idée, essayez de renifler le trafic NFS avec Wireshark. Pourrait vous dire quel utilisateur a accédé à quel fichier:

tshark -R nfs -i eth0

2

Je dois dire de tous les différents utilitaires * stat disponibles pour un, nfsstat est de loin le pire! Il vous donne la possibilité de regarder un tas de compteurs, mais c'est tout. Si vous les regardez deux fois, VOUS devez faire le travail d'essayer de déterminer combien de chaque compteur a changé et si vous voulez connaître le taux de changement, vous devez alors le diviser par le nombre de secondes entre les échantillons. En toute honnêteté, nfsstat remonte à plusieurs années quand les choses étaient encore assez grossières et est maintenant gêné par personne ne voulant changer le format de sortie car cela casserait probablement beaucoup de choses.

Quant à l'utilisation de collectl pour surveiller nfs, il fournit une sortie nfsstat dans un format beaucoup plus facile à lire, mais ce qui est encore mieux, vous pouvez le laisser fonctionner pendant des heures ou des jours et lire les données que vous avez collectées en arrière-plan. En ce qui concerne la demande de voir ce que font les processus, collectl peut également collecter des données de processus, y compris le nombre d'E / S effectuées par chaque processus et même les lire en affichant les meilleurs utilisateurs d'E / S. Vous pouvez également utiliser la fonctionnalité supérieure en temps réel.

Si vous voulez regarder le thème des disques, collectl peut également le faire et afficher tout dans un affichage coordonné.

Vérifiez-le ... -mark


2

collectl (en particulier son sous-système NFS ) est un très bon utilitaire qui pourrait être utile pour votre analyse mais il ne correspond pas à votre liste d'exigences. Je ne connais aucun utilitaire Linux qui le fasse.

(S'il vous plaît, laissez-moi ajouter cette note hors sujet: il existe un logiciel qui correspond à vos besoins: Sun Analytics basé sur DTrace (pdf) - mais malheureusement n'est pas disponible sur Linux. Vous trouverez de nombreux exemples sur le blog de Brendan Gregg qui illustrent les capacités de cet outil.)



1

À mon avis, cela met exactement en évidence le problème des outils d'aujourd'hui. Ici, nous sommes mentionnés au moins 3, y compris nfsstat, iostat et iotop. Ensuite, il a été fait mention du partage de fils et de nfsreplay. Cela ressemble-t-il vraiment à une façon normale de faire les choses? À part wireShark avec une catégorie qui lui est propre, ne préférez-vous pas 1 outil?

Pour les ouvreurs, bien que je trouve la sortie d'iostat très utile, c'est trop difficile à lire avec tous ces .00 dans les chiffres. Collectl rapporte les mêmes données exactes mais formatées beaucoup plus facilement pour les yeux. Vous savez déjà ce que je pense de nfsstat et puisque collectl peut lire toutes les données, il n'y a pas besoin d'un utilitaire de «relecture». Quant à «iotop», collect peut également afficher les processus triés par tout ce qui inclut les E / S.

Donc, vous avez tout cela aussi, avec des horodatages. Si vous avez besoin d'un intervalle de surveillance plus fin, vous pouvez toujours ramener l'échantillonnage à 0,1 ou 0,5 seconde ou quoi que ce soit entre les deux, bien que vous générerez plus de surcharge si vous surveillez les processus aussi rapidement, mais avec n'importe quel utilitaire de surveillance de processus.

ET le bonus final est tout ce que vous collectez avec collectl que vous pouvez charger dans une feuille de calcul et tracer facilement OU utiliser colplot qui fait partie de collectl-utils.

-marque


1

Vous voudrez peut-être essayer à nfswatchpartir de http://nfswatch.sourceforge.net

Vous pouvez voir un exemple de sortie sur http://prefetch.net/blog/index.php/2009/06/16/monitoring-nfs-operations-with-nfswatch/

nfswatchest un peu comme top(même si je ne suis pas sûr qu'il y ait un mode batch). Une fois qu'il est en cours d'exécution, vous pouvez modifier l'affichage en appuyant sur une touche (par exemple, "c" pour afficher les clients NFS à l'aide de votre serveur NFS).

Dans mon bref test, cependant, nfswatchne semble pas fonctionner avec NFSv4.


1
Suggestion intéressante. En fait, l'auteur lui-même dit que NFSv4 n'est pas pris en charge et que l'outil n'a pas été mis à jour depuis environ 3 ans. Dommage car ce serait d'une grande utilité!
Tonin

1

Je n'ai pas de meilleures réponses pour le moment, mais vous pouvez suivre assez précisément le disque IO avec

iostat -mx <delay in sec.> <devices>

Il donne des chiffres très utiles, en particulier la taille moyenne de la file d'attente et le temps d'attente (en ms) pour vos E / S. Il indique assez facilement si vos disques sont un goulot d'étranglement et si le goulot d'étranglement est le nombre d'E / S ou le débit.

Puis avec

netstat -plaute | grep nfs

Vous verrez les connexions client et les octets transférés de chaque client en temps réel. boucle dessus pour des données continues. Ce serait assez facile de faire un script qui fournisse des données continues ... J'y travaille :)

Maintenant, pour obtenir des E / S par processus, vous pouvez utiliser l'excellent iotop . Cependant, vous devez toujours trouver un moyen de faire correspondre les processus nfsd avec les clients.

Quant à savoir quels fichiers sont accessibles par quel client, je suis bloqué. En fait, les fichiers actuellement lus / écrits à partir d'un client NFS n'apparaissent même pas dans la sortie lsof.

Juste pour développer le netstat, utilisez watch -d pour voir comment les choses changent et trient par hôte

watch -d "netstat -plaute | grep nfs | sort -k 4,5"

C'est la meilleure solution que j'ai trouvée jusqu'à présent pour savoir quel hôte est à l'origine du trafic sur NFS. Ensuite, je peux aller chez le client pour savoir à quel fichier il accède. Merci!
peschü

0

Vous voudrez peut-être consulter nfsreplay. Cela pourrait vous aider à comprendre ce qui se passe. Vous trouverez également les informations et les liens ici utiles

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.