ecureuil_roux

J'en vois au moins un qui est prêt à en découdre avec le chrono... A vos marques, prêt ? Partez !



Quelque soit votre matériel ou votre système d'exploitation, il est un facteur qui va influer sur les performances, à savoir la capacité de vos disques à lire et écrire les données. Si l'on ajoute des stockages déportés au travers du réseau, les choses se compliquent encore..
Sous Linux, même si le cache système s'avère utile (sauf au premier lancement d'une appli), cette règle s'applique également.

Problème : On ne peut mesurer de la même manière les temps de lecture/écriture d'un disque, d'une partition ou d'un Raid logiciel et ceux d'un point de montage réseau.
Donc, voici une solution (parmi d'autres) pour chacune de ces deux situations.


Mesure de lecture standard avec la commande "hdparm"


  • "hdparm" est disponible sur les dépôts "base" de CentOS. S'il n'est pas installé sur votre système :
# yum install hdparm


  • Pour effectuer un test de lecture "cache" et "disque", repérez le disque dur à tester (/dev/sda, /dev/hdb, etc..) et lancez la commande ci-dessous en l'adaptant à votre situation :
# hdparm -tT /dev/sda


  • La CentOS (ou votre Linux) vous renvoie une paire de lignes qui devraient ressembler à ceci :
/dev/sda:
 Timing cached reads:   2224 MB in  2.00 seconds = 1113.08 MB/sec
 Timing buffered disk reads:  278 MB in  3.02 seconds =  92.19 MB/sec


  • Avec un montage Raid logiciel Linux (si md0 est la partition raid) :
# hdparm -tT /dev/md0
/dev/md0:
 Timing cached reads:   4068 MB in  2.00 seconds = 2034.49 MB/sec
 Timing buffered disk reads:  272 MB in  3.02 seconds =  90.09 MB/sec



Note : Évidemment, plus le chiffre est haut (2eme ligne surtout), mieux c'est.. En dessous de 40 MB/sec, les pertes en termes de performances auront un impact significatif sur l'utilisation de votre machine.


ATTENTION : "Hdparm" ne sert pas seulement à effectuer des mesures d'écriture. Il permet également de modifier les paramètres système de vos disques. Comme tous les outils de ce type, il peut s'avérer très efficace mais aussi très dangereux s'il est utilisé de manière incorrecte. Voici, à toutes fins utiles, les 7 options qu'il convient de ne pas "pousser" à la légère (vous noterez qu'elles ne font pas partie de notre ligne de tests) :

  • -m ==> Configurer le compte de secteur d'entrée-sortie multiple
  • -n ==> Paramétrage du booléen "ignorer les erreurs en écriture"
  • -p ==> Paramétrage du mode PIO (Programmed I/O) 3
  • -u ==> Paramétrage du booléen interrupt-unmask
  • -U ==> Dés-enclencher l'interface IDE (Unregister)
  • -w ==> Réinitialiser un périphérique
  • -X ==> Paramétrage du mode de transfert IDE (DMA mode 1, DMA mode 2, ultra DMA mode 2)


Pour plus d'informations, consultez les liens en bas de page.


Test d'écriture avec "dd" pour tous supports y compris montages réseau (NFS, samba et autres)


Quand le support n'est pas un disque physique, c'est à dire pour les cas de montage réseau et quelque soit le protocole (NFS, Samba, etc..), il existe une alternative avec l'ami "dd" (oui, le même que pour la création d'une image iso).

  • La ligne ci dessous effectue un test d'écriture (et création) d'un fichier " test.data " dans " /tmp ". A adapter avec vos partitions ou points de montage (changez seulement la partie "of=") :
# dd if=/dev/zero of=/tmp/test.data bs=8k count=128k


  • Exemple de retour de ce test (disque standard 5400 tr/min) :
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 16,5297 s, 65,0 MB/s


  • La taille des blocks (bs=8k) peut être adaptée à vos besoins. Ci après on monte à 16k sur le même support :
# dd if=/dev/zero of=/tmp/test.data bs=16k count=128k
131072+0 enregistrements lus
131072+0 enregistrements écrits
2147483648 octets (2,1 GB) copiés, 39,0226 s, 55,0 MB/s



Note : Les exemples ci-dessus donnent une idée assez proche des performances lors d'une utilisation classique poste de travail. Si le support à mesurer va recevoir (lire/écrire) des fichiers de très grande taille, augmentez le block size (bs=xxk) en conséquence.

Note 2 : pensez à effacer le fichier (/tmp/test.data) créé lors des tests quand vous aurez terminé.


Cas particulier - Les transferts de petits fichiers (et le protocole NFS V4)


Nous avons remarqué, notamment depuis la version 6 de CentOS et l'arrivée de NFS v4, une importante diminution des performances lors du transfert de grosses quantités de petits fichiers (exemples avec les dossiers /home ou encore les espaces web). Le problème ne se posait pas via Samba ou SSHFS.
Les tests décrits plus haut donnaient pourtant des résultats très intéressants. Et la même machine, avec les paramètres équivalents d'export et montage NFS, ne posait aucun souci sous CentOS 5.x.

Nous soupçonnons fortement les nouvelles options de sécurité introduites avec NFSV4 (entrées / sorties) sans pour autant avoir pu mettre en avant la cause réelle et précise du problème. Bien entendu, une page dédiée sera publiée dès que possible. Probablement lors des prochains tests avec NFS V4 et V4.1.




Liens utiles :





Vous pouvez commenter ou participer à l'amélioration de cet article via le topic dédié du forum.