Guide d'administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris

Chapitre 8 Ordonnanceur FSS (présentation)

L'analyse des données de la charge de travail permet parfois d'identifier la charge de travail ou le groupe de charges de travail qui monopolise les ressources de la CPU. S'il n'existe aucune violation de contrainte en terme d'utilisation de la CPU, vous pouvez changer la stratégie d'allocation du temps CPU sur le système. La classe de programmation FSS (Fair Share Scheduler ) décrite dans ce chapitre permet d'allouer du temps CPU en tenant compte des parts et non du plan de priorité de la classe de programmation TS (TimeSharing).

Ce chapitre se compose des sections suivantes :

Pour apprendre à utiliser l'ordonnanceur FSS, reportez-vous au Chapitre 9Administration de l'ordonnanceur FSS (tâches).

Introduction à l'ordonnanceur FSS

L'une des tâches fondamentales du système d'exploitation consiste à décider à quels processus attribuer l'accès aux ressources système. Le programme chargé de la programmation des processus, appelé ordonnanceur ou dispatcheur, est la portion du noyau qui gère l'allocation des ressources de la CPU aux processus. L'ordonnanceur fonctionne sur le principe de classes de programmation. Chaque classe définit une stratégie de programmation qui sert à planifier les processus au sein de la classe. L'ordonnanceur par défaut dans le système d'exploitation Solaris, l'ordonnanceur TS, essaie d'accorder à chaque processus un temps d'accès équivalent aux CPU disponibles. Il peut être souhaitable, cependant, d'allouer plus de ressources à certains processus qu'à d'autres.

Vous pouvez vous servir de l'ordonnanceur FSS pour contrôler la répartition des ressources disponibles des CPU entre les différentes charges de travail, en fonction de leur importance. Celle-ci se traduit par le nombre de parts de ressources CPU que vous assignez à chaque charge.

Assignez des parts de CPU à chacun des projets pour contrôler leur droit aux ressources CPU. L'ordonnanceur FSS garantit une répartition équitable des ressources CPU entre les projets en fonction des parts assignées, indépendamment du nombre de processus rattachés à un projet. Pour ce faire, il réduit les droits du projet en terme d'utilisation intensive de la CPU et augmente ses droits pour une utilisation légère, en conformité avec les autres projets.

L'ordonnanceur FSS se compose d'un module de classe de programmation de noyau et de versions spécifiques à la classe des commandes dispadmin(1M) et priocntl(1). Les parts de projet utilisées par l'ordonnanceur FSS sont définies par le biais de la propriété project.cpu-shares dans la base de données project(4).


Remarque –

Si vous vous servez du contrôle de ressource project.cpu-shares sur un système doté de zones, reportez-vous aux sections Données de configuration de zones, Utilisation de contrôles de ressources dans les zones non globales et Utilisation de l'ordonnanceur FSS sur un système Solaris doté de zones.


Définition d'une part de CPU

Le terme « part » désigne la partie des ressources de CPU système allouée à un projet. Si vous assignez un nombre de parts de CPU élevé à un projet, par rapport aux autres projets, l'ordonnanceur FSS alloue plus de ressources de CPU à ce projet.

Les parts de CPU ne doivent pas être considérées comme un pourcentage des ressources de CPU. Elles servent à définir l'importance relative d'une charge par rapport à une autre charge. Lorsque vous attribuez des parts de CPU à un projet, ce n'est pas tant le nombre qui est important, mais sa quantité respective par rapport aux autres projets. Il faut également prendre en compte le nombre de projets qui se « disputeront » les ressources de la CPU.


Remarque –

Les processus de projets qui ne disposent d'aucune part ont la priorité système la plus basse (0). Ces processus sont uniquement exécutés lorsque les projets dotés de parts supérieures à zéro n'utilisent pas les ressources de CPU.


Parts de la CPU et état des processus

Dans le système Solaris, la charge de travail d'un projet implique, en principe, plusieurs processus. Du point de vue de l'ordonnanceur FSS, une charge de travail de projet est soit à l'état inactif, soit à l'état actif. Un projet est considéré comme inactif lorsque aucun de ses processus n'utilise les ressources de la CPU. Cela signifie généralement que ces processus sont en sommeil (en attente d'exécution d'E/S) ou arrêtés. Un projet est considéré comme actif si au moins un de ses processus exploite les ressources de la CPU. La somme des parts de tous les projets actifs permet de calculer la portion des ressources de la CPU à attribuer aux projets.

Au fur et à mesure que des projets deviennent actifs, l'allocation de la CPU est réduite en conséquence pour chaque projet, mais la répartition entre les différents projets reste la même en proportion.

Différence entre allocation des parts de CPU et utilisation de la CPU

Il ne faut confondre allocation et utilisation des parts de CPU. L'utilisation moyenne de la CPU par un projet peut très bien avoisiner les 20 % même si 50 % des ressources de la CPU lui ont été alloués. En outre, les parts ont pour intérêt de limiter l'utilisation de la CPU uniquement en cas de compétition avec d'autres projets. Quelle que soit la part des ressources qui lui a été attribuée, un projet reçoit systématiquement 100 % de la puissance de traitement s'il est le seul projet en cours d'exécution sur le système. Les cycles de CPU disponibles ne sont jamais gaspillés. Ils sont répartis entre les projets.

L'allocation d'une petite part à une charge de travail intensive risque de réduire ses performances. Cela ne l'empêche pas, en revanche, de terminer ses opérations si le système n'est pas surchargé.

Exemples de parts de CPU

Supposons que vous disposiez d'un système avec deux CPU exécutant deux charges de travail en parallèle appelées respectivement A et B. Chaque charge de travail est exécutée dans un projet indépendant. Les projets ont été configurés de manière à allouer SA parts au projet A et S B parts au projet B.

En moyenne, avec l'ordonnanceur TS habituel, chacune des charges de travail s'exécutant sur le système aurait droit à la même quantité de ressources de la CPU, c'est-à-dire 50 % de la capacité du système.

Lorsque vous les exécutez sous le contrôle de l'ordonnanceur FSS sur la même base (SA=SB ), ces projets obtiennent approximativement les mêmes quantités de ressources de la CPU. En revanche, si le nombre de parts accordé à ces projets est différent, les allocations des ressources de la CPU ne seront pas identiques.

Les trois exemples qui suivent illustrent le principe de fonctionnement des parts dans différentes configurations. Ces exemples démontrent que le raisonnement mathématique des parts n'a de sens que si la demande atteint ou dépasse les ressources disponibles.

Exemple 1 : deux processus tirant parti de la CPU dans chaque projet

Si A et B disposent tous deux de deux processus ayant besoin de la puissance de traitement de la CPU et que S A = 1 et S B = 3, le nombre total de parts est alors 1 + 3 = 4. Dans cette configuration, à condition que la demande de la CPU soit suffisante, 25 et 75 % des ressources de la CPU sont attribués respectivement aux projets A et B.

Illustration. Le contexte décrit le graphique.

Exemple 2 : aucune compétition entre les projets

Si A et B ne disposent chacun que d'un processus ayant besoin de la puissance de traitement de la CPU et que S A = 1 et S B = 100, le nombre total de part est alors 101. Chaque projet ne peut utiliser plus d'une CPU car chacun n'a qu'un processus en cours d'exécution. Comme il n'existe aucun conflit de partage des ressources de la CPU dans cette configuration, les projets A et B se voient attribuer chacun 50 % de toutes les ressources de la CPU. Les parts de CPU n'ont donc aucune importance dans ce cas. Les allocations des projets seraient identiques (50/50), même si vous leur aviez attribué zéro part .

Illustration. Le contexte décrit le graphique.

Exemple 3 : un projet dans l'incapacité de s'exécuter

Si A et B disposent chacun de deux processus ayant besoin de la puissance de traitement de la CPU et si 1 part est attribuée au projet A et 0 part au projet B, toutes les ressources sont allouées au projet A et aucune ressource au projet B. Les processus du projet B seront systématiquement définis au niveau de priorité 0, ce qui signifie qu'il sera impossible de les exécuter dans la mesure où le projet A possède en permanence le niveau de priorité supérieur.

Illustration. Le contexte décrit le graphique.

Configuration de l'ordonnanceur FSS

Projets et utilisateurs

Les projets sont les conteneurs de charges de travail dans l'ordonnanceur FSS. Les groupes d'utilisateurs affectés à un projet sont traités comme de simples blocs contrôlables. Sachez qu'il est possible de créer un projet avec son propre nombre de parts pour chaque utilisateur.

Les utilisateurs peuvent faire partie de plusieurs projets possédant un nombre différent de parts. En déplaçant les processus d'un projet à un autre, il est possible de faire varier les quantités de ressources CPU qui leur sont allouées.

Pour plus d'informations sur la base de données project(4) et les services de noms, reportez-vous à la section Base de données project.

Configuration des parts de CPU

La configuration des parts de CPU est gérée par le service de noms en tant que propriété de la base de données project.

Lors de la création de la première tâche (ou du premier processus) associée à un projet au moyen de la fonction de bibliothèque setproject(3PROJECT), le nombre de parts de CPU définies comme contrôle de ressource project.cpu-shares dans la base de données project est communiqué au noyau. Les projets pour lesquels aucun contrôle de ressource project.cpu-shares n'a été défini se voient attribuer une part.

Dans l'exemple qui suit, cette entrée du fichier /etc/project fixe le nombre de parts pour le projet fichiers-x à 5 :


x-files:100::::project.cpu-shares=(privileged,5,none)

Si vous changez le nombre de parts de CPU alloué à un projet dans la base de données alors que des processus sont déjà en cours d'exécution, ce nombre n'est pas modifié à ce stade. Il est nécessaire, en effet, de redémarrer le projet pour que le changement prenne effet.

Si vous souhaitez modifier temporairement le nombre de parts attribué à un projet sans changer les attributs du projet dans la base de données project, utilisez la commande prctl. Par exemple, pour remplacer la valeur du contrôle des ressources project.cpu-shares du projet fichiers-x par 3 lorsque les processus associés à ce projet sont exécutés, tapez ce qui suit :


# prctl -r -n project.cpu-shares -v 3 -i project x-files

Pour plus d'informations, voir la page de manuel prctl(1).

-r

Remplace la valeur actuelle pour le contrôle de ressource nommé.

-n nom

Définit le nom du contrôle de ressource.

-v val

Spécifie la valeur du contrôle de ressource.

-i typeid

Précise le type d'ID de l'argument suivant.

fichiers-x

Indique l'objet concerné par le changement. Dans cet exemple, il s'agit du projet fichiers-x.

Le projet system avec pour ID de projet 0 comprend l'ensemble des démons système démarrés par les scripts d'initialisation lancés au démarrage. system peut être considéré comme un projet avec un nombre illimité de parts. Cela signifie que system est toujours programmé en premier, quel que soit le nombre de parts alloué aux autres projets. Si vous ne souhaitez pas accorder au projet system un nombre illimité de parts, il suffit de définir le nombre de parts de ce projet dans la base de données project.

Comme indiqué précédemment, les processus appartenant aux projets disposant d'aucune part possèdent la priorité système la plus basse (zéro). Les projets dotés d'une ou plusieurs parts s'exécutent aux niveaux de priorité un ou plus. Par conséquent, les projets dépourvus de part sont programmés à condition qu'aucun projet avec des parts ne demande de ressources de CPU.

Le nombre maximum de parts susceptible d'être alloué à un projet est de 65535.

Ordonnanceur FSS et jeux de processeurs

Il est possible d'utiliser l'ordonnanceur FSS conjointement aux jeux de processeurs. Cela permet de gérer les répartitions des ressources de la CPU entre les projets s'exécutant sur chaque jeu de processeurs de façon plus précise que si vous procédiez processeur par processeur. L'ordonnanceur FSS considère les jeux de processeurs comme des partitions parfaitement distinctes, chacun d'eux étant géré indépendamment des ressources de la CPU allouées.

Les allocations de la CPU prévues pour les projets s'exécutant sur un jeu de processeurs ne sont pas affectées par les parts de CPU ou l'activité des projets s'exécutant sur un autre jeu de processeurs, car les projets ne se disputent pas les mêmes ressources. Les projets sont en concurrence uniquement lorsqu'ils fonctionnent sur le même jeu de processeurs.

Le nombre de parts allouées à un projet s'applique à l'ensemble du système. Quel que soit le jeu de processeurs de destination, chaque partie d'un projet possède le même nombre de parts.

En cas d'utilisation de jeux de processeurs, les allocations des ressources de la CPU sont calculées pour les projets actifs au sein de chaque jeu.

Les partitions des projets s'exécutant sur divers jeux de processeurs risquent d'avoir des allocations différentes. L'allocation des ressources de la CPU pour chaque partition de projet dans un jeu de processeurs dépend uniquement des allocations définies pour les autres projets appartenant au même jeu.

Les performances et la disponibilité des applications s'exécutant dans les limites de leurs jeux de processeurs ne sont pas concernées par l'ajout de nouveaux jeux de processeurs. Les changements apportés aux parts de CPU des projets s'exécutant sur d'autres jeux de processeurs n'ont aucune incidence sur les applications.

Les jeux de processeurs vides (jeux sans processeur) ou les jeux de processeurs auxquels aucun processus n'est rattaché n'ont pas d'impact sur le comportement de l'ordonnanceur FSS.

Exemples d'utilisation des jeux de processeurs avec l'ordonnanceur FSS

Supposons qu'un serveur à huit CPU exécute plusieurs applications utilisant la CPU dans le cadre des projets A, B et C. Une, deux et trois parts sont allouées respectivement aux projets A, B et C.

Le projet A n'est exécuté que sur le jeu de processeurs 1. Le projet B est exécuté sur les jeux de processeurs 1 et 2. Le projet C est exécuté sur les jeux de processeurs 1, 2 et 3. Présumons que chaque projet dispose de suffisamment de processus pour tirer parti de l'ensemble de la puissance disponible de la CPU. Dans un tel cas de figure, les projets sont en concurrence permanente pour utiliser les ressources de la CPU sur chaque jeu de processeurs.

Le schéma montre les allocations totales des ressources de la CPU à l'échelle du système sur un serveur à huit CPU exécutant plusieurs applications dans trois projets différents.

La valeur totale est récapitulée dans le tableau suivant.

Projet 

Allocation 

Projet A 

4% = (1/6 X 2/8)jeuproc1

Projet B 

28 % = (2/6 X 2/8)pset1+ (2/5 * 4/8)pset2

Projet C 

67 % = (3/6 X 2/8)pset1+ (3/5 X 4/8)pset2+ (3/3 X 2/8)pset3

Ces pourcentages ne correspondent pas aux nombres de parts de CPU attribuées aux projets. Cependant, à l'intérieur de chaque jeu de processeurs, les rapports d'allocation de CPU par projet sont proportionnels à leurs parts respectives.

Sur le même système sans jeu de processeurs, la répartition des ressources de la CPU serait différente, comme le montre le tableau suivant.

Projet 

Allocation 

Projet A 

16.66% = (1/6) 

Projet B 

33,33% = (2/6) 

Projet C 

50% = (3/6) 

Utilisation de l'ordonnanceur FSS avec d'autres classes de programmation

Par défaut, la classe de programmation FSS utilise la même plage de priorités (0 à 59) que les classes de programmation TS (partage de temps), IA (interactive) et FX (priorité fixe). Il vaut donc mieux éviter que des processus de ces classes de programmation partagent le même jeu de processeurs. Le fait de combiner des processus des classes FSS, TS, IA et FX risquerait de provoquer un comportement inattendu.

En revanche, si vous utilisez des jeux de processeurs, il est possible de combiner des classes TS, IA et FX avec l'ordonnanceur FSS sur un même système. Tous les processus s'exécutant sur chaque jeu de processeurs doivent, cependant, faire partie d'une seule classe de programmation, pour éviter qu'ils entrent en compétition pour les mêmes CPU. Il faut veiller notamment à ne pas utiliser l'ordonnanceur FX en parallèle avec la classe de programmation FSS, sauf si vous tirez parti des jeux de processeurs. Cela empêche les applications de la classe FX d'utiliser les priorités les plus élevées au détriment des applications de la classe FSS.

Vous pouvez combiner des processus des classes TS et IA au sein du même jeu de processeurs ou sur le même système sans jeu de processeurs.

Le système Solaris propose également un ordonnanceur en temps réel (RT) aux utilisateurs dotés des privilèges de superutilisateur. Par défaut, la classe de programmation RT utilise les priorités système d'une plage différente (entre 100 et 159, en général) de celle de la classe FSS. Comme les classes RT et FSS utilisent des plages de priorités distinctes (sans risque de se chevaucher), il est possible de les faire cohabiter au sein du même jeu de processeurs. La classe de programmation FSS n'offre, cependant, aucun contrôle sur les processus s'exécutant dans la classe RT.

Sur un système quadriprocesseur, par exemple, un processus RT à simple thread peut accaparer un processeur entier si le processus est lié à la CPU. Si le système exécute également la classe FSS, des processus utilisateur normaux se disputent les trois CPU restantes. Il faut noter que le processus RT n'utilise pas nécessairement l'UC en continu. Lorsqu'il est inactif, la classe FSS tire parti des quatre processeurs.

Vous pouvez saisir la commande suivante pour identifier les classes de programmation sur lesquelles s'exécutent les jeux de processeurs et vous assurer que chaque jeu de processeurs est configuré pour fonctionner en mode TS, IA, FX ou FSS.


$ ps -ef -o pset,class | grep -v CLS | sort | uniq
1 FSS
1 SYS
2 TS
2 RT
3 FX

Définition de la classe de programmation pour le système

Pour définir la classe de programmation pour le système, reportez-vous aux sections Sélection de l'ordonnanceur FSS comme classe de programmation par défaut, Classe de programmation dans une zone et à la page de manuel dispadmin(1M). Pour déplacer des processus en cours dans une autre classe de programmation, reportez-vous à la section Contrôle de l'ordonnanceur FSS et à la page de manuel priocntl(1).

Classe de programmation dans un système doté de zones

Les zones non globales utilisent la classe de programmation par défaut pour le système. En cas de mise à jour du système avec un nouveau paramètre de classe de programmation par défaut, le paramètre est appliqué aux zones non globales au moment où vous les initialisez ou les redémarrez.

Dans ce cas, il est préférable de définir FSS comme classe de programmation par défaut du système à l'aide de la commande dispadmin. Toutes les zones disposent ainsi d'une part équitable des ressources CPU du système. Pour plus d'informations sur l'utilisation de la classe de programmation avec des zones, reportez-vous à la section Classe de programmation dans une zone.

Pour savoir comment transférer des processus en cours d'exécution vers une autre classe de programmation sans changer la classe de programmation par défaut et sans redémarrer, reportez-vous au Tableau 27–5 et à la page de manuel priocntl(1).

Commandes utilisées avec l'ordonnanceur FSS

Les commandes présentées dans le tableau suivant assurent l'interface d'administration principale avec l'ordonnanceur FSS.

Aide-mémoire des commandes 

Description 

priocntl(1)

Affiche ou définit les paramètres de programmation des processus indiqués, transfère les processus en cours d'exécution vers une autre classe de programmation. 

ps(1)

Récapitule les informations au sujet des processus en cours d'exécution, identifie les classes de programmation dans lesquelles les jeux de processeurs s'exécutent. 

dispadmin(1M)

Configure l'ordonnanceur par défaut pour le système. Permet également d'examiner et de régler la valeur de quantum de l'ordonnanceur FSS. 

FSS(7).

Affiche une description de l'ordonnanceur FSS.