Introduction SRM
mardi 16 septembre 2008
par
popularité : 6%
par
popularité : 6%
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.
<pre>
+---------+
| root |
| CPU=100 |
+---------+
/ \
/ \
/ \
+---------------+ +---------------+
| wallace | | gromit |
| cpu.shares=50 | | cpu.shares=50 |
+---------------+ +---------------+
</pre>
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:
<pre>
+-------------- 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
</pre>
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
1001
# ./limid -p 409
1001
# grep test1 /etc/passwd
test1:x:1001:10::/tmp/test1:/bin/sh
<pre>
# ./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:
</pre>
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
</pre>
