Output Queue Length counter, on affiche une description de l’avertissement de performance.

La figure 5 contient plusieurs valeurs intéressantes. Le compteur Current Bandwidth montre 100 mégabits, indiquant que le NIC 10/100 fonctionne en fait à 100 Mbps. Le compteur Bytes Total/sec est à 3,6 Mbps, soit bien en dessous de la capacité du réseau. (Je sais que sur le serveur qui a produit ce rapport, tout le trafic du réseau sur le segment allait vers le DC ou en venait.) Enfin, nous voyons que Bytes Sent/sec représente la quasi-totalité du trafic. C’est logique, compte tenu que les recherches LDSP extraient beaucoup de données.

Mais alors pourquoi la file d’attente de sortie est-elle si longue ? On peut avancer plusieurs hypothèses :
• Le NIC a atteint sa capacité maximale, ou s’en approche.
• Il y a trop peu de tampons de sortie configurés pour le NIC.
• Le traitement des files d’attente de sortie est lent, tout simplement parce que la CPU n’est pas assez puissante.

Bien que, selon le rapport, le débit total moyen sur le NIC soit de 3,6 Mbps, il a connu une pointe à 10,8 Mbps, qui dépasse le maximum théorique de 100 Mbps (environ 10 Mbps). Il semble donc que le NIC soit parfois surchargé, ce qui laisse supposer que d’autres composants sur le segment du réseau pourraient l’être eux aussi. Comme la CPU est près de son maximum, il ne servirait probablement à rien d’ajouter un autre NIC. Il faudrait pousser l’analyse plus loin pour parvenir à une réponse définitive, mais le plus sage est probablement de réduire la charge sur le serveur en optimisant les requêtes (ou en ajoutant un index) et, si nécessaire, soit en passant à une CPU plus rapide, soit en ajoutant un autre DC et en répartissant la charge de requête.