Chapitre 6 Ordonnanceur SHR

L'ordonnanceur SHR de Solaris Resource Manager est utilisé pour contrôler l'attribution des ressources de l'unité centrale. Le concept de parts permet aux administrateurs de contrôler facilement des droits relatifs aux ressources de l'UC pour les utilisateurs, les groupes et les applications. Ce concept est similaire à celui des actions d'une entreprise ; ce qui importe n'est pas la quantité détenue, mais bien la proportion d'actions par rapport aux autres actionnaires.

Description technique

Il existe quatre attributs par noeud limite associé à l'ordonnanceur d'UC de Solaris Resource Manager : cpu.shares, cpu.myshares , cpu.usage et cpu.accrue. La sortie de liminfo( 1SRM) affiche ces attributs ainsi que d'autres valeurs utiles.

Sous Solaris Resource Manager, l'ordonnancement est mis en oeuvre au moyen de la classe d'ordonnancement SHR, qui comprend la prise en charge des commandes nice(1), priocntl (1), renice(1) et dispadmin(1M). Au niveau de l'appel système, SHR est compatible avec la classe d'ordonnancement TS.

Parts

L'attribut cpu.shares d'un utilisateur permet de répartir les droits à l'UC en fonction du père et des homologues actifs de l'utilisateur. L'attribut cpu.myshares est significatif uniquement si l'utilisateur a des utilisateurs enfants actifs ; il permet de déterminer la proportion de droits à l'UC en fonction de ces derniers.

Par exemple, si les utilisateurs A et B sont les seuls enfants du père P et que A, B et P ont chacun une part au sein du groupe P (cpu.shares est fixé à 1 pour A et B, et cpu.myshares est fixé à 1 pour P), chacun à droit à un tiers du total des ressources de l'UC accordées au groupe.

Les droits à l'UC d'un utilisateur sont donc tributaires des droits relatifs du père, ce qui dépend des valeurs relatives de cpu.shares du père sur ses homologues et de cpu.myshares du grand-père, et ainsi de suite en remontant l'arbre.

Aux fins de la gestion du système, les processus liés au noeud limite root ne sont pas concernés par les attributs des parts. Tout processus lié au noeud limite root obtient toujours la plupart des ressources de l'UC qu'il demande.

Il est important que les processus qui consomment beaucoup de ressources d'UC ne soient pas liés au noeud limite root, à défaut de quoi l'exécution d'autres processus serait grandement ralentie. Pour l'éviter, les précautions ci-après doivent être observées :

• Le compte de l'administrateur central doit posséder son propre UID, qui doit différer de celui du superutilisateur. Ce compte doit être utilisé pour ouvrir une session en vue d'effectuer des tâches non administratives. Si l'UID d'un superutilisateur est requis pour exécuter des fonctions administratives, l'administrateur central peut se servir de la commande su(1) afin de changer d'UID tout en demeurant relié à son propre noeud limite.

• La commande srmuser( 1SRM) peut être utilisée dans les scripts init.d(4) pour attacher tout processus démon à un noeud limite non root. Tout processus lancé depuis le script de démarrage détient par défaut un UID root et est relié au noeud limite root. La commande "user" permet aux démons de conserver un UID root tout en demeurant reliés à leur propre noeud limite, ce qui évite les problèmes si un démon accroît sa consommation de ressources de l'UC.

Les chefs de groupe de l'arbre d'ordonnancement n'ont pas tous à représenter les utilisateurs qui exécutent actuellement des processus, et il n'est pas nécessaire de leur allouer une part des ressources de l'UC. Ces noeuds limites peuvent être indiqués en fixant leur attribut cpu.myshares à zéro. L'attribut cpu.accrue dans un tel chef de groupe comprend néanmoins la charge totale pour tous les membres de son groupe.

Part attribuée

Les attributs cpu.shares et cpu.myshares déterminent la part d'UC attribuée à chaque noeud limite actif en pourcentage. Les parts des utilisateurs inactifs n'ont aucune incidence sur la part attribuée. Si un seul utilisateur est actif, il disposera de 100% des ressources de l'UC. Si seulement deux utilisateurs sont actifs et disposent de parts égales dans le même groupe, chacun recevra une part de 50%. Pour en savoir davantage sur le calcul de la part attribuée, consultez la rubrique Calcul de la part attribuée.

Utilisation et décroissance

La valeur de l'attribut cpu.usage augmente chaque fois qu'un processus relié au noeud limite est chargé pour un temps d'UC. Cette valeur décroît exponentiellement à un taux déterminé par le paramètre global de décroissance d'utilisation de Solaris Resource Manager. Le taux de décroissance (exprimé par une demi-vie en secondes) est défini par la commande srmadm(1MSRM).

Bien que tous les processus soient dotés d'un noeud limite sans égard à leur classe d'ordonnancement actuelle, ceux qui se trouvent à l'extérieur de la classe d'ordonnancement SHR ne sont jamais chargés.

Utilisation cumulative

La valeur de l'attribut d'utilisation cumulative augmente dans les mêmes proportions que celle de l'attribut d'utilisation, mais elle ne décroît pas. Elle représente donc l'utilisation cumulative totale pour tous les processus ayant été reliés au noeud limite et à ses membres depuis la dernière réinitialisation de l'attribut.

Part effective

La part effective courante d'un noeud limite est déterminée par sa part attribuée et par l'attribut cpu.usage. L'ordonnanceur de Solaris Resource Manager ajuste les priorités de tous les processus reliés à un noeud limite de façon à rendre leur taux de traitement proportionnel à la part effective du noeud et inversement proportionnel au nombre de processus exécutables qui y sont reliés.

Priorité de partage par processus (sharepri)

Chaque processus relié à un noeud limite intègre des données propres à Solaris Resource Manager et dont la maintenance est assurée par le noyau du système d'exploitation. Aux fins de l'ordonnancement, la plus importante de ces valeurs est sharepri. Les processus dont la valeur sharepri est la plus basse ont en tout temps priorité pour leur exécution par l'UC.

Exemple d'attribution de parts

Structure de l'arbre d'ordonnancement

Les paragraphes ci-après traitent de la structure de l'arbre d'ordonnancement, sujet auquel l'administrateur central doit porter une attention particulière :

• L'arbre d'ordonnancement est la structure utilisée par Solaris Resource Manager pour mettre en oeuvre une hiérarchie de contrôle des ressources et des privilèges. Si un sous-administrateur obtient le contrôle d'un sous-arbre de l'arbre d'ordonnancement auquel il n'a normalement pas accès, il peut accéder à des ressources et privilèges additionnels sans l'approbation de l'administrateur central. Cela peut se produire lorsque l'administrateur supprime un noeud limite en laissant un sous-arbre orphelin.

• L'administrateur central peut exécuter la commande limreport(1SRM) pour repérer les sections orphelines de l'arbre par l'intermédiaire de l'identificateur d'orphelin intégré. Tout orphelin détecté doit être relié immédiatement.

• Lorsqu'un noeud limite est créé, il est constitué en grande partie de zéros, forçant ainsi la plupart des indicateurs à adopter la valeur par défaut inherit (héritage). Il s'agit du résultat souhaité pour la plupart des indicateurs, puisqu'ils sont utilisés pour indiquer les privilèges de périphérique. Deux indicateurs sont mis à zéro de façon explicite lors de la création d'un noeud limite : uselimadm et admin. Cette mesure vise à empêcher que les nouveaux utilisateurs obtiennent automatiquement des privilèges administratifs.

Description de l'arbre

L'arbre ci-dessous illustre une structure comportant plusieurs chefs de groupe et utilisateurs. La racine de l'arbre est l'utilisateur root. Un noeud limite de chef de groupe est indiqué par deux nombres entiers qui représentent les valeurs de ses attributs copu.shares et cpu.myshares respectivement. Un noeud limite feuille est indiqué par un seul nombre entier, la valeur de son attribut shares.

Figure 6-1 Structure de l'arbre d'ordonnancement

Calcul de la part attribuée

Dans la figure précédente, des processus sont reliés aux noeuds limites A, C et N. Au niveau supérieur, il suffirait de partager l'unité centrale entre A et M du fait qu'il n'y a aucun processus pour W ou un membre de ce groupe. Le rapport des parts entre A et M étant de 3:1, la part attribuée au niveau supérieur serait de 75% au groupe A et 25% au groupe M.

La part de 75% accordée au groupe A serait partagée entre les utilisateurs actifs (A et C) en fonction du rapport de leurs parts au sein du groupe A (1:2). Notez que l'attribut myshares est utilisé pour déterminer les parts de A par rapport à ses enfants. Par conséquent, l'utilisateur A obtiendrait un tiers de la part attribuée au groupe, et C les deux tiers. Le total attribué au groupe M serait accordé au noeud N, car il est le seul à comporter des processus.

La distribution globale des parts d'UC disponibles serait donc de 0,25 pour A, 0,5 pour C et 0,25 pour N.

Maintenant, supposons que les processus de A, C et N ont toujours besoin de l'UC et que le système dispose d'un maximum de deux processeurs. Dans un tel cas, Solaris Resource Manager ferait en sorte que chaque processus reçoive les pourcentages ci-après du total des ressources de l'UC :

• pour les deux processus de A : 12,5% chacun

• pour le processus de C : 50%

• pour les trois processus de N : 8,3% chacun

Le taux de progression de chaque processus est contrôlé de façon que la cible soit atteinte pour chaque noeud limite. Sur un système doté de plus de deux unités centrales mais de seulement ces six processus exécutables, le processus de C ne parviendra pas à consommer sa part de 50%, et le reste sera réparti proportionnellement entre A et N.

Relation entre Solaris Resource Manager et la fonction nice de Solaris

La fonction nice de Solaris permet à un utilisateur de réduire la priorité d'un processus pour que les processus habituels ne soient pas ralentis par ceux qui ne sont pas urgents. Pour les utilisateurs de Solaris Resource Manager, cette fonction présente l'avantage de réduire la charge de travail pour le temps de traitement utilisé en basse priorité.

Solaris Resource Manager met en oeuvre cette fonctionnalité en permettant à l'administrateur central de modifier le taux de décroissance sharepri pour les processus visés par nice. Le paramètre global pridecay de la commande srmadm(1MSRM) de Solaris Resource Manager est utilisé pour définir les taux de décroissance applicables aux priorités des processus ayant des valeurs nice normales et maximales. Les taux de toutes les valeurs nice intermédiaires sont interpolés puis extrapolés à la valeur nice minimale. Par exemple, la priorité (comme sharepri) des processus normaux peut décroître avec une demi-vie de deux secondes, tandis que celle des processus ayant une valeur nice maximale peut décroître avec une demi-vie de 60 secondes.

Le résultat est que les processus visés par nice obtiennent une part des ressources d'UC inférieure à celle des autres processus sur le même noeud limite. Sous Solaris Resource Manager, nice a peu d'incidence sur les taux d'exécution des processus exécutés sur des noeuds différents, sauf si le nombre de processus dans la file d'attente des processus exécutables excède le nombre d'UC.

Sous Solaris Resource Manager, les processus ayant une valeur nice maximale (par exemple, ceux qui démarrent avec une commande nice -19) font l'objet d'un traitement spécial : ils obtiennent du temps d'UC uniquement si les autres processus n'en font pas la demande et seraient de toutes façons inactifs.

Pour en savoir davantage sur nice, voir nice(1) et nice(2SRM). Pour en savoir davantage sur la relation entre Solaris Resource Manager et d'autres fonctions de contrôle des ressources, reportez-vous à la rubrique Différences entre Solaris Resource Manager et les produits similaires.

Reconfiguration dynamique

La fonction de reconfiguration dynamique (RD) des serveurs Sun Enterprise permet aux utilisateurs d'ajouter et de supprimer dynamiquement des cartes systèmes comportant des ressources matérielles comme des processeurs, de la mémoire et des périphériques d'E/S. Aux fins de l'ordonnancement, Solaris Resource Manager effectue le suivi des ressources processeur disponibles et gère les changements en conséquence, redistribuant équitablement les ressources libres entre les utilisateurs et les processus admissibles.

Solaris Resource Manager contrôlant uniquement la taille de mémoire virtuelle des processus et non la mémoire physique consommée par les processus et les utilisateurs, l'incidence d'une opération RD sur la mémoire n'a aucun effet sur la vérification des limites de mémoire effectuée par Solaris Resource Manager.

srmidle Noeud limite inactif

Le noeud limite inactif (srmidle) est celui qui est assigné par l'administrateur central pour facturer tous les coûts d'UC inactive du noyau. Lors de l'installation, srmidle a été créé avec l'UID 41. Le noeud limite srmidle ne doit pas avoir de partage, pour garantir que les processus qui lui sont liés sont exécutés uniquement lorsque aucun autre processus n'est actif. Le noeud limite srmidle est affecté au moyen de la commande srmadm.

A la réinitialisation, le noeud limite inactif par défaut est le noeud limite root. Lors du passage en mode multi-utilisateur, le script init.d définit le noeud limite inactif comme étant celui du compte srmidle si celui-ci existe. Cette procédure peut être personnalisée en précisant un autre noeud limite dans le script /etc/init.d/init.srm.

Si le noeud inactif n'est pas le noeud root, il doit s'agir d'un enfant direct de celui-ci.

srmother Noeud limite autre

Le noeud limite autre (srmother) est celui qui est assigné par l'administrateur système en tant que noeud limite père par défaut pour les nouveaux utilisateurs créés après l'installation initiale (où le noeud limite père par défaut est la root). Le noeud smrother, qui est créé automatiquement à l'installation et ne peut pas être changé, a une valeur par défaut de 1 partage, pour garantir que les noeuds limites qui y sont connectés pourront accéder à l'UC. Le noeud smrother a été créé avec l'UID 43.

Le noeud smrother ne doit avoir aucune limite de ressources, un partage d'UC de 1 ou plus, et aucun privilège particulier.

srmlost Noeud limite perdu

Sous Solaris Resource Manager, l'appel système setuid (2SRM) a comme effet secondaire de relier le processus appelant à un nouveau noeud limite. Si le changement de liaison échoue, ce qui se produit habituellement parce que le nouveau noeud n'existe pas, le processus est alors relié au noeud perdu (srmlost), ce dernier étant créé à l'installation de Solaris Resource Manager. Si cette liaison échoue aussi ou qu'aucun noeud srmlostn'a été assigné, la fonction setuid n'est pas touchée et le processus demeure sur son noeud limite actuel.

Le script init.srm définit le noeud limite srmlost pendant la transition au mode de multi-utilisateur. Ce comportement peut être outrepassé en précisant le noeud limite à utiliser dans le fichier /etc/init.d/init.srm. Pour éviter les failles de sécurité, le noeud srmlost doit avoir une part d'UC de 1 et aucun privilège spécial. Si vous modifiez les valeurs, tenez compte des besoins de cet utilisateur lors des changements.

Le noeud limite srmlost a été créé avec l'UID 42.