Manpages

NOM

nhfsstone − Programme de mesure de performances du Système de Fichiers Réseau (NFS)

SYNOPSIS

nhfsstone [ −v ] [[ −t secs ] | [ −c appels ]] [ −l charge ] [ −p nprocs ] [ −m fichier_mix ] [ répertoire ]...

DESCRIPTION

nhfsstone (qui se prononce n−f−s−stone, le « h » étant silencieux) est utilisé sur un client NFS afin de générer un trafic artificiel constitué d’un mélange particulier d’opérations NFS. Il permet d’obtenir le temps de réponse en millisecondes du serveur par appel et le nombre d’appels par seconde. Le programme ajuste ses schémas d’appels d’après les statistiques du noyau du client et le temps écoulé. Le trafic peut être généré pour une certaine durée ou un certain nombre d’appels NFS.

Puisqu’il utilise les statistiques NFS du noyau pour surveiller sa progression, nhfsstone ne peut pas servir à mesurer la performance d’autres systèmes de fichiers que NFS.

Le programme nhfsstone manipule des fichiers et des répertoires dans le but de générer des opérations spécifiques à NFS en rapport avec les appels spécifiques du système. Dans ce but, il utilise plusieurs astuces qui sont basées sur la connaissance de l’implémentation du portage de référence de NFS du coté client. Par exemple, il se sert de noms de fichiers longs pour éviter le recours au cache de recherche de noms du noyau, afin que l’appel système à stat(2) génère une opération de recherche NFS.

Le mélange d’opérations NFS peut être défini dans un fichier de mix, qui est le résultat de la commande nfsstat(8C) (voir l’option « −m » ci−dessous). Les pourcentages indiqués dans le fichier de mix sont calculés d’après le nombre d’appels NFS , et non à partir des pourcentages affichés par nfsstat. Les opérations qui sont à 0% dans le mix ne seront jamais appelées par nhfsstone. Dans le mélange de charge d’un vrai serveur, même si le pourcentage d’appels pour une opération NFS précise peut être à zéro, le nombre d’appels est souvent non nul. Nhfsstone fait le pari que le nombre d’appels à ces 0 pour cent d’opérations aura un effet insignifiant sur les réponses du serveur.

nhfsstone s’attend normalement à une liste d’au moins deux répertoires de tests pour son usage (il s’agit du répertoire courant par défaut). Les répertoires de tests choisis devront être situés sur différents disques et partitions du serveur pour simuler de façon réaliste les charges typiques de serveur. Chaque processus nhfsstone cherche un répertoire <répertoire>/testdir<n> (<n> étant ici un nombre de 0 à nprocs − 1). Si le nom du répertoire pour ce processus existe déjà, la recherche de l’ensemble valide de fichiers de tests y sera faite. Dans le cas contraire, le répertoire sera créé et le jeu de fichiers de tests implanté.

OPTIONS

−m fichier_mix

Mélange d’opérations NFS à générer. Le format du fichier fichier_mix est identique à la sortie du programme nfsstat(8C). Un fichier_mix peut être créé sur un serveur en tapant la commande « nfsstat −s > fichier_mix ». Le mélange d’opération par défaut est le suivant : null 0%, getattr 13%, setattr 1%, root 0%, lookup 34%, readlink 8%, read 22%, wrcache 0%, write 15%, create 2%, remove 1%, rename 0%, link 0%, symlink 0%, mkdir 0%, rmdir 0%, readdir 3%, fsstat 1%.

UTILISATION de NHFSSTONE

Comme tous les outils de mesures, nhfsstone ne fournit des résultats utiles que si les tests réalisés sont définis avec précision. Puisqu’il teste des serveurs, il doit être exécuté à partir d’un client qui ne limitera pas la génération de requêtes NFS ce qui sous−entend que le client doit disposer d’un microprocesseur rapide, d’une bonne interface Ethernet, et que la machine ne doit servir à rien d’autre pendant la durée du test. Un Sun 3/50 peut générer jusqu’à 60 appels par seconde avant de dépasser les capacités du microprocesseur.

Nhfsstone implique que tous les appels NFS générés sur le client sont à destination d’un unique serveur, et que toutes les requêtes NFS adressées à ce serveur sont imputables à ce client. Afin de respecter au mieux cette hypothèse, le client et le serveur doivent être sollicités au minimum pendant ces tests.

Si le réseau est fortement encombré, les retards causés par les collisions peuvent cacher les variations de performances du serveur. Un important taux d’erreur tant du coté client que serveur peut aussi provoquer des ralentissements en raison de la retransmission des paquets perdus ou endommagés. L’usage de netstat(8C) −i permettra la mesure des taux d’erreurs et de collisions sur le client et le serveur.

Afin de mieux simuler les effets des clients NFS sur le serveur, les répertoires de test partagés par le serveur devraient être répartis sur au moins deux partitions du disque, et ces partitions être aussi éloignées que possible l’une de l’autre. La commande dkinfo(8) pourra servir à connaître la géométrie du disque dur pour les systèmes basés sur BSD. Les opérations NFS tentent d’accéder de manière aléatoire à l’ensemble du disque, d’où l’obtention de résultats peu probants lorsqu’on définit les répertoires de test de nhfsstone sur une seule partition, ou sur deux partitions trop proches l’une de l’autre.

Comme pour tous les tests, il est conseillé de les exécuter plusieurs fois et de comparer les résultats. Le nombre d’appels peut être augmenté (avec l’option −c) jusqu’à ce que la variation en millisecondes par appel devienne suffisamment petite. Si l’augmentation du nombre d’appels n’agit pas, c’est que quelque chose ne va pas dans le réglage des expérimentations. L’erreur est souvent liée à une taille mémoire trop importante sur la machine de test cliente. S’il y a trop de mémoire, nhfsstone n’arrive pas à tromper les caches du client et les opérations NFS ne parviennent pas du tout au serveur. Si vous suspectez un problème de cache, vous pouvez utiliser l’option −p afin d’augmenter le nombre de processus.

Les résultats obtenus par nhfsstone permettent de meilleurs comparatifs entre différentes configurations du serveur lorsque la configuration des tests de la machine cliente est identique. La modification des réglages de nhfsstone entre chaque essai produira des résultats dont la comparaison sera peu significative. Par exemple, modifier le nombre de processus générés peut modifier le temps de réponse mesuré sur la machine cliente (à cause du changement de contexte ou autres ralentissements), alors que la modification du mélange d’opérations NFS modifiera la nature même de l’expérience. Toute autre modification de la configuration du client pourra altérer la comparabilité des résultats. Même si nhfsstone tente de compenser les différences dans les configurations du client en analysant réellement les statistiques et en ajustant à la fois la charge et le mélange d’opérations, certaines modifications n’auront d’effet ni dans la charge, ni dans le mélange. Par exemple, l’installation d’un processeur plus rapide, ou le montage d’autres systèmes de fichiers NFS modifieront éventuellement le temps de réponse sans altérer la charge ou le mélange.

Afin de comparer différentes configurations du serveur, configurez tout d’abord les répertoires de test du client, puis exécutez nhfsstone avec différents niveaux de charges en vous assurant que la variation est suffisamment fine. Ensuite, lancez nhfsstone à différents niveaux de charges plus spécifiques et sauvegardez les résultats. Troisièmement, modifiez la configuration du serveur (en ajoutant de la mémoire, en remplaçant un contrôleur de disque, par exemple). Enfin, lancez une nouvelle fois les mêmes charges de nhfsstone et comparez les résultats.

VOIR AUSSI

Le fichier source nhfsstone.c contient des commentaires décrivant le détail des opérations du programme.

MESSAGES D’ERREUR

illegal calls value

L’argument appels qui suit le drapeau −c sur la ligne de commande n’est pas un nombre positif.

illegal load value

L’argument charge qui suit le drapeau −l sur la ligne de commande n’est pas un nombre positif.

illegal time value

L’argument time qui suit le drapeau −t sur la ligne de commande n’est pas un nombre positif.

bad mix file

Le fichier fichier_mix passé en argument au drapeau −m sur la ligne de commande n’est pas accessible.

can’t find current directory

Le processus père ne trouve pas le chemin d’accès au répertoire courant. Ceci est dû en général à un problème de droits d’accès.

can’t fork

Le processus père n’a pas pu créer(NdT : fork) de fils. Ceci est dû en général à un manque de ressources, telles que la mémoire ou l’espace d’échange (NdT : swap).

can’t open log file
can’t stat log
can’t truncate log
can’t write sync file
can’t write log
can’t read log

Un problème a été rencontré lors de la création, du découpage, de la lecture ou de l’écriture du fichier journal de synchronisation. Le processus crée un fichier journal dans /tmp afin de se synchroniser et de communiquer avec les processus fils.

can’t open test directory
can’t create test directory
can’t cd to test directory
wrong permissions on test dir
can’t stat testfile
wrong permissions on testfile
can’t create rename file
can’t create subdir

Un processus fils a rencontré un problème lors de la création de ses répertoires de tests, ou de la vérification de leurs contenus. Ceci est en général dû à un problème de droits d’accès (si le répertoire de test a été créé par un autre utilisateur par exemple) ou de manque d’espace sur le système de fichiers.

bad mix format: unexpected EOF after ’nfs:’
bad mix format: can’t find ’calls’ value
bad mix format: unexpected EOF after ’calls’
bad mix format: can’t find %d op values
bad mix format: unexpected EOF

Un problème a été rencontré lors de l’analyse du fichier mix. Le format attendu pour ce fichier est le même que la sortie de la commande nfsstat(8C) lancée avec l’option « −s ».

op failed:

Une des opérations pseudo−NFS internes a échouée. Le nom de cette opération (par exemple read, write, lookup) sera affichée accompagnée d’une description de la nature de l’erreur.

select failed

L’appel système select a renvoyé une erreur inattendue.

BOGUES

L’exécution de nhfsstone sur un système de fichiers non−NFS entraînera une boucle infinie, parce que ce programme interroge les statistiques NFS du noyau pour savoir quand le nombre d’appels suffisant est atteint.

Nhfsstone utilise un nombre important de descripteurs de fichiers. Le noyau de la machine client doit éventuellement être reconfiguré afin d’augmenter le nombre d’entrées disponibles dans la table des fichiers.

Les scripts shell qui utilisent nhfsstone devront intercepter et ne pas traiter le signal SIGUSR1 (voir signal(3)). Ce signal est utilisé dans le but de synchroniser les processus de test. Si ce signal n’est pas intercepté, alors le shell dans lequel tourne le script sera tué.

FICHIERS

TRADUCTION

Cette page de manuel a été traduite et est maintenue par Sylvain Cherrier <sylvain DOT cherrier AT free DOT fr> et les membres de la liste <debian−l10n−french AT lists DOT debian DOT org> depuis 2006. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le paquet manpages−fr−extra.