NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Introduction a l'administration systeme - Puissance de traitement et largeur de bande
Red Hat Enterprise Linux 4: Introduction � l'administration syst�me
Chapitre 3. Puissance de traitement et largeur de bande
Des deux ressources examin�es dans ce chapitre, la largeur de bande est souvent de compr�hension difficile pour les administrateurs alors que la puissance de traitement est un concept beaucoup plus simple � saisir.
De plus, ces deux ressources ne semblent pas vraiment �troitement li�es — alors pourquoi les regrouper�?
Ces deux ressources sont examin�es ensemble car elles sont toutes les deux bas�es sur le mat�riel responsable de la capacit� d'un ordinateur � d�placer et traiter des donn�es. Dans ce sens, ces deux ressources entretiennent souvent une relation d'interd�pendance.
3.1. Largeur de bande
Au niveau le plus �l�mentaire, la largeur de bande repr�sente la capacit� de transfert de donn�es — en d'autres termes, la quantit� de donn�es pouvant �tre transf�r�e d'un point � un autre au cours d'une dur�e d�termin�e. Toute communication de donn�es point � point n�cessite deux �l�ments�:
Un ensemble de conducteurs �lectriques permettant d'�tablir une communication � deux niveaux
Un protocole pour faciliter la communication efficace et fiable des donn�es
� ce titre, deux types de composants syst�me satisfont ces obligations�:
Bus
Chemins des donn�es
Les sections suivantes abordent chacun des deux composants de mani�re d�taill�e.
3.1.1. Bus
Comme nous l'avons mentionn� pr�c�demment, les bus permettent une communication point � point et utilisent un certain type de protocole pour garantir que toutes les communications aient lieu de mani�re contr�l�e. Ceci �tant, les bus affichent d'autres caract�ristiques particuli�res�:
Des caract�ristiques �lectriques normalis�es (telles que le nombre de conducteurs, les niveaux de tension, les vitesses de signalisation, etc.)
Des caract�ristiques m�caniques normalis�es (telles que le type de conducteurs, la taille de la carte, la disposition physique, etc.)
Protocol normalis�
Le terme "normalis�" est important car les bus repr�sentent le moyen de base par lequel les diff�rents composants du syst�me sont reli�s entre eux.
Dans bien des cas, les bus permettent l'interconnexion du mat�riel con�u par de multiples fabricants, une op�ration qui s'av�rerait impossible en l'absence de normalisation. Toutefois, m�me dans les situations o� un bus est la propri�t� d'un fabricant particulier, la normalisation est importante car elle permet � ce dernier d'impl�menter plus facilement diff�rents composants gr�ce � une interface commune — le bus lui-m�me.
3.1.1.1. Exemples de bus
O� que vous regardiez dans un ordinateur, vous remarquerez la pr�sence de bus. Parmi les plus courants figurent�:
Les bus de stockage de masse (ATA et SCSI)
Les r�seaux[1] (Ethernet et Token Ring aussi appel� anneau � jetons)
Les bus m�moire (PC133 et Rambus®)
Les bus d'expansion (PCI, ISA, USB)
3.1.2. Chemins des donn�es
Les chemins des donn�es eux peuvent �tre plus difficiles � identifier mais, tout comme les bus, ils sont pr�sents partout dans un ordinateur. De m�me que les bus, les chemins des donn�es permettent �galement une communication point � point. Toutefois, � la diff�rence des bus, les chemins aux donn�es�:
utilisent un protocole plus simple (s'ils en utilisent un)
ne respectent que peu (voire pas du tout) la normalisation m�chanique
Ces diff�rences s'expliquent par le fait que les chemins des donn�es sont g�n�ralement internes � certains composants syst�me et ne sont pas utilis�s pour faciliter l'interconnexion improvis�e de diff�rents composants. En tant que tels, les chemins des donn�es sont particuli�rement adapt�s pour des situations o� une vitesse �lev�e et un co�t moindre repr�sentent une priorit� importante par rapport � des situations disposant d'une souplesse g�n�rale obtenue gr�ce � une vitesse basse et un co�t �lev�.
3.1.2.1. Exemples de chemins des donn�es
Ci-apr�s figurent certains chemins des donn�es typiques�:
CPU vers le chemin des donn�es d'un cache sur puce
Processeur graphique vers le chemin des donn�es de la m�moire vid�o
3.1.3. Probl�mes potentiels li�s � la largeur de bande
Les probl�mes en relation avec la largeur de bande peuvent se produire de deux mani�res (aussi bien pour les bus que pour les chemins des donn�es)�:
Les bus et les chemins des donn�es peuvent constituer une ressource partag�e. Dans ce cas, un haut degr� de contention pour le bus r�duit l'efficacit� de la largeur de bande disponible pour tous les p�riph�riques sur le bus.
Un bus SCSI dot� de plusieurs disques durs tr�s actifs illustre bien cette situation. Les disques durs tr�s actifs saturent le bus SCSI, ne laissant disponible qu'une largeur de bande tr�s faible pour tout autre p�riph�rique sur le m�me bus. En cons�quence, toutes les activit�s d'E/S vers tout autre p�riph�rique seront lentes, et ce, m�me si aucun p�riph�rique du bus n'est extr�mement actif.
Il est possible que le bus ou le chemin des donn�es repr�sentent une ressource attitr�e � laquelle un nombre fixe de p�riph�riques sont reli�s. Dans ce cas, les caract�ristiques �lectriques du bus (et dans une certaine mesure, la nature du protocole utilis�) limitent la largeur de bande disponible. Cette situation est toutefois plus courante avec les chemins d'acc�s qu'avec les bus. C'est d'ailleurs une des raisons pour lesquelles les adaptateurs graphiques ont tendance � �tre plus lents lorsqu'ils fonctionnent � des degr�s �lev�s de r�solution et/ou d'intensit� de couleur — pour tout rafra�chissement d'�cran, davantage de donn�es doivent �tre transmises le long du chemin des donn�es reliant la m�moire vid�o et le processeur de graphiques.
3.1.4. Solutions potentielles � des probl�mes li�s � la largeur de bande
Heureusement, il existe des solutions aux probl�mes li�s � la largeur de bande. En fait, il est possible d'adopter plusieurs approches�:
Distribution de la charge
R�duction de la charge
Augmentation de la capacit�
Les sections suivantes abordent chacune de ces approches de mani�re plus d�taill�e.
3.1.4.1. R�partition de la charge
La premi�re approche consiste � r�partir l'activit� du bus de mani�re plus �quilibr�e. En d'autres termes, si un bus particulier est surcharg� et qu'un autre est inactif, peut-�tre que la situation pourrait �tre am�lior�e en transf�rant une partie de la charge sur le bus inactif.
En tant qu'administrateur syst�me, cette approche devrait �tre la premi�re � consid�rer, particuli�rement lorsque de nombreux bus suppl�mentaires existent d�j� sur le syst�me. Par exemple, la plupart des ordinateurs comportent au moins deux canaux ATA (juste un autre nom pour un bus). Si vous disposez de deux disques durs ATA et de deux canaux ATA, pourquoi les deux disques durs devraient-ils se trouver sur le m�me canal�?
M�me si votre configuration syst�me n'inclut pas de bus suppl�mentaires, la r�partition de la charge peut toujours repr�senter une approche valable. Les co�ts au niveau mat�riel associ�s � une telle approche seraient moins �lev�s que de remplacer un bus existant par un mat�riel � capacit� sup�rieure.
3.1.4.2. R�duction de la charge
Au premier abord, la r�duction et la r�partition de la charge semblent repr�senter diff�rents aspects du m�me probl�me. Apr�s tout, la r�partition de la charge ne permet-elle pas aussi de la r�duire (du moins sur le bus surcharg�)�?
Alors que ce point de vue est tout � fait correct, r�partir la charge ne revient toutefois pas � r�duire la charge globalement. La cl� ici consite � d�terminer si un certain aspect de la charge du syst�me est � l'origine de la surcharge d'un bus particulier. Par exemple, est-ce qu'un r�seau doit faire face � une lourde charge � cause d'activit�s qui ne sont pas vraiment n�cessaires�? Ou peut-�tre un petit fichier temporaire est-il le destinataire d'activit�s d'E/S intenses. Si ce fichier temporaire figure sur un serveur de fichiers r�seau, une grande partie du trafic r�seau pourrait �tre �limin�e simplement en travaillant localement avec ce fichier.
3.1.4.3. Augmentation de la capacit�
La solution la plus �vidente au probl�me de largeur de bande insuffisante consiste � augmenter cette derni�re d'une mani�re ou d'une autre. Cette approche est n�anmoins souvent assez co�teuse. Imaginez par exemple un contr�leur SCSI avec un bus surcharg�. Afin d'augmenter sa largeur de bande, il faudrait remplacer le contr�leur SCSI (et vraisemblablement tous les p�riph�riques connect�s � ce dernier) par du mat�riel plus puissant. Dans le cas o� le contr�leur SCSI est une carte ind�pendante, le processus est relativement simple�; en revanche, si le contr�leur SCSI fait partie de la carte m�re du syst�me, il est beaucoup plus difficile de justifier le co�t d'une telle op�ration.
3.1.5. En r�sum�…
Tous les administrateurs de syst�me devraient disposer de connaissances sur la largeur de bande et sur l'impact que la configuration et l'utilisation du syst�me ont sur la largeur de bande disponible. Malheureusement, la distinction existant entre un probl�me li� � la largeur de bande et un autre probl�me n'est pas toujours tr�s claire. Quelquefois, le probl�me n'est pas le bus lui-m�me mais plut�t les composants qui sont reli�s au bus.
Par exemple, imaginez un adaptateur SCSI reli� � un bus PCI. S'il existe des probl�mes de performance au niveau des E/S du disque SCSI, peut-�tre qu'un adaptateur SCSI � faible performance en est la cause, m�me si les bus SCSI et PCI eux-m�mes sont bien loin de leur capacit� au niveau de leur largeur de bande.
