Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Introduction a l'administration systeme - Puissance de traitement

3.2. Puissance de traitement

Souvent appel�e puissance CPU, la puissance de traitement des cycles CPU (qui portent parfois d'autres noms) repr�sente la capacit� d'un ordinateur � manipuler des donn�es. La puissance de traitement varie en fonction de l'architecture (et de la vitesse d'horloge) du CPU — g�n�ralement, des CPU � vitesses d'horloge �lev�es et des CPU prenant en charge des longueurs de mots plus importantes ont une puissance de traitement sup�rieure aux CPU plus lents supportant des mots de tailles inf�rieures.

3.2.1. Informations sur la puissance de traitement

Il est important de garder � l'esprit deux points principaux concernant la puissance de traitement, � savoir�:

  • La puissance de traitement est fixe

  • La puissance de traitement ne peut �tre stock�e

La puissance de traitement est fixe dans le sens o� la vitesse du CPU est d�termin�e. Par exemple, si vous devez ajouter deux nombres (une op�ration qui, sur la plupart des ordinateurs, ne n�cessite qu'une seule instruction pour la machine), un CPU sp�cifique peut effectuer la t�che � une vitesse d�termin�e et seulement � cette vitesse sp�cifique. Mises � part quelques rares exceptions, il n'est m�me pas possible de ralentir le taux auquel le CPU traite les instructions, alors pour ce qui est de l'augmenter, il ne faut m�me pas y songer.

La puissance de traitement est �galement fixe � un autre niveau�: elle est limit�e. C'est � dire qu'il existe des limites quant aux CPU pouvant �tre branch�s dans un ordinateur donn�. Certains syst�mes sont � m�me de prendre en charge une vaste gamme de CPU � vitesses vari�es, alors que d'autres ne pourront peut-�tre m�me pas faire l'objet d'une mise � niveau[1].

La puissance de traitement ne peut pas �tre mise en r�serve pour une utilisation ult�rieure. En d'autres termes, si un CPU peut traiter 100 millions d'instructions en une seconde, une seconde d'inactivit� se traduit par une perte de traitement �quivalent � 100 millions d'instructions.

En prenant ces informations et en les examinant sous une optique l�g�rement diff�rente, un CPU peut �tre consid�r� comme "produisant" un flux d'instructions ex�cut�es � un taux fixe. Si le CPU "produit" des instructions ex�cut�es, un autre �l�ment doit indubitablement les "consommer". La section suivante se concentre sur ces consommateurs d'instructions.

3.2.2. Consommateurs de puissance de traitement

Les deux principaux consommateurs de puissance de traitement sont�:

  • Les applications

  • Le syst�me d'exploitation lui-m�me

3.2.2.1. Les applications

Les consommateurs de puissance de traitement les plus �vidents sont les applications et les programmes que vous souhaitez voir ex�cuter par l'ordinateur. Qu'il s'agisse d'un tableur ou d'une base de donn�es, ces outils sont les raisons pour lesquelles vous avez un ordinateur.

Un syst�me � CPU unique ne peut effectuer qu'une seule t�che � un moment donn�. Par cons�quent, si votre application est en cours d'ex�cution, aucun autre �l�ment de votre syst�me ne peut �tre ex�cut�. Et bien �videmment, il en va de m�me pour la relation inverse — si tout �l�ment autre que votre application est en cours d'ex�cution, cette derni�re ne pourra �tre ex�cut�e.

Dans de telles conditions, comment se fait-il que de nombreuses applications diff�rentes puissent en apparence tourner sous un syst�me d'exploitation moderne�? La r�ponse est simple�; ces syst�mes d'exploitation sont des syst�mes multit�che. En d'autres termes, ils cr�ent l'illusion que de nombreux �l�ments sont ex�cut�s simultan�ment alors que c'est en fait impossible. L'astuce consiste � donner � chaque processus une dur�e d'ex�cution sur le CPU d'une fraction de seconde avant d'accorder le m�me traitement � un autre processus qui lui, disposera de la fraction de seconde suivante. � condition que ces changements de contexte se produisent suffisamment rapidement, il est possible de cr�er l'illusion que de multiples applications sont ex�cut�es de mani�re simultan�e.

Bien s�r, les applications effectuent des t�ches autres que la seule manipulation de donn�es par le biais du CPU. Elles peuvent aussi bien attendre des entr�es de l'utilisateur qu'effectuer des activit�s d'E/S vers des p�riph�riques comme les disques durs ou des affichages de graphiques. Lorsque ces �v�nements se produisent, l'application n'a plus besoin du CPU. Dans ces cas-l�, le CPU peut �tre utilis� pour d'autres processus ex�cutant d'autres applications sans pour autant ralentir du tout l'application en attente.

En outre, le CPU peut �tre utilis� par un autre consommateur de puissance de traitement�: le syst�me d'exploitation lui-m�me.

3.2.2.2. Le syst�me d'exploitation

Il est difficile de d�terminer le degr� de puissance de traitement consomm� par le syst�me d'exploitation. En effet, pour effectuer leur travail, les syst�mes d'exploitation utilisent une combinaison de codes au niveau des processus et au niveau du syst�me. Alors qu'il est facile d'utiliser par exemple, un contr�leur de processus pour d�terminer ce que fait le processus ex�cutant un d�mon ou service, il est plus difficile de d�terminer la puissante de traitement consomm�e par le traitement d'activit�s en relation avec les E/S au niveau du syst�me (ce qui est normalement effectu� dans le contexte du processus demandant les E/S).

En g�n�ral, il est possible de diviser ce genre de temps de gestion du syst�me d'exploitation en deux types�:

  • Gestion interne du syst�me d'exploitation

  • Activit�s en relation avec les processus

La gestion interne du syst�me d'exploitation inclut des activit�s telles que la programmation des processus et la gestion de la m�moire alors que les activit�s associ�es aux processus incluent tout processus supportant le syst�me d'exploitation lui-m�me, tels que des processus traitant la journalisation des �v�nements dans tout le syst�me ou effectuant le vidage du cache des E/S (cache flashing).

3.2.3. R�ponse � une insuffisance de CPU

Lorsque la puissance de traitement disponible est insuffisante pour faire face au travail devant �tre effectu�, deux options sont disponibles�:

  • R�duction de la charge

  • Augmentation de la capacit�

3.2.3.1. R�duction de la charge

La r�duction de la charge CPU est une op�ration ne n�cessitant aucun co�t suppl�mentaire. L'astuce consiste � identifier les aspects de la charge du syst�me qui sont sous votre contr�le et qui peuvent �tre r�duits. � cet �gard, trois aspects ont une importance particuli�re�:

  • La r�duction du temps de gestion du syst�me d'exploitation

  • La r�duction du temps de gestion des applications

  • L'�limination totale des applications

3.2.3.1.1. La r�duction du temps de gestion du syst�me d'exploitation

Afin de r�duire le temps de gestion du syst�me d'exploitation, il est n�cessaire d'examiner la charge actuelle de votre syst�me afin d'identifier les aspects pr�cis entra�nant des temps de gestion excessifs. Parmi ces derniers pourraient figurer�:

  • La r�duction du besoin de programmation fr�quente de processus

  • La r�duction de la quantit� d'E/S effectu�es

Ceci dit, il ne faut pas s'attendre � des miracles�; dans un syst�me raisonnablement bien configur�, il y a peu de chances que la seule r�duction du temps de gestion du syst�me d'exploitation entra�ne une am�lioration consid�rable de la performance. En effet, un syst�me raisonnablement bien configur� n'a, par d�finition, qu'un temps de gestion minimal. Toutefois, si votre syst�me tourne par exemple avec une quantit� de RAM insuffisante, vous serez peut-�tre en mesure de r�duire le temps de gestion en r�solvant le probl�me d'une m�moire vive trop petite.

3.2.3.1.2. R�duction du temps de gestion des applications

Pour r�duire le temps de gestion d'une application, il est n�cessaire de s'assurer que cette derni�re dispose bien de tout ce dont elle a besoin pour fonctionner correctement. Certaines applications ont des comportements extr�mement diff�rents selon les environnements — une application peut par exemple voir ses capacit�s fortement limit�es par le traitement de certains types de donn�es, mais pas par le traitement d'autres.

� ce stade, il est important de garder � l'esprit qu'une bonne compr�hension des applications ex�cut�es sur votre syst�me est n�cessaire pour pouvoir leur permettre de tourner aussi efficacement que possible. Pour ce faire, vous devrez souvent travailler avec vos utilisateurs et/ou les d�veloppeurs de votre entreprise afin de pouvoir d�couvrir des moyens permettant aux applications de tourner plus efficacement.

3.2.3.1.3. �limination compl�te des applications

Selon l'environnement de votre entreprise, il est possible que cette approche ne puisse pas �tre utilis�e, car il n'est souvent pas du ressort de l'administrateur syst�me d'imposer une liste des applications qui peuvent ou ne peuvent pas tourner. Toutefois, si vous pouvez identifier des applications qui sont connues pour leur "monopole de CPU", vous serez peut-�tre en mesure d'influencer les personnes responsables de ce genre de d�cision, afin que les applications en question soient supprim�es.

� cet �gard, vous ne serez vraisemblablement pas la seule personne impliqu�e. Les utilisateurs concern�s devraient certainement faire partie de ce processus�; dans bien des cas, ils disposeront probablement des connaissances et du pouvoir politique n�cessaires pour apporter les changements n�cessaires � la liste des applications.

TuyauAstuce
 

Gardez bien � l'esprit qu'il ne sera peut-�tre pas n�cessaire de retirer une application donn�e de tout les syst�mes de votre entreprise. Vous pourrez peut-�tre d�placer une application particuli�rement gourmande en CPU d'un syst�me surcharg� vers un autre syst�me quasiment inoccup�.

3.2.3.2. Augmentation de la capacit�

Bien s�r, s'il n'est pas possible de r�duire la demande de puissance de traitement, vous devez trouver des moyens d'augmenter la puissance de traitement disponible. Cette option est certes tout � fait possible, mais elle entra�nera des d�penses.

3.2.3.2.1. Mise � niveau du CPU

L'approche la plus simple consiste � d�terminer s'il est possible de mettre � niveau le CPU de votre syst�me. Pour ce faire, la premi�re �tape consiste � voir si le CPU actuel peut �tre retir�. Certains syst�mes (essentiellement les ordinateurs portables) dot�s de CPU soud�s ne permettent pas une mise � niveau. Sur les autres en revanche, les CPU sont branch�s et rendent donc les mises � niveau possibles — tout du moins en th�orie.

Il convient ensuite de faire un peu de recherche afin de d�terminer si un CPU plus rapide existe pour la configuration de votre syst�me. Par exemple, si vous disposez actuellement d'un CPU de 1GHz et qu'il existe une unit� de 2GHz du m�me type, une mise � jour sera peut-�tre possible.

Finalement, il est essentiel de d�terminer la vitesse d'horloge maximale prise en charge par votre syst�me. Toujours sur la base de l'exemple pr�c�dent, m�me s'il existe un CPU de 2GHz d'un type appropri�, un simple �change de CPU n'est pas vraiment une option si votre syst�me ne prend en charge que des processeurs tournant � une vitesse �gale ou inf�rieure � 1GHz.

Dans le cas o� vous ne pourriez pas installer un CPU plus rapide dans votre syst�me, l'�tendue de vos options se limitera peut-�tre au remplacement des cartes m�res ou � la mise � niveau massive dont nous avons parl� pr�c�demment.

Toutefois, certaines configurations syst�me permettent une approche l�g�rement diff�rente. Au lieu de remplacer le CPU actuel, pourquoi ne pas tout simplement en ajouter un autre�?

3.2.3.2.2. Le traitement multit�che sym�trique est-il adapt� � votre situation�?

Le traitement multit�che sym�trique (aussi appel� multitraitement sym�trique ou SMP de l'anglais Symmetric multiprocessing) permet � un ordinateur d'avoir plus d'un CPU partageant toutes les ressources syst�me. Ainsi, contrairement � un syst�me dot� d'un seul processeur, un syst�me SMP peut, lui, faire tourner plus d'un processus � la fois.

Au premier abord, cette situation semble repr�senter le r�ve d'un administrateur de syst�me. SMP permet avant tout d'augmenter la puissance de CPU d'un syst�me, m�me s'il existe des CPU avec une vitesse d'horloge plus rapide — simplement en ajoutant un autre CPU. Cette souplesse s'accompagne n�anmoins d'un certain nombre de contraintes.

La premi�re d'entre elles est que tous les syst�mes ne sont pas en mesure de fonctionner en traitement multit�che sym�trique (SMP). La carte m�re de votre syst�me doit �tre con�ue pour prendre en charge de multiples processeurs. Si ce n'est pas le cas, la mise � niveau de la carte m�re (au strict minimum) sera n�cessaire.

Le deuxi�me d'entre elles est que SMP augmente le temps de gestion du syst�me. En y r�fl�chissant bien, l'augmentation du nombre de CPU pour lesquels la programmation de t�ches doit �tre effectu�e se traduit logiquement, pour le syst�me d'exploitation, en un plus grand nombre de cycles CPU au niveau de la gestion. En outre, un plus grand nombre de CPU peut entra�ner une contention accrue pour les ressources syst�me. En raison de ces facteurs, la mise � niveau d'un syst�me � double processeur vers une unit� � quadruple processeur n'entra�ne pas une augmentation � 100% de la puissance CPU disponible. En fait, en fonction du mat�riel m�me, de la charge de travail et de l'architecture du processeur, il est possible d'arriver � un stade o� l'ajout d'un autre processeur pourrait en fait r�duire la performance du syst�me.

Il est aussi important de se souvenir que SMP ne permet pas d'influencer des charges de travail compos�es d'une application monolithique avec un seul flux d'ex�cution. En d'autres termes, si un grand programme de simulation n�cessitant une activit� de calcul intense tourne en tant qu'un processus et n'a pas de fils (ou thread), il ne sera pas ex�cut� plus rapidement sur un syst�me SMP que sur un ordinateur � processeur unique. En fait, il tournera m�me peut-�tre un peu plus lentement � cause de la gestion suppl�mentaire engendr�e par SMP. Ainsi, de nombreux administrateurs de syst�me estiment qu'en mati�re de CPU, une puissance de traitement � flux unique est l'option � retenir. Elle offre une puissance CPU optimale avec des restrictions minimales au niveau de son utilisation.

M�me si ces informations semblent indiquer que SMP n'est jamais une bonne option, il existe certaines situations dans lesquelles un tel choix est tout � fait appropri�. Des environnements faisant tourner de multiples applications � calculs intensifs repr�sentent, par exemple, un environnement tout � fait appropri� pour SMP. En effet, des applications dont la t�che n'est autre que d'effectuer des calculs pendant de longues p�riodes de temps maintiennent la contention entre les processus actifs (et par cons�quent, le temps de gestion du syst�me d'exploitation) � un minimum, alors que les processus eux-m�mes utilisent chaque CPU.

Il est important de se rappeler �galement que la performance d'un syst�me SMP � tendance � se d�grader plus progressivement au fur et � mesure que la charge du syst�me augmente. C'est pr�cis�ment une des raisons pour lesquelles les syst�mes SMP sont populaires dans des environnements de serveurs ou dans des environnements � utilisateurs multiples, car l'impact qu'un m�lange de processus changeant constamment a sur la charge du syst�me entier est moindre sur un ordinateur � processeurs multiples.

Notes

[1]

Cette situation m�ne � ce que l'on appelle de mani�re humoristique une mise � niveau massive, qui correspond en fait au remplacement complet d'un ordinateur

 
 
  Published under the terms of the GNU General Public License Design by Interspire