Bienvenue sur le site admin-sys

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

srmidle

Une tâche rattaché au fichier lnode srmidle est
uniquement exécutée lorsque la file des tâches
en attentes d'exécution est vide. Cette tâche
consommera donc tout le temps CPU restant. Ce fichier lnode est
créé par défaut sous l'uid 41. Le
nombre de part attribuer à ce lnode doit toujours être
nul.

srmlost

Le fichier lnode srmlost hérite des processus rattachés
aux comptes inexistant(à l'aide de la commande setuid
par exemple)

Son uid par défaut vaut 42 . on peut changer sont uid

srmother

Le système utilise le fichier lnode srmother comme sgroup
par défaut pour les nouveaux utilisateurs ajouté au
système, avant de les transférer à leur
emplacement correct dans l'arborescence de SRM

Le système créé automatiquement ce lnode lors
de l'installation. Son uid vaut 43. Son nom et son UID ne
peuvent pas être modifiés.

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.shares`	Part d'attribution de CPUque le fichier lnode par rapport à son homologue dans son sgroup parent
cpu.myshares	Part d'attribution de CPU que le fichier lnode du sgroup reçoit par rapport aux membre de son groupe

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

memory.limit

Nombre total maximum d'octets de mémoire virtuelle
que les processus connectés à ce lnode peuvent
utilisés.

memory.plimit

Nombre total maximum d'octets de mémoire virtuelle
qu'un seul processus connectés à ce lnode peut
utilisés.

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

`Process.limit`

Nombre maximum de process pouvant être attaché à
un lnode/

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

`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]...

select-expression

est une expression qui décrit les données à récupérer dans la base SRM. La commande limreport effectue un seul passage dans la base affin de récupérer les données de formater les lignes correspondant à cette expression

format

est une spécification du format de type printf. Un – désigne le format par défaut

[identifier

le nom de l'attribut ou flag du fichier lnode

limreport –a pour afficher tous les indicateurs possibles

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

Introduction SRM

Jerome ROBERT — 2008-09-16T16:52:37Z

 SRM - Solaris Resource Manager

 ==============================

I/ Introduction

===============

SRM est un produit integre par Sun a partir du produit

"Share II" de la societe australienne Softway: http://www.softway.com.au

SRM est une application qui permet de CONTROLER et LIMITER la

disponibilite des ressources d'un serveur pour des users, groupes

et applications.

Il permet d'allouer des pourcentages de CPU, memoire virtuelle,

nombre de processus, max logins et connect times a des users et

groupes.

Cette application est ideale pour consolider des serveurs qui

hebergent plusieurs applications critiques.

SRM est implemente en utilisant une nouvelle classe de scheduling

SHR qui remplace les classes "standards" IA/TS (Time Sharing).

II/ Concepts

===========

2.1/ Le concept des lnodes

--------------------------

SRM est construit autours d'un nouveau concept introduit sous Solaris: les

'lnodes' alias 'limit nodes'. Il s'agit de nodes qui correspondent a des

UIDs au sens Solaris (definis dans /.etc/passwd ou sous NIS). Ils sont

utilises par le kernel pour appliquer les limitations de ressources a des

users, processus ou groupes de users.

Les lnodes sont organises hierarchiquement en arbre: le 'scheduling tree'.

Ils seront crees relativement aux uids Solaris mais pas automatiquement,

cette tÃ¢che est du ressort de l'administrateur.

D'autres lnodes peuvent Ãªtre ajoutes avec la commande 'limadm'.

Il faudra les effacer manuellement lorsque le user sera efface de la

map passwd.

Note: On peut techniquement creer un lnode qui n'a pas d'UID equivalent

dans la map passwd mais ce n'est pas recommande.

Tous les processus vont ensuite Ãªtre rattaches a un 'lnode'. le processus

'init' et ces descendants seront toujours rattaches au lnode 'root' apres

le boot de la machine.

Les limites sont ensuite affectees a chaque lnodes du scheduling tree.

Les limites du root lnode doivent Ãªtre laissees a zero. Zero voulant

dire 'pas de limite'.

Il existe deux classes de ressources:

 a/ FIXED resources (ou non-renewable resources)

 Il s'agit de ressources disponibles en quantite finie.

 (number of logins, connect time).

 b/ RENEWABLE resources

 Resources disponibles en continu comme le temps CPU:

 ce sont des ressources qui une fois consommees ne sont plus

 reclamables.

Les users se verront alloues dynamiquement par le SHR scheduler

le temps cpu en proportion du nombre de 'shares' qui leur auront

ete alloues un peu comme dans une societe commerciale.

A chaque lnode est affecte un nombre de 'shares', qui permettra de

recalculer la priorite des threads d'un processus. La nouvelle

priorite est calculee a chaque 'tick' suivant la formule:

 CPU_usage x (# active_process)

new_SRM_priority = current_SRM_priority + ------------------------------

 (# of shares) x (# of shares)

Seuls les lnodes actifs (ceux ayant des processus running attaches)

seront calcules. Le CPU_usage de chaque lnode va donc augmenter.

Le SHR scheduler va ajuster les priorites pour forcer les ratios relatifs

de CPU_usage a converger vers les ratios relatifs des CPU shares pour

tous les lnodes actifs. De facon a ce qu'a LONG TERME, chaque user

recoive bien le CPU_usage relatif a son nombre de shares.

Il s'agit d'un 'long term scheduler', les ajustement se font lentement

par modifications des priorites.

2.2/ Avantages du SRM scheduler

-------------------------------

- SRM permet de scheduler des users & applications plutÃ´t que

des processus (comme le fait le scheduler standard).

Chaque processus etant associe a un lnode sur lequel sont positionnees

des limites.

- Ce scheduler ne "gaspillera" jamais de temps CPU: mÃªme si un user a une

limite tres faible, si personne d'autre n'utilise la CPU il se verra alloue

toutes les ressources.

- La limitation sur la memoire virtuelle est geree en utilisant un modele de

ressource fixe. On peut limiter la consommation d'un processus en memoire

virtuelle et ainsi eviter qu'une application (suite a un memory leak par

exemple) s'approprie toute la memoire. On evite ainsi un possible bloquage

de la machine.

- Le nombre de processus qu'un user peut lancer est controle selon un modele

de ressource fixe avec limites hierarchiques.

- On peut aussi gerer des limites sur le nombre de logins et le temps de

connexion toujours de facon hierarchique.

La cle d'une bonne gestion des ressources sous SRM repose sur une bonne

conception de l'arbre hierarchique des lnodes et des limites definies

pour chaque lnode.

2.3/ Un exemple simple

----------------------

Nous allons mettre en place le controle des ressources pour 2 users

seulement: wallace et gromit. Ces deux users vont consommer de grandes

quantites de CPU mais a des moments differents de la journee.


 
 +---------+
 | root |
 | CPU=100 |
 +---------+
 / \
 / \
 / \
 +---------------+ +---------------+
 | wallace | | gromit |
 | cpu.shares=50 | | cpu.shares=50 |
 +---------------+ +---------------+

Wallace et Gromit ont ete integres dans la hierarchie SRM comme

fils du user 'root' avec les commandes suivantes:

# limadm set sgroup=root wallace

# limadm set sgroup=root gromit

Les valeurs des shares pour les 2 users ont ete positionnees par les

commandes suivantes:

# limadm set cpu.shares=50 wallace

# limadm set cpu.shares=50 gromit

On peut verifier toutes ces informations avec:

# liminfo -c wallace

Attention: seul les lnodes ayant des processus attaches et actifs seront pris

en compte pour le calcul des limites: si par exemple le lnode 'gromit' n'a

aucun processus actif, wallace aura 100% des ressources cpu.

2.4/ La 'limit database'

-----------------------

Elle va contenir un lnode par UID qui sera accede par indexation directe avec

l'UID. Cette base est cree au boot de la machine par le script de demarrage

/etc/init.d/init.srm. La base est cree par defaut sous /var/srm. Cette base

appartient au user root, groupe root et seulement lisible par root.

Note: les numeros d'UID n'etant pas sequentiels, les lnodes seront donc

stockes dans un fichier a trou sous ufs (tmpfs ne supporte pas les fichiers

a trou). Seule la commande ufsdump/ufsrestore preserve le fichier a trous

(les commandes cp, tar et cpio copieront les trous comme des sequences de 0...).

L'administrateur doit maintenir la limit database en parallele de la

map passwd. La commande suivante permet d'afficher la liste des UIDs

qui n'ont pas de lnode associe:

# limreport \ !flag.real - uid lname

Lors de la creation d'un lnode, les valeurs suivantes sont positionnees par

defaut:

 . flag.real est positionne

 . cpu.shares et cpu.myshares sont fixes a 1

 . les flags 'uselimadm' et 'admin' sont devalides

 . tous les autres flags sont positionnes a 'inherit'

 . toutes les limites et attributs sont positionnes a 0

La commande limadm permet de detruire un lnode sans detruire le user

correspondant dans la map passwd. Il faut Ãªtre root pour utiliser limadm

ET avoir le flag 'uselimadm' positionne (ou avoir un flag 'admin' mais

on ne peut dans ce cas detruire que les lnodes du groupe dont on est leader).

2.5/ La notion de shares

------------------------

Le SHR scheduler va controler l'allocation des ressources cpu. Le concept

des 'shares' va permettre de controler facilement les allocations entre

differents users, groupes et applications.

La notion de shares est analogue a celle d'une societe: ce qui est important,

ce n'est pas le nombre absolu de shares qu'on possede mais le nombre relatif

de shares par rapport aux autres actionnaires.

Il y a 4 attributs par lnodes pour definir les shares:

 . cpu.shares: permet de fixer le ratio de cpu que ce lnode pourra

 utiliser par rapport aux autres lnodes.

 . cpu.myshares: valable seulement si le lnode possede des fils actifs,

 il s'agit de la part de share attribuee a chaque lnode.

 Il permet de fixer le ratio de CPU que ce lnode pourra

 utiliser par rapport a ses fils.

 . cpu.usage: cet attribut est augmente a chaque 'tick' horloge

 lorsqu'un lnode a utilise la cpu pendant 1 tick, cet

 valeur est diminuee suivant un taux defini par le

 parametre global SRM 'usage decay rate' suivant un

 algorithme exponentiel base sur les periodes de demi-vie...

 . cpu.accrue: cet attribut est similaire a cpu.usage mais la

 diminution du 'decay usage rate' n'est pas appliquee.

Les valeurs de cpu.shares et cpu.myshares vont permettre de calculer

un pourcentage d'allocation cpu pour chaque lnode dans l'arbre.

Les 'shares' des users inactifs seront evidemment redistribues aux

users actifs: si un seul user est actif, alors ce user aura 100%

des ressources cpu disponibles.

Le share alloue a un lnode et son cpu.usage vont permettre de determiner quel

est son 'effective share' calcule en temps reel.

Le scheduler SRM va ajuster en permanence les priorites des processus

attaches a un lnode pour que le pourcentage de cpu utilise soit toujours

proportionnel a "l'effective share" de ce lnode.

Note: Tous les processus attaches a un lnode ont des donnees specifiques SRM

dont le 'sharepri': a tout moment le processus avec la valeur de 'sharepri'

la plus faible sera le plus elligible pour Ãªtre schedule sur une CPU.

Les autres limites controlables sont:

 . memory.limit: permet de limiter la quantite de memoire virtuelle

 que le lnode pourra utiliser. Lorsque la limite est

 atteinte, les appels syteme du type malloc() renvoie

 un code d'erreur.

 . memory.plimit: permet de limiter la quantite de memoire virtuelle

 par processus attaches a un lnode donne (idem que

 memory.limit mais par processus).

 . process.limit: permet de limiter le nombre maximal de processus

 pouvant s'attacher au lnode (limitation du nombre

 de processus parallele).

2.6/ Les lnodes speciaux

------------------------

 . srmidle: cet lnode predefini est en charge de comptabiliser tous

 les temps idle cpu. Ce lnode a un share egal a 0 pour que les

 processus lances le soient uniquement lorsque aucun autre processus

 ne tourne (au boot, par defaut, srmidle est le root lnode).

 . srmother: cet lnode est cree lors de l'install (egal au lnode root

 par defaut) et a un share egal a 1 pour assurer que les processus qui

 y sont rattaches aient acces a la cpu. Les nouveaux users y seront

 attaches.

 . srmlost: 'setuid' sous Solaris va avoir comme effet de bord

 d'attacher le processus appelant au nouveau lnode. Si cette derniere

 operation echoue (lnode inexistant...): alors le processus est attache

 au lost lnode (srmlost). srmlost a un share egal a 1.

2.7/ Un scheduling tree plus complexe

-------------------------------------

Essayons de calculer les pourcentage de cpu effectifs attribues aux lnodes

du scheduling tree ci-dessous:


 
 +-------------- R 1,1 ------------------------+ 
 / | \
 / | \
 ** / | \
 +--- A 3,1 + M 1,2 +- W 1,0 +
 / | \ | / \
 / | \ | / \
/ | * \ *** | / \
B 2 C 2 +- D 2 + N 2 X 2,0 Y 1
 / | \ |
 / | \ |
 / | \ Z 2
 E 2 F 2 G 2

Convention:

----------

Les lnodes sont notes [NAME share,myshare], donc le premier lnode root avec

un share=1 et myshare=1 est note R 1,1.

Les * representent les processus attaches au lnode associe, on voit que A

a 2 processus actifs alors que C n'en a qu'un seul.

Comment calculer les priorites effectives liees a cet arbre ?

a/ Tout d'abord: seuls les lnodes ayant des PROCESS ACTIFS dans leur

sous-arbre sont pris en compte dans le calcul en temps reel des pourcentages

de cpu relatifs a allouer a chaque lnode.

Donc, au premier niveau sous le lnode root, seuls les lnodes A et M seront

pris en compte pour les calculs !

b/ 'A' possede 3 shares alors que 'M' n'en a qu'un seul: donc le total etant 4,

'A' se verra alloue 3/4 (75%) des ressources CPU pour son sous-arbre alors que

'M' aura 1/4 (25%).

Si 'X' avait eu des processus actifs par exemple le calcul aurait ete

completement different et on aurait eu la distribution suivante pour le

premier niveau de l'arbre:

 A = 3/5 (60%)

 M = 1/5 (20%)

 W = 1/5 (20%)

c/ Apres cela, pour calculer la valeur attribuee au seul noeud 'A', il faut

utiliser la valeur du 'cpu.myshare'. Pour 'A', myshare=1 donc 'A' aura 1/3

des ressources calculees precedemment soit 75% * 1/3 = 25%. 'C' etant le seul

a posseder des processus actifs va recuperer les 2/3 restants soit 50%.

d/ 'M' n'ayant pas de processus actifs, 'N' va donc recuperer la totalite

des ressources allouees pour cette partie de l'arbre soit 25%.

Resume des pourcentages alloues au lnodes et processus associes:

 A=25% M=25%

 process1=12.5%

 process2=12.5%

 C=50% N=25%

 process3=50% process4=8.3%

 process5=8.3%

 process6=8.3%

Attention car ces chiffres varient dynamiquement en permanence au fur

et a mesure que les processus sont crees et detruits...

2.8/ Utilisation de SRM avec les SGBD

-------------------------------------

SRM peut Ãªtre utilise pour limiter les ressources utilisees par une base

de donnees mais seulement sous certaines conditions.

En effet, il existe 2 modes principaux dans lequels sont utilisees les bases

de donnees:

 . mode 2n:

 Dans ce mode, un processus SEPARÃ‰ existe pour chaque user utilisant

 la base de donnees.

 . mode Multi Threaded Server (MTS):

 Dans ce mode, un seul processus multi-threade sert tous les user de

 la base.

Une base en mode MTS ne sera pas controlable par SRM car tous les users

vont utiliser les ressources sous le mÃªme UID (UID=oracle par exemple).

Des bases comme Oracle 8i par exemple fournissent les moyens de fixer des

restrictions sur les allocations cpu par query ou par users.

En revanche, une base en mode 2n sera facilement controlable sous SRM dans

la mesure ou chaque user utilise son propre UID.

En mode 2n, Oracle forque un "Oracle shadow process" pour chaque user

qui s'attache a la base. Ce shadow process s'attache ensuite a la zone

centrale de memoire partagee de la base et effectue ses I/O directement

sur les fichiers de la base.

(MÃªme si les shadow process passent par un setuid(), ils ne vont pas

s'attacher a un lnode SRM different, car le lnode est affecte lors du setuid() au moment

du login et n'est pas transfere lors des setuid() ulterieurs).

En mode client/serveur 2n, le processus "Oracle network listener" accepte une

connexion venant d'un client de la base et demarre le "shadow process" pour ce

user. Il faut dans ce cas modifier les fichiers de demarrage de la base

pour que le "oracle listener" attache le "shadow process" au bon lnode.

a/ Creation des lnodes:

limadm set sgroup=root:flag.uselimadm=set oracle

limadm set sgroup=wh:cpu.shares=20:memory.limit=400M test1

le flag flag.uselimadm autorise le lnode oracle a utiliser la commande

srmuser.

b/ Exemple de demarrage des listeners dans les scripts de demarrage oracle:

% cat /etc/rc3.d/S98oracle

#!/bin/ksh

...

ORA_HOME=/ora/OraHome1

ORACLE_SID=instance1

ORA_OWNER=oracle

...

case "$1" in

'start')

[...]

su $ORA_OWNER -c "/usr/srm/bin/srmuser test1 $ORA_HOME/bin/lsnrctl start " &

[...]

ORACLE_SID=instance2

su $ORA_OWNER -c "/usr/srm/bin/srmuser test1 $ORA_HOME/bin/lsnrctl start " &

[...]

etc...

c/ Verification:

Suite a ce demarrage plus lancement d'une requete sur l'instance:

# ps -eaf | grep ora

 oracle 335 333 0 08:53:06 pts/1 0:00 -ksh

 oracle 431 335 1 10:14:52 pts/1 0:00 sqlplus system/manager@TEST8

 oracle 409 1 0 10:13:18 ? 0:00 /ora/OraHome1/bin/tnslsnr LISTENER

-inherit

 oracle 433 1 2 10:14:53 ? 0:01 oracletest8

(DESCRIPTION=(LOCAL=no)(ADDRESS=(PROTOCOL=BEQ)))

# ./limid -p 433

# ./limid -p 409

# grep test1 /etc/passwd

test1:x:1001:10::/tmp/test1:/bin/sh


# ./liminfo test1
Login name: test1 Uid (Real,Eff): 1001 (-,-) 
Sgroup (uid): wh (1002) Gid (Real,Eff): 10 (-,-) 
 
Shares: 1 Myshares: 1 
Share: 33.33 % E-share: 0.006 % 
Usage: 12130.5 Accrued usage: 366500 
 
Mem usage: 98.1641 MB Term usage: 0s 
Mem limit: 0 B Term accrue: 0s 
Proc mem limit: 0 B Term limit: 0s 
Mem accrue: 39.7158500 GB.s
 
Processes: 2 Current logins: 0 
Process limit: 0 
 
Last used: Tue Jun 20 10:13:18 2000 
Directory: /tmp/test1 
Name: 
Shell: /bin/sh 
 
Flags:

IV/ Support

===========

SRM n'est supporte que sur la gamme Server Ultra-Entreprise:

E250, E450, Netra 1200T, E3x00, E4x00, E5x00, E6x00 et E10000.

Pas de support des stations de travail.

SRM 1.0 seulement supporte sous Solaris 2.6

SRM 1.1 supporte sous Solaris 2.6 et Solaris 7

 supporte egalement sur les configurations cluster 2.x (including 2.2)

SRM1.2 supporte sous Solaris 2.6 5/98 KU 105181-11 minimum, Solaris 7

5/99 minimum ou Solaris 8. Supporte les configurations Sun Cluster 2.x

(including 2.2).

Pour utiliser avec DR sur E3x00-E6x00, il faut l'OBP 3.2.22 minimum.

Pour plus de details, voir les release notes de SRM 1.2.

Packages:

SUNWsrmb: les commandes user

SUNWsrmm: les man pages

SUNWsrma: answer book collection

SUNWsrmr: librairies et utilitaires systeme

3.1/ Installation

-----------------

Se referrer aux releases notes pour les mises a jour de patch (notamment

le patch kernel qui est important).

Il y a un 'installer' fourni sur le CDROM SRM 1.x, il suffit de monter le

cdrom puis lancer l'installer:

# cd /cdrom0/srm_1_1

# ./Installer

3.2/ Les fichiers utilises par SRM

----------------------------------

/etc/init.d/init.srm

 Il s'agit du script d'initialisation de SRM lorsque

 le serveur passe de single-user a multi-user.

/etc/rc0.d/K52srm

/etc/rc1.d/K52srm

/etc/rc2.d/S10srm

/etc/srm/limconf

/etc/srm/nolnode

 Ce script cree un lnode pour un user qui se connecte et envoie

 un mail a l'administrateur. Ce script peut Ãªtre remplace en modifiant

 /etc/pam.conf.

/etc/system contient en standard:

[...]

* Solaris Resource Manager 1.0

set initclass="SHR"

 Il s'agit de l'initialisation en classe SHR du processus

 init: tous les descendant vont en heriter, SRM est donc

 active.

 Rq: Il suffit de commenter avec un '*' cette ligne et

 rebooter le serveur pour redemarrer le serveur hors SRM.

/kernel/drv/srmdrv

/kernel/drv/srmdrv.conf

/kernel/misc/srmlim

/kernel/sched/SHR

/dev/srmdrv -> ../devices/pseudo/srmdrv@0:c,raw

/devices/pseudo/srmdrv@0:c,raw (139,0)

/usr/lib/class/SHR/SHRdispadmin

/usr/lib/class/SHR/SHRpriocntl

/usr/lib/security/pam_srm.so.1

/usr/lib/srm/liblim.so.1

/usr/lib/srm/srmscru

3.3/ Les parametres de tuning dans /etc/system

----------------------------------------------

SRMLnodes: Number of lnodes to cache in the kernel

 3kb per lnodes

 default = 0, means that kernel will determine the value

SRMProcsPerUid: The anticiped average number of processes used by each user

 default = 4

SRMLnodesExtra: A bias used in the formula used to calculate the number of

 lnodes to cache in the kernel (SRMLnodes).

 default = 20

SRMNhash: The number of entries in the hash table that is used to map

 UID values to lnodes in the kernel.

 default = 0, means to use the same value as for the numbers

 of lnodes.

SRMMemoryMax: Maximum percentage of real memory to use for SRM, lnodes

 and hash tables combined.

 default = 20 which means 5% (1/20).

SRMMemWarnFReq: The minimum interval in second between "memory exceeded"

 notification warnings from a single node.

 default = 4 i.e messages will not be sent more frequently

 than 4 seconds.

initclass: Name of the scheduling class in which the init process is

 started. Under SRM this should be given as the string "SHR".

 default = "TS"

extraclass: This is the name of a scheduling class module to load, without

 using it as the default scheduling class.

 To use SRM with only NON-CPU ressource control add the line:

 set extraclass="SHR"

3.4/ Les differentes commandes SRM

----------------------------------

/usr/srm/bin/liminfo

 Cette commande permet d'afficher les usages, limites et privileges

 lies a un user donne. Les administrateurs ont les privileges pour

 faire des requÃªtes sur d'autres users.

/usr/srm/bin/limreport

 Cette commande permet permet aux administrateurs de faire des requetes

 pour connaitre n'importe quel parametre de n'importe quel user (y

 compris les attributs 'accrues').

 # limreport 'cpu.accrue!=0' '%u %u %10d\n' uid lname cpu.accrue

 Selectionne les lnodes avec une 'accrued usage' different de 0 et

 liste les uids et 'accrued usages' des lnodes selectionnes.

/usr/srm/bin/srmkill

 Permet de tuer tous les processus attaches a un lnode donne.

/usr/srm/bin/srmstat

 Permet d'afficher des informations relatives a l'activite

 sur les lnodes en temps reel.

/usr/srm/bin/srmuser

 Permet de lancer des applications sous un lnode donne.

/usr/srm/lib/limdaemon

 Il s'agit du user-mode daemon qui est demarre au run level 2 et/ou 3.

 Il est lance avec la classe SHR et permet l'envoi de notifications

 vers le terminal, gere les connect-time usages de tous les users,

 detecte les users qui ont depasse leur limite de connect-time.

 Ce daemon enverra les notifications aux users ayants depasses leur

 limite en memoire et/ou nombre de processus par exemple.

/usr/srm/sbin/limadm

 Cette commande permet de modifier les limites fixees sur les lnodes,

 les flags et autres attributs SRM.

/usr/srm/sbin/srmadm

 Permet de positionner, modifier et afficher les parametres

 globaux SRM. Les differents parametres peuvent Ãªtre modifies

 "on the fly".

 # srmadm set -f /var/srm/srmDB fileopen=y:share=y:limits=y

 Demmarre le SRM avec le CPU scheduler, et les limitations de

 ressources.

 # srmadm set usagedecay=300s

 Positionne le CPU usage decay a un temps de demi-vie de 5s.

 # srmadm

 Affiche les parametres courants

 # srmadm show -dv

 Affiche les parametres par defaut.

 # srmstat -Rac

 Affiche et raffraichi en permanence des statistiques sur les

 usages cpu des differents users.

/usr/srm/unsupport/passwd_lnodes

 Commande non supportee qui permet de creer automatiquement les

 lnodes correspondants aux uids n'ayant pas encore de lnode. On peut

 faire un 'show' pour voir quels lnodes seront crees et lequels, puis

 il suffit de relancer la commande avec l'option 'do':

 voyager:root# ./passwd_lnodes show

 Looking for UIDs in the range >= 0 and < 59901

 3 missing lnode(s).

 limadm set -u cpu.shares=1 18483

 limadm set -u cpu.shares=1 985

 limadm set -u cpu.shares=1 18175

/usr/srm/unsupport/schedtree

 Cette commande (non supportee) permet d'afficher en ascii une

 representation hierarchique des lnodes definis sur une machine:

voyager:root# ./schedtree

 root smtp(0) [1]

 daemon(1) [1]

 bin(2) [1]

 sys(3) [1]

 adm(4) [1]

 lp(71) [1]

 uucp(5) [1]

 nuucp(9) [1]

 listen(37) [1]

 srmidle(41) [0]

 srmlost(42) [1]

 srmother(43) [1]

 oracle(107) [1]

 wh(1002) [1]

 test1(1001) [1]

^ ^

| |

 uid shares

3.5/ La phase de boot

---------------------

SRM s'initialise apres le processus 0 (sched: le swapper) et avant la creation

du processus 1 (init). La classe SHR est alors loadee, le processus 'init' est

donc schedule sous SRM (et non dans la classe de scheduling par defaut).

Le systeme execute ensuite les scripts de demarrage et passe de single-user a

multi-user et le script /etc/init.d/init.srm est lance.

3.6/ Troubleshooting

--------------------

a/ Un user ne peut pas se loguer ?

Raisons possibles:

 . pas de lnode correspondant a cet uid (message No limits information

 is available).

 . le user a le flag nologin (ou noattach)

 . le user a le flage onelogin et est a deja un autre terminal connecte

 . le user a atteint la limite de connect-time usage

 . le lnode du user est orphelin suite a la destruction du lnode parent

b/ Les users ne sont pas notifies des depassement de limite ?

 . le daemon responsable des notifications (limdaemon) ne tourne pas

 . la console n'est pas au premier plan ou cachee

 . limdaemon n'a pas assez de ressources memoire pour fonctionner

 (message a la console seulement lors de la premiere tentative qui

 echoue).

 . le fichier utmp n'existe pas et/ou est corrompu

c/ Impossible de changer un user de groupe ?

Pour changer un user de groupe il faut:

 . Ãªtre super-user

 . avoir le flag 'uselimadm' positionne

 . avoir le flag 'admin' positionne et Ãªtre un 'group header' pour

 le lnode a modifier.

d/ Les users depassent les limites tres frequemment ?

 . une limite est effectivement trop faible par rapport aux besoin

 de ce user

 . l'attribut 'usage' n'est pas 'decayed'

 . la periode entre 2 executions de 'limdecay' est trop faible

 . l'attribut 'decay' pour une ressource de type 'renewable' est

 trop faible

e/ Message de notification d'origine inconnue ?

 Les messages de notification a un 'group header' seront recu par tous

 les users dans la branche hierarchique en dessous de ce group header.

f/ La base des limites sous /var/srm est corrompue ?

 Si la corruption est prouvee, il faudra restaurer la base avec ufsdump

 ou a partir d'un 'dump' de la base effectue au prealable avec la

 commande limreport (voir section FAQs).

g/ Les connect-time ne sont pas bien mis a jour ?

 Ceci est probablement du au fait que le daemon 'limdaemon'

 ne tourne pas.

h/ Problemes de performances ?

Attention, car SRM ne controle que les processus sous la classe SHR, si des

des demandes excessives sont realisees par des processus de priorite

superieure (processus lances en RT par exemple), alors SHR ne peut

scheduler les processus que sur la base de la cpu restante.

D'une maniere generale, l'utilistaion de processus en RT (RealTime) va

generer des conflits avec l'utilisation de SRM. Les processus sous la

classe SHR auront des priorites toujours inferieures a RT.

Attention a ne pas mixer egalement trop de processus en classe SYS ou TA

lors de l'utilisation de SRM, ceci va reduire la qualite du fonctionnement

du scheduler SHR.

i/ Les lnodes orphelins ?

Un lnode est orphelin lorsque son lnode parent a ete detruit. SRM va empecher

tout processus de s'attacher a un lnode orphelin, ceci a comme effet de bord

qu'il est impossible de se loguer sous ce lnode !

Le moyen le plus facile pour detecter les lnodes orphelins est:

# limreport orphan - uid sgroup lname

On peut ensuite utiliser 'limadm' pour rattacher cet lnode a la hierarchie des

lnodes. L'administrateur peut egalement creer un nouveau user dont l'uid est

egal a l'uid defini dans le 'sgroup' du lnode orphelin.

j/ Boucle dans l'arbre des lnodes

Quand un lnode est active, tous ses parents jusqu'au root lnode sont actives.

Si un des lnodes a un parent qui a deja ete rencontre alors le kernel a

detecte une boucle...Ceci peut egalement arriver suite a une corruption de

la base des lnodes.

Il faut lister les lnodes qui sont fils du lnode root:

# limreport 'sgroup=0' - uid lname

si on detecte un lnode qui ne doit pas Ãªtre directement fils du lnode

root, c'est peut etre le haut d'un sous-arbre qui a ete rattache au lnode root.

Il faudra surement restaurer l'arbre (cf crash recovery).

k/ crash recovery

Lorsque la base des lnodes sous /var/srm est corrompue, il faut la restaurer

a partir d'un dump effectue avec limreport (cf FAQs).

IV/ FAQs

=========

Q: Comment desactiver SRM ?

A: Retirer la ligne set initclass="SHR" dans /etc/system et rebooter.

L'option -a au boot peut egalement Ãªtre utilisee, on peut alors choisir

le fichier system suivnat: etc/system.noshrload qui correspond au backup

du fichier /etc/system avant l'install de SRM (genere par l'installer).

Q: Comment savoir si SRM est installe sur un serveur ?

A: Faire un pkginfo | grep -i srm

system SUNWsrmb Solaris Resource Manager

system SUNWsrmm Solaris Resource Manager, (Man)

system SUNWsrmr Solaris Resource Manager

=> dans ce cas SRM est installe.

Q: Comment savoir si SRM est actif ?

A: Avec la commande suivante:

# srmadm show share

yes

Si la reponse est 'yes' alors SRM est actif.

D'autre part la commande suivante permet de voir si la base des lnodes

est en cours d'utilisation:

# srmadm show fileopen

yes

Q: Comment savoir quels processus sont sous le controle de SRM ?

A: Il suffit de chercher les processus ayant la classe 'SHR' avec la

commande 'ps':

# ps -eo class,pid,comm

CLS PID COMMAND

SYS 0 sched

SHR 1 /etc/init

SYS 2 pageout

SYS 3 fsflush

SYS 4 srmgr

SHR 289 /usr/lib/saf/sac

SHR 126 /usr/sbin/rpcbind

SHR 516 -sh

SHR 95 limdaemon

[...]

Q: Comment afficher un rapport des processus courant et leur valeurs

de shares et cpu usage ?

A: Avec la command limreport suivante (pipee dans un 'sort'):

voyager:root# limreport 'flag.real' - uid sgroup lname cpu.shares \

 cpu.usage | sort +1n +0n

1 0 daemon 1 4.78916348357e-225

2 0 bin 1 0

3 0 sys 1 0

4 0 adm 1 0

5 0 uucp 1 2322.94519291

9 0 nuucp 1 0

37 0 listen 1 0

41 0 srmidle 0 0

42 0 srmlost 1 0

43 0 srmother 1 0

71 0 lp 1 0

107 0 oracle 1 1.13057987261e-233

1002 0 wh 1 0

2000 0 database 3 0

2001 0 finance 1 0

2002 0 batch 1 0

1001 1002 test1 1 1.74991494383e-222

2003 2000 db1 1 0

2004 2000 db2 1 0

2005 2000 db3 1 0

2006 2001 fi1 1 0

2007 2001 fi2 1 0

2008 2002 ba1 1 0

0 4294967295 root 1 3885.78587097

0 4294967295 smtp 1 3885.78587097

'flag.real': dit a limreport de n'afficher que les couples lnode/uid reels.

'-': indique a limreport d'afficher au mieux les parametres

'uid sgroup lname...': indique la liste des infos a afficher

La sortie est pipee sur un sort pour classer les valeurs selon la 2eme

colonne et suivant la premiere colonne en ordre secondaire.

Q: Comment lancer SRM sans limites actives et sans le scheduling cpu actif ?

(pour du debug ou lors de la configuration initiale).

A: avec la commande suivante:

# srmadm set share=n:limits=n

Q: Quelles ressources systemes peuvent Ãªtre controllees par SRM ?

Il a 5 types de ressources controllables par SRM:

 . CPU

 . Virtual Memory

 . Number of Processes

 . Number of Logins

 . Limit Connect Time

Q: Que se passe-t-il lors de l'utilisation de su ou setuid ?

Le processus lance avec setuid() va changer de user et par la mÃªme occasion

de lnode, il sera donc soumis aux limitations du nouveau lnode.

Ceci est egalement vrai pour les temps de connexion par exemple grace

au Pluggable Authentication Module (PAM) 'pam_srm' (cf man pour plus

d'infos).

Attention: le lnode ne change que lorsque le effective uid change avec

l'appel systeme setuid().

D'autre part, lors d'un su d'un user X vers root, il n'y aura pas de

changement de lnode. Dans tous les autres cas (user x vers user y ou

user root vers user x), le changement de lnode se fera.

Q: Que faire si le systeme parait tres lent et que SRM est installe ?

A: Il faut suspecter un processus 'root' car root ne possede aucune limite

en temps CPU et peut donc 'accaparer' toutes les ressources systeme.

Verifier aussi qu'il n'y ait pas un user qui "domine" le temps

cpu avec la commande suivante:

# srmstat -Rac

Cette commande donne un resultat sous forme texte de l'usage cpu du type:

User/group No. Proc %Cpu Mon Sep 25 15:57:28 2000

System 5 34 0.0 ==================================================|

daemon 1 1 0.0 I !|

srmother 2 0.0 I |

toto 1 6 0.0 ! I |

srmidle 1 100.0 ##################################################|

Q: Comment lister tous les lnodes d'un serveur sous SRM ?

A: avec la commande limreport:

** TODO **

# limreport flag.real

ou avec la commande schedtree (non supportee, cf ci-dessus)

# /usr/srm/unsupport/schedtree

Q: Comment deplacer/backuper la base des lnodes SRM qui est sous /var/srm ?

A: Seule les commandes ufsdump/ufsrestore permettent de garder la structure

"a trou" de ce fichier. Les commandes telles que cp, tar et cpio copieront

les trous comme des sequences de 0.

D'autres part la base peut etre "dumpee" en ascii puis recree ailleurs avec

les commandes:

# limreport 'flag.real' - lname preserve > /var/tmp/savelnodes.ascii

puis recree avec:

# limadm set -f - < /var/tmp/savelnodes.ascii

Q: est-ce que la commande 'nice' (1) est utilisable sur un systeme sur

lequel SRM est configure ?

R: les interractions entre 'nice' et les processus sous la classe SHR

sont assez compliquees. 'nice' permet sous Solaris de reduire la priorite

d'un processus de facon a ce qu'un processus normal ne soit pas ralenti par

des processus non urgents. Sous SRM, la commande nice va diminuer

le decompte du cpu time utilise a une priorite inferieure.

Pour plus de details, voir "Relation ship to Other Resource control features"

dans l'answerbook.

Q: Comment empecher un processus lance en batch (crontab) de se lancer

en dehors de la plage horaire prevue ?

A: On peut avec SRM lancer des scripts qui ne pourrons s'executer

qu'a des heures specifiques avec limadm dans la crontab sur le lnode

'batch':

0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch

0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch

=> Le batch ne pourra pas se lancer a 6:00 a.m (pas de permission

pour se loguer), par contre il pourra a partir de 18:00.

Q: Comment se comporte SRM en cas de DR ?

A: Le scheduler SRM connait en permanence le nombre de CPUs disponibles y

compris en cas de DR, donc aucun impact (supporte).

Pas d'impact non plus sur les limites en taille memoire (SRM ne contrÃ´le

les limites que sur la memoire virtuelle).

Q: Quelles sont les limitations sur les processus attaches au 'root' lnode ?

A: Les processus attaches au 'root' lnode sont schedules d'une maniere

particuliere et pourront obtenir toutes les ressources CPU qu'ils demandent.

Le processus 'init' est attache au 'root' lnode. Tous les daemons systeme

seront donc attaches au 'root' lnode. Il faudra ajouter une commande

'srmuser' explicite dans les scripts de demarrage pour les attacher a un

autre lnode specifique.

ex:

/usr/srm/bin/srmuser network in.named

[..]

Q: Que se passe-t-il lorsqu'on utilise SRM avec les processor sets ?

A: A partir de Solaris 2.6, on peut utiliser les processeurs sets avec

lesquels on peut diviser le nombre de processeurs d'un serveurs en plusieurs

groupes de processeurs pour repartir la charge sur ces groupes.

L'interraction entre SRM et les processeurs set est un peu compliquee et

plus simple a comprendre sur un exemple avec 2 processeurs set sur un machine

bipro:

Processeurs set: A=cpu1 B=cpu2

user1 +------------+

10 shares | |

 +------------+

user2 +------------+

80 shares | |

| |

| |

| |

 +------------+

user3 +------------+

10 shares | |

 +------------+

Les users 1 et 3 ont 10 shares SRM ET sont limites au processeur set A (cpu1),

user 2 possede 80 shares SRM EY est limites au processeur set B (cpu2 soit

50% de la cpu totale du systeme).

Dans ce cas, user 2 utilisera le processeur set A complet (50% de la cpu

totale du systeme), car user 2 n'utilise que 50% de la cpu systeme plutot

que les 80 SRM. Les users 1 et 3 peuvent utiliser les 50% de cpu systeme

restant pour le processeur set A: ils utiliseront donc chacun 25% de la

cpu du systeme (mÃªme s'ils ont chacun des shares a 10).

En resume, attention a l'utilisation des processeurs set sous SRM, ne surtout

pas lancer des processus relatifs a un mÃªme user ayant un lnode et donc des

limites dans 2 processeurs set differents, dans ce cas certains processus

peuvent ne jamais avoir de cpu.

Pour plus d'infos sur les processeurs set, voir le man de psrset

ou le web http://trinity.eng/pset/

V/ Documentation & Liens

========================

5.1/ Articles

-------------

MODELLING THE BEHAVIOR OF SOLARIS RESOURCE MANAGER:

http://www.sun.com/software/solutions/blueprints/0899/solaris4.pdf

Par Engineering Entreprise - Aug 1999

SOLARIS RESOURCE MANAGER RESOURCE ASSIGNMENT:

http://www.sun.com/software/solutions/blueprints/0899/solaris5.pdf

Par Richard Mac Dougall - Aug 1999

SOLARIS RESOURCE MANAGER DECAY FACTORS AND PARAMETERS:

http://www.sun.com/software/solutions/blueprints/0499/solaris2.pdf

Par Richard Mac Dougall - Apr 1999

Solaris Resource ManagerTM 1.1 White Paper

Consolidate Servers and Increase Resource Utilization:

http://web.eng/solaris-enterprise/srm/wp-srm11/

5.2/ Links

----------

Senior Product Manager:

 Rajiv Parikh - Rajiv.Parikh@Eng.Sun.Com

Technical Marketing:

 Steve Houle - Steve.Houle@East

Solaris Product Group page:

 http://web.eng/solaris-enterprise/srm/

 http://web.eng/solaris-enterprise/srm/demo/

 (scripts de Demo qui utilisent SyMon)

Le site de Andrei dorofeev du CTE (andrei.dorofeev@eng):

 http://muskoka.eng/~andrei/SRM/

Site interessant EAST OS UNIX Page:

 http://osweb.east/unix/srm.html

Enterprise Resource Management, la page de Brian Wong.

 http://chessie.eng/srm/

La page SRM de Richard Mc Dougall:

 http://devnull.eng.sun.com/rmc/share.html

SRM OneStop site:

 http://onestop.eng/hw/srm.shtml

Page Editeur du soft (Softway):

 http://www.softway.com.au

5.3/ Livre

-----------

Resource Management - Sun Blueprints

 Richard Mc Dougall, Adrian Cockcroft, Evert Hoogendoorn, Enrique Vargas

 Tom Bialaski

Bienvenue sur le site admin-sys

Installation SRM

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

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

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

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

5.3 Ajout d'un user dans un sgroup

5.4 Attribution des parts à un lnode ou un sgroup

cpu.shares

Process.limit

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

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