Cet exemple illustre la commande suivante :
Détruit tous les processus actifs reliés à un noeud limite.
Le service des finances est propriétaire du système de base de données, mais un utilisateur (Joe) du service de génie doit exécuter un travail de calcul et voudrait utiliser la machine des finances durant les heures où le système est généralement inactif. Le service des finances considère le travail de Joe comme moins important que les bases de données, et accepte d'exécuter son travail uniquement s'il ne perturbe pas le rôle principal du système. Pour mettre cette politique en oeuvre, ajoutez un nouveau groupe ( lot) au noeud limite base de données, et ajoutez Joe au nouveau groupe lot dans la hiérarchie de noeuds limites du serveur.
% limadm set cpu.shares=20 databases % limadm set cpu.shares=1 batch % limadm set cpu.shares=1 joe % limadm set sgroup=lot joe |
Cette série de commandes permet de modifier l'attribution des parts afin que le groupe bases de données possède 20 parts, et le groupe lot une seule. Ainsi, les membres du groupe lot (Joe seulement) utiliseront au plus 1/21 des ressources de la machine si le groupe bases de données est actif. Le groupe bases de données reçoit 20/21, ou 95,2 %, ce qui dépasse la proportion de 60 % + 20 % = 80 % antérieurement déterminée comme étant suffisante pour exécuter les applications de base de données. Si les bases de données ne demandent pas leur attribution entière, Joe recevra plus que sa part de 4,8 %. Si les bases de données sont inactives, l'attribution de Joe pourrait atteindre 100 %. Lorsque le nombre de parts disponibles attribué aux bases de données est augmenté de 1 à 20, il n'est pas nécessaire de modifier l'attribution des parts de bd1 et bd2. Dans le groupe bases de données, quatre parts sont toujours disponibles, attribuées à raison de 3/1. Les différents niveaux de l'arbre d'ordonnancement sont complètement indépendants ; seul le rapport du nombre de parts entre les groupes homologues importe.
Même avec ces assurances, le service des finances souhaite s'assurer que Joe ne pourra pas ouvrir de session durant les heures de bureau. Cela peut être accompli en insérant certains contrôles de connexion dans le groupe lot. Comme les contrôles tiennent compte de l'heure, l'objectif peut être réalisé en exécutant un script modifiant le nombre de connexions accordées au groupe lot au début et à la fin de la journée. Par exemple, des entrées crontab pourraient être employées :
0 6 * * * /usr/srm/bin/limadm set logins=0 batch 0 18 * * */usr/srm/bin/limadm set logins=100 batch |
À 6h00, la limite de connexions de lot passe à 0, et à 18h00, elle est augmentée de manière à permettre 100 connexions.
Une politique encore plus stricte peut être mise en oeuvre en ajoutant une autre ligne à l'entrée crontab :
01 6 * * * /usr/srm/bin/srmkill joe |
Cette ligne utilise la commande srmkill pour détruire tout processus relié au noeud limite Joe à 6h01. Cela ne sera pas nécessaire si les seules ressources requises par le travail sont contrôlées par Solaris Resource Manager. Cette action pourrait toutefois être utile si le travail de Joe était susceptible d'accaparer des ressources qui nuiraient aux opérations normales, par exemple un travail pouvant bloquer une base de données ou dominant un canal d'E-S.
À présent, Joe peut ouvrir une session et exécuter son travail uniquement durant la nuit. Vu que Joe (et le groupe lot) détient beaucoup moins de parts que les autres applications, l'exécution de son application utilisera moins de 5 % des ressources de la machine. De même, la commande nice(1) peut être utilisée pour réduire la priorité des processus reliés à ce travail, afin que sa priorité d'exécution soit inférieure à celle des autres travaux ayant le même nombre de parts dans Solaris Resource Manager.
Maintenant, le service des finances a fait le nécessaire pour que ses applications de base de données aient un accès suffisant au système et ne se nuisent pas mutuellement. En outre, les besoins de traitement par lot nocturnes de Joe sont satisfaits, tout en s'assurant qu'ils ne perturberont pas les applications critiques.