Concepts de base sur les contrôles de ressources

Dans le système d'exploitation Solaris, le concept de limitation de ressources par processus a été étendu aux entités tâche et projet décrites au Chapitre 2Projets et tâches (présentation). Ces améliorations sont liées à l'utilitaire de contrôle des ressources (rctls). De plus, les allocations définies par le biais des paramètres réglables /etc/system sont désormais automatiques ou configurées également via le mécanisme de contrôle des ressources.

Un contrôle de ressource est identifié par le préfixe zone, project, task ou process. Les contrôles de ressources peuvent être observés à l'échelle d'un système. Il est possible de mettre à jour les valeurs des contrôles de ressources sur un système en cours d'exécution.

Pour afficher la liste des contrôles de ressources standard disponibles dans cette version, reportez-vous à la section Contrôles de ressources disponibles. Pour plus d'informations sur les contrôles de ressources disponibles à l'échelle d'une zone, reportez-vous à la section Propriétés des types de ressources.

Pour connaître les contrôles de ressources standard disponibles dans cette version, reportez-vous à la section Contrôles de ressources disponibles.

Limites d'utilisation des ressources et contrôles de ressources

Les systèmes UNIX proposent, par tradition, un utilitaire de limitation des ressources (rlimit). L'utilitaire rlimit permet aux administrateurs de prévoir une ou plusieurs limites numériques quant à l'utilisation des ressources mises à la disposition d'un processus. Ces limites concernent aussi bien le temps CPU par processus que la taille du fichier Core par processus et la taille du tas maximum par processus. La taille du tas correspond à la quantité de mémoire de travail allouée au segment de données du processus.

L'utilitaire de contrôle des ressources fournit des interfaces de compatibilité à l'utilitaire de limitation des ressources. Les applications existantes auxquelles des contraintes d'utilisation des ressources ont déjà été appliquées continuent de fonctionner normalement. Ces applications peuvent être observées de la même manière que les applications modifiées dans le but de tirer parti de l'utilitaire de contrôle des ressources.

Communication interprocessus et contrôles de ressources

Les processus peuvent communiquer entre eux en utilisant l'un des différents types de communication interprocessus (IPC). Le protocole de communication interprocessus (IPC) assure le transfert ou la synchronisation des informations entre les processus. Avant la version Solaris 10, les paramètres réglables IPC étaient définis en ajoutant une entrée au fichier /etc/system. L'utilitaire de contrôle des ressources propose désormais des contrôles de ressources qui régissent le comportement des utilitaires IPC du noyau. Ces contrôles de ressources remplacent les paramètres réglables /etc/system.

Des paramètres obsolètes peuvent être inclus dans le fichier /etc/system sur ce système Solaris. Dans ce cas, ces paramètres sont utilisés pour initialiser les valeurs par défaut de contrôle de ressource comme dans les versions précédentes de Solaris. Toutefois, l'utilisation des paramètres obsolètes est déconseillée.

Pour identifier les objets IPC qui participent au projet, exécutez la commande ipcs avec l'option -J. Pour obtenir un exemple, reportez-vous à la section Mode d'utilisation d'ipcs Pour plus d'informations au sujet de la commande ipcs, voir la page de manuel ipcs(1).

Pour plus d'informations sur le réglage du système Solaris, reportez-vous au Oracle Solaris Tunable Parameters Reference Manual.

Mécanismes de contrainte par contrôle des ressources

Les contrôles de ressources offrent un mécanisme de contrainte des ressources système. Vous pouvez empêcher les processus, les tâches, les projets et les zones d'utiliser une quantité donnée des ressources système spécifiées. Ce mécanisme permet de gérer plus efficacement le système en empêchant une surexploitation des ressources.

Les mécanismes de contrainte peuvent servir à gérer les processus à planification de la capacité. La contrainte rencontrée peut fournir des indications sur les besoins en ressource de l'application sans refuser nécessairement la ressource à l'application.

Mécanismes d'attribut d'un projet

Les contrôles de ressources peuvent également faire office de simple mécanisme d'attribut pour les utilitaires de gestion des ressources. Par exemple, le nombre de parts de CPU mises à la disposition d'un projet dans la classe de programmation de l'ordonnanceur FSS est défini par le contrôle de ressource project.cpu-shares. Étant donné qu'un nombre fixe de parts est attribué au projet par le contrôle, les diverses actions qui entrent en jeu en cas de dépassement d'un contrôle ne sont pas applicables. Dans ce contexte, la valeur actuelle du contrôle project.cpu-shares est considérée comme un attribut pour le projet spécifié.

Un autre type d'attribut de projet est utilisé pour réglementer la façon dont les ensembles de processus associés à un projet utilisent la mémoire physique. Ces attributs sont reconnaissables à leur préfixe rcap : rcap.max-rss , par exemple. Comme pour un contrôle de ressource, ce type d'attribut est configuré dans la base de données project. Cependant, à la différence des contrôles de ressources qui sont synchronisés par le noyau, les limitations des ressources sont appliquées de façon asynchrone au niveau utilisateur par le démon d'allocation restrictive rcapd . Pour plus d'informations sur la commande rcapd, reportez-vous au Chapitre 10Contrôle de la mémoire physique à l'aide du démon d'allocation restrictive (présentation) et à la page de manuel rcapd (1M).

L'attribut project.pool sert à spécifier une liaison de pool pour un projet. Pour plus d'informations sur les pools de ressources, reportez-vous au Chapitre 12Pools de ressources (présentation).