Problèmes de performance

Processus reliés au noeud limite root

Aux fins de la gestion du système, les processus reliés au noeud limite root obtiennent pratiquement toutes les ressources d'UC demandées. Par conséquent, si un processus d'UC est relié au noeud root, il peut monopoliser et ralentir, voire même arrêter les processus des autres noeuds limites.

Pour éviter ce genre de problème, les précautions ci-après peuvent être prises :

• L'administrateur doit toujours ouvrir une session sur l'un des noeuds limites créés en vue d'une utilisation normale et non se relier au noeud root. S'il doit se relier au noeud root, il ne doit pas exécuter d'applications faisant usage intensif de l'UC, par exemple, des compilateurs. Pour se servir d'un UID de superutilisateur sans se relier au noeud root, l'administrateur peut utiliser la commande su(1).

• Les scripts init.d peuvent être changés pour utiliser le programme srmuser pour relier tous les démons à leurs propres noeuds limites, de façon qu'ils ne soient pas reliés (par héritage) au noeud limite root. Cependant, cette solution ne peut pas être recommandée sur une base générale. En effet, elle peut créer des problèmes, puisqu'elle suppose la modification d'un grand nombre de fichiers, et que la pratique peut interdire l'intégration ultérieure de patchs dans un système. Une solution n'imposant pas l'exécution manuelle de cette tâche est à l'étude.

  Pour les versions de Solaris Resource Manager versions supérieures à 1.0, les scripts sbin_rc2 et sbin_rc3 fournis dans le répertoire /usr/srm/unsupport peuvent être utilisés pour résoudre partiellement ce problème.

Un programme exécuté en tant que setuid-root n'est pas automatiquement relié au noeud limite. Normalement, le processus demeure relié au noeud limite du père qui l'a créé, et seul l'UID en cours est modifié.

Ressources d'unité centrale non contrôlées par Solaris Resource Manager

Solaris Resource Manager contrôle uniquement l'utilisation d'UC par les processus de la classe d'ordonnancement SHR. Si des demandes excessives d'une priorité supérieure sont faites par d'autres classes d'ordonnancement, spécialement les classes temps réel (RT) et système (SYS), SHR peut ordonnancer seulement avec les ressources restantes de l'UC.

L'utilisation de la classe RT génère un conflit avec les fonctions de gestion de système de Solaris Resource Manager. Les processus en temps réel obtiennent un accès complet au système afin qu'ils puissent transmettre des réponses en temps réel (habituellement de l'ordre de quelques centaines de microsecondes). Les processus exécutés dans la classe SHR ont par définition une priorité inférieure à celle de tout processus en temps réel, sur lesquels Solaris Resource Manager n'a aucun contrôle. Les processus en temps réel peuvent facilement consommer toutes les ressources disponibles, privant Solaris Resource Manager de ressources à attribuer aux autres processus.

Le serveur NFS est l'un des services exécuté exclusivement dans la classe SYS. Solaris Resource Manager ne peut pas contrôler les démons NFS, car ils sont exécutés dans SYS. La capacité de Solaris Resource Manager à attribuer des ressources de processeur peut être réduite sur les systèmes offrant un service NFS étendu.

Même si des processus exécutent du code de noyau (à l'intérieur d'un appel système), les règles de priorité de tranche de temps habituelles ne s'appliquent pas. La plupart des appels système exécuteront seulement une certaine partie de leurs tâches avant d'atteindre un point de préemption. Cependant, si le système subit une charge élevée d'appels système plus intensifs, cela peut causer une diminution de la réactivité globale, ce qui est hors de la portée de contrôle d'une classe d'ordonnancement.

Si le système manque de mémoire réelle, le goulot d'étranglement d'E/S résultant de l'accroissement du taux d'erreurs de page et des échanges de processus augmente la consommation des ressources de l'UC par le noyau. Des temps d'attente d'E/S importants peuvent indiquer des pertes de capacité d'UC. Encore une fois, cela est hors de la portée d'une classe d'ordonnancement.

La classe d'ordonnancement SHR est un ordonnanceur à temps partagé (TS) qui utilise la même gamme de priorité globale que les ordonnanceurs TS et interactif (IA). Il n'est pas recommandé de combiner l'utilisation de SHR avec TS et IA, sauf pour transférer tous les processus dans ou depuis la classe SHR. L'utilisation du système avec une combinaison de processus des classes SHR et TS diminuera la qualité de l'ordonnancement dans les deux classes. Pour cette raison, Solaris Resource Manager empêche les processus non root de se déplacer ou de déplacer d'autres processus vers les classes TS ou IA. La classe RT fait appel à une autre gamme de priorité et peut être utilisée avec la classe SHR de la même façon que les classes TS et IA.

Si des processus exécutés par le superutilisateur contiennent du code utilisant l'appel système priocntl(2) directement au lieu de la routine de bibliothèque setpriority (3C) pour ajuster les priorités des processus, ils peuvent transférer les processus cibles dans une autre classe d'ordonnancement (habituellement TS). Le code de la routine de bibliothèque setpriority tient compte du fait que l'interface priocntl avec SHR est binairement compatible avec celle de TS, et contourne ainsi le problème. L'option - c de ps( 1) ou l'option -d de priocntl(1) peut être utilisée pour afficher la classe d'ordonnancement des processus.

Le même problème se manifeste avec les processus de privilège de superutilisateur qui utilisent explicitement priocntl(2) pour gérer l'appartenance de classe d'ordonnancement des processus.