Auteur : Judith DEFO

Rapport d’installation de SRM

1- Gestion des ressources avec SRM...

2- Classes d’ordonnancement

3- Gestion de l’utilisation des ressources CPU..

4- Organisation hiérarchique des ressources.

4.1- Le fichier lnode

4.2- Utilisateurs et groupes.

4.3- Notion de parts.

4.4- Répartition des parts dans une hiérarchie.

4.5- Les fichiers lnodes spéciaux.

5- Administration de SRM.

5.1 Pour consulter l’arborescence :

5.2 visualisation des attributs et flags d’un lnode.

5.3 Ajout d’un user dans un sgroup.

5.4 Attribution des parts à un lnode ou un sgroup.

5.5 Test de l’utilisation de la CPU.

5.6 Test de l’utilisation de la mémoire.

5.7 Vérification du lnode propriétaire d’un process.

5.8 Arrêt de tous les process appartenant à un lnode.

5.9 Editions de rapports et de statistiques.

1- Gestion des ressources avec SRM

Le logiciel SRM (Solaris Ressource Manager) gère
les classes de ressources suivantes dans l’environnement
Solaris : 

• Allocation de temps CPU

• Limites d’utilisation de la mémoire virtuelle

• Limites en terme de nombre de processus

• Limite en terme de nombre de connexions

L‘une des fonctions majeures de SRM est le
contrôle de l’accès au CPU qui s’effectue en
ajoutant une nouvelle classe d’ordonnancement à
l’environnement Solaris( cette classe est la classe SHR)

2- Classes d’ordonnancement

L’environnement d’exploitation
Solaris fournit 4 différents groupes de priorités
appelés « classes d’ordonnancement »
qui permettent de contrôler l’utilisation des ressources
CPU.

• La classe Temps réel( RT) – La classe temps réel
  a la priorité absolue au sein du système, sauf pour le
  traitement des interruptions.

• La classe système (SYS) – La classe système
  qui gère les priorité au niveau de noyau, est utilisée
  pour les threads du système tel que les démons de
  pages et les threads d’horloges. La classe système ne
  contient aucun paramètre configurable

• La classe Time Sharing (TS) - La classe partage de temps est
  utilisée pour les travaux standards des utilisateurs. Les
  priorités sont ajustés dynamiquement en fonction de
  l’utilisation des ressources CPU.

• La classe interactive (IA) – La classe interactive
  dérive de la classe partage de temps, et accroît les
  performances des taches exécutées dans les fenêtres
  actives tels que Cde ou Openwindow

3- Gestion de l’utilisation des ressources CPU

 La configuration de SRM définit des
quantités cibles d’utilisation des ressources CPU pour
les groupes d’utilisateurs et des utilisateurs individuels du
système. Ces quantités sont exprimés sous forme
de rapport. SRM remplace les classes TS et IS par la classe SHR
(share).

La classe de parts SHR est une nouvelle classe
d’ordonnancement ajouté à l’environnement
Solaris. Elle exécute les mêmes fonctions que les autres
classes détermine le priorité d’ordonnancement 
des threads et processus ainsi que la quantité de temps CPU
que ce thread/processus peut utiliser.

Une certaine part de temps CPU disponible est
alloué à chaque utilisateur de CPU. SRM gère
l’accès de façon à équilibrer le
rapport entre les groupes et les utilisateurs.

Supposons par exemple qu’une tâche a
utilisé la CPU de façon intensive et a largement
dépassé sa part (Cette situation peut apparaître
si aucun autre travail n’a besoin de CPU). Lorsqu’une
nouvelle tâche débute, le temps CPU accordé à
la première tâche est considérablement, voir
totalement réduite jusqu’à ce que le nouvel
utilisateur ait consommé suffisamment de temps CPU pour
rétablir l’équilibre du rapport d’utilisation
par rapport à la première tâche.

SRM utilise une combinaison de rapport
d’utilisation totale de CPU sur une certaine période.
L’une des principales tâche lors de la configuration de
l’outil est de déterminer les rapports.

4- Organisation hiérarchique des ressources

4.1- Le fichier lnode

SRM utilise le fichier lnode (limit node) pour
identifier un utilisateur et enregistrer son appartenance à un
groupe, son total de parts de CPU et les statistiques cumulées
sur l’utilisation des ressources. Ces fichiers lnodes sont
crées lors de l’installation de l’outil pour tous
les utilisateurs existants.

Un fichier lnode est donc associé à
chaque utilisateur. Le système lit ces fichiers lors du
démarrage du système afin de déterminer les
parts de ressources utilisable par chaque utilisateur. Ils permettent
aussi d’enregistrer les ressources consommées par
utilisateur.

Attention : SRM ne gère les ressources que des utilisateurs dont l’uid <65xxx

Les fichiers lnodes sont classés dans une
structure arborescente dans laquelle un rapport de part est défini
entre les homologues ayant le même parent. Les fichiers lnodes
des utilisateurs parents constituent les fichiers sgroup
(scheduling group)

Un sgroup peut être un utilisateur
existant ou un compte réservé qui sert de consolidation
pour les utilisateurs de niveau inférieur. Les statistiques
sont cumulés dans le fichier lnode pour l’utilisateur.
Elles sont également cumulées au niveau du sgroup
incluant tous les lnodes inférieurs au sgroup dans la
structure hiérarchique y compris le sgroup de niveau
inférieur.

Les processus étant rattachés aux
fichiers lnodes, ils héritent des propriétés
affectées à ces fichiers. En règle général,
un processus appartient aux fichiers lnode du parent initiateur, mais
ce n’est pas toujours le cas (utilisation de la commande
srmuser
pour lancer sous un autre lnode)

La figure 1 page suivante montre un exemple
d’arborescence SRM

Root, oracle sont des sgroup

Appuser, srmidle, srmlost, srmother sont des
lnodes

 
Figure 1

4.2- Utilisateurs et groupes

SRM effectue le suivi des ressources consommées.
Chaque ressource consommée est imputée au fichier lnode
et cumulée dans ce fichier . Il ne fait aucune différence
entre un fichier lnode et un fichier sgroup. Toute propriété
attribué à un lnode peut être attribué à
un sgroup.

Les propriétés non spécifiées
dans un lnodes sont hérités du sgroup parent

Si un utilisateur de système est inconnu
de SRM, un fichier lnode par défaut est associé à
cet utilisateur(srmother)

4.3- Notion de parts

SRM alloue l’utilisation des ressources au
prorata de la part détenu par chaque fichier lnode. Une
attribution désigne une quantité de ressource CPU que
le fichier lnode reçoit. Tous les fichiers lnodes ont une
attribution. Tous les processus appartenant au fichier lnode
participent à l’utilisation de cette part. Le nombre de
parts utilisables par un système est illimité.

Une part définie un rapport d’utilisation
des ressources entre les fichiers lnodes homologues dans
l’arborescence, au sein du même sgroup. Peu importe si
l’homologue est un fichier sgroup ou un lnode.

 figure 2

La figure 2 décrit un sgroup (sales
Database) et un lnode (Webservers)
Le rapport entre les parts est 80 pour le sgroup et 20 pour le lnode
serveur Web

En pourcentage ce la donne 80% CPU pour le
sgroup (sales Database) et 20% pour le lnode Web server En admettant
qu’aucune activité n’est généré
par le sgroup parent (root)

A l’intérieur du groupe les
fichiers lnodes se partagent les parts dans le rapport 20 pour online
et 1 pour batch. En admettant que le sgroup sales Database n’est
pas un utilisateur actif par conséquent ne génère
aucune activité.

4.4- Répartition des parts dans une hiérarchie

Les fichiers sgroup et lnodes ont deux valeurs
de part d’attribution

La première cpu.shares,
est une part d’attribution que le fichier lnode reçoit(du
lnode parent) par rapport à son homologue dans son sgroup
parent. Il s’agit du rapport décrit dans le paragraphe
précédent.

La seconde cpu.myshares
est la part de contribution que le fichier lnode du sgroup reçoit
par rapport au membre de son groupe(les lnodes fils) . Par conséquent
le fichier lnode du sgroup est en fait considéré comme
un homologue de ses membres lorsque les attributions de CPU sont
déterminées.

En admettant que root ne consomme rien comme
ressource. Sa part de CPU par rapport a ses homologues (inexistant
ici car c’est la racine) est de 100.

Cette part il la partage entre les groupes
Databases
et batchs.
Databases et batchs
possèdent des parts dans un rapport 20 :1 soit
20/21pour database
et 1/21% pour batchs.

Dans le groupe database
. La consommation de CPU du groupe sera utilisé par db1 et db2
dans un rapport de 1 :3 . Si A est la consommation de CPU de
database, 
cette consommation sera répartie de la façon suivante
1/4A pour db2 et 3/4Apour db1.

Supposons que db1 est un vautour qui rapporte à
sa progéniture les restes d’une proie partagée
avec les autres prédateurs. Cette nourriture sera ensuite
redivisée pour nourrir toute la famille. Si un des oisillons
est absent, sa part est répartie entre les oisillons présents.
Db1 aura donc une part de 4/10(cpu.myshares=4 ce paramètre
définit sa part par rapport aux lnodes fils ws1) et ws1 6/10
de la proie.

4.5- Les fichiers lnodes spéciaux

5- Administration de SRM

Les commandes d’administration de SRM sont
dans les repertoires /usr/srm/bin
/sur/srm/sbin /usr/srm/unsupport. Le manuel
des commandes est dans le repertoire /usr/srm/man.

Il y’a un fichier /.env-judith
qui contient les variables d’environnement PATH et MANPATH
adapté à SRM .

5.1 Pour consulter l’arborescence :

#  /usr/srm/unsupport/schedtree

5.2 visualisation des attributs et flags d’un lnode

On utilise la commande liminfo pour visualiser les parts actuellement allouées pour  un utilisateur spécifique

# liminfo
dave à
donne la consommation de l’utilisateur dave

# liminfo
–v dave ->donne les valeurs de tous les attributs du user
dave.

Parmi les attributs qui sont listé par la
commande précédente, certains peuvent être
modifiées (par la commande limadm).

5.3 Ajout d’un user dans un sgroup

Username=joe sgroup=batch
#  limadm set sgroup=batch joe
La commande précédente va créer un lnode pour l’utilisateur joe s’il n’existait pas et va l’ajouter dans le sgroup batch.

5.4 Attribution des parts à un lnode ou un sgroup

#  limadm set cpu.shares=20 databases
#  limadm set cpu.shares=1 batch
#  limadm set cpu.shares=1 joe

Les paramètres de configuration de la
consommation CPU sont les suivantes :

  cpu.myshares

Les paramètres de configuration de la
consommation de mémoire virtuelle sont les suivantes :

SRM gère le nombre de processus grâce
aux flags process( visibles dans les attributs d’un
lnode liminfo –v
user)

Tous les paramètres listées dans les tableaux précédents peuvent être modifiés par la commande limadm

5.5 Test de l’utilisation de la CPU

SRM fournis un script nspin
permettant d’effectuer des tests CPU. Utilisé sans
argument, ce script créer un processus exécuté
en boucle afin de consommer du temps CPU. Avec l’opérande
–n xx il génère
xx processus individuel rattachés au même
lnode.

# nspin
–n 20&

Cette commande lancera en arrière plan 20
processus npin afin de générer une consommation en CPU

Il est possible de lancer une commande sous une
autre identité

# 
srmuser oracle nspin –n 20&

Etant connecté root, en tapant la
commande précédente , on lance 20 processus nspin en
arrière plan appartenant au lnode root

5.6 Test de l’utilisation de la mémoire

En admettant qu’on a fixer un plafond à
5m par process pour le user toto, on peut tester de la façon
suivante :

# 
srmuser toto dd if=/ddev/zero of=/dev/null bs=6000k

5.7 Vérification du lnode propriétaire d’un process

#
plimit –p < pid>

5.8 Arrêt de tous les process appartenant à un lnode

#
srmkill <lname>

5.9 Editions de rapports et de statistiques

La commande limreport extrait les données
de la base SRM et des fichiers lnode du noyau. Cette commande
flexible permet de mettre en forme les données extraites

Synthaxe :

limreport
select-expression format [identifier]...

Exemple :

Pour afficher les noms de tous les
fichiers lnodes.

#
limreport flag.real – lname

Le flag flag.real est un flag qui est
définit uniquement pour les lnodes. Ca permet de récupérer
entre autre la liste des comptes ayant un lnode.

Pour connaître l’utilisateur associé
à l’UID 13562 avec un formatage simple

#
limreport uid==13562 “uid %d is user %s.\n” uid lname

Pour afficher les utilisateurs actifs du système
ainsi que leur emplacement dans la hiérarchie

#
limreport ‘flag.real&&cpu.usage>0’ – uid
sgroup lname cpu.shares

cpu.usage|sort
+1n +0n

La commande srmstat permet d’afficher
l’utilisation courante des parts dans la hiérarchie SRM.
La commande limreport génère des rapports sur
l’utilisation cumulé des ressources dans les fichiers
lnodes, tandis que la commande srmstat génère des
rapports sur l’activité courante au sein du système
évalué par SRM

Il permet d’afficher les par affecté
à chaque lnode ainsi que les part effectivement reçu
par le lnode

#
srmstat –Ra –c

Cette commande donne la répartition des
parts CPU continuellement

Auteur : Judith DEFO