Si vous avez plusieurs utilisateurs sur votre système, la possibilité de limiter leur utilisation du système peut venir à l'esprit. FreeBSD fournit plusieurs méthodes à l'administrateur système pour limiter la quantité de ressources système qu'un utilisateur peut utiliser. Ces limites sont généralement divisées en deux parties: les quotas disque, et les autres limites de ressource.
Les quotas limitent l'utilisation des disques par les utilisateurs, et ils fournissent un moyen de vérifier rapidement cette utilisation sans avoir à faire des calculs à chaque fois. Les quotas sont abordés dans la Section 18.15.
Les autres limites de ressource comprennent les moyens de limiter l'utilisation du CPU, de la mémoire, et les autres ressources qu'un utilisateur peut consommer. Elles sont définies en employant des classes de session et sont abordées ici.
Les classes de session sont définies dans /etc/login.conf. La sémantique précise sort du cadre de cette section, mais est décrite en détail dans la page de manuel login.conf(5). Il est suffisant de dire que chaque utilisateur est assigné à une classe (default par défaut), et que chaque classe dispose d'un ensemble de capacités associées. La forme utilisée pour ces capacités est une paire nom=valeur où nom est un identifiant connu et valeur est une chaîne arbitraire dépendante du nom. Paramétrer des classes et des capacités est plutôt direct et également décrit dans login.conf(5).
Note : Le système ne lit normalement pas directement le fichier /etc/login.conf, mais plutôt la base de données /etc/login.conf.db qui fournit plus rapidement les réponses au système. Pour générer /etc/login.conf.db à partir du fichier /etc/login.conf, exécutez la commande suivante:
# cap_mkdb /etc/login.conf
Les limites de ressource sont différentes des capacités standards des classes en deux points. Premièrement, pour chaque limite, il existe une limite douce (actuelle) et limite dure. Une limite douce peut être ajustée par l'utilisateur ou une application, mais jamais dépasser la limite dure. Cette dernière peut être abaissée par l'utilisateur, mais jamais augmentée. Deuxièmement, la plupart des limites de ressource s'applique par processus à un utilisateur spécifique, et non pas à l'utilisateur dans sa totalité. Notez, cependant, que ces différences sont exigées par la manipulation spécifique des limites, et non pas par l'implémentation du système des capacités des classes de session utilisateur (i.e., elles ne sont vraiment pas un cas particulier des capacités des classes de session).
Sans plus attendre, ci-dessous sont présentées les limites de ressource les plus souvent utilisées (le reste, avec les autres capacités des classes de session, peut être trouvé dans login.conf(5)).
La limite sur la taille du fichier core généré par un programme est, pour d'évidentes raisons, subordonnée aux autres limites sur l'utilisation du disque (e.g., filesize, ou les quotas de disque). Néanmoins, elle est souvent employée comme méthode moins sévère pour contrôler la consommation d'espace disque: puisque les utilisateurs ne génèrent pas de fichier core eux-mêmes, et souvent ne les suppriment pas, paramétrer cela peut leur éviter de manquer d'espace disque si un programme important (e.g., emacs) plante.
C'est la quantité maximale de temps CPU qu'un processus d'un utilisateur peut consommer. Les processus la dépassant seront tués par le noyau.
Note : C'est une limite sur le temps CPU consommé, non sur le pourcentage comme affiché par certains champs de top(1) et ps(1). Une limite sur ce dernier est, au moment de l'écriture de ces lignes, impossible, et serait plutôt inutile: un compilateur—probablement une tâche légitime—peut aisément utiliser presque 100% du CPU pendant un certain temps.
C'est la taille maximale du plus gros fichier qu'un utilisateur peut posséder. Contrairement aux quotas, cette limite ne s'applique qu'aux fichiers individuellement, et non pas sur l'ensemble lui-même de tous les fichiers que possède un utilisateur.
C'est le nombre maximal de processus que peut exécuter un utilisateur en même
temps. Ceci inclut les processus de premier plan et de tâche de fond. Pour
d'évidentes raisons, il ne doit pas être plus grand que les limites du système
spécifiées par la variable sysctl(8) kern.maxproc. Notez en outre qu'une valeur trop basse peut
gêner la productivité de l'utilisateur: il est souvent utile d'ouvrir plusieurs
sessions à la fois ou d'exécuter des opérations sous forme de
“pipeline”. Certaines tâches, comme compiler un gros programme,
engendrent également de multiples processus (e.g., make(1), cc(1), et autres
préprocesseurs).
C'est la quantité maximale de mémoire qu'un processus peut avoir demandé de verrouiller en mémoire principale (e.g., voir mlock(2)). Certains programmes système critiques, comme amd(8), sont verrouillés en mémoire principale de sorte qu'en cas de dépassement de la mémoire de pagination, ils ne contribuent pas aux ennuis du système.
C'est la quantité maximale de mémoire qu'un processus peut consommer à un instant donné. Cela inclus la mémoire principale et celle de pagination. Ce n'est pas le remède miracle pour restreindre la consommation de mémoire, mais c'est un bon début.
C'est le nombre maximal de fichiers qu'un processus peut avoir ouvert. Sous
FreeBSD, des fichiers sont également employés pour représenter les sockets et
les canaux IPC, par conséquent faites attention à ne fixer une valeur trop basse.
La limite générale du système pour cela est définie par la variable sysctl(8) kern.maxfiles.
C'est une limite sur la quantité de mémoire réseau, et donc de “mbufs”, qu'un utilisateur peut consommer. Ceci est à l'origine une réponse à une vielle attaque par refus de service en créant de nombreuses sockets, mais peut être généralement employée pour limiter les communications réseau.
C'est la taille maximale de la pile d'un processus. Seule, cela n'est pas suffisant pour limiter la quantité de mémoire que peut utiliser un programme, par conséquent, cette limite devra être utilisée en même temps que d'autres limitations.
Il y a quelques éléments à se rappeler quand on fixe des limites de ressource. Quelques astuces générales, suggestions, et commentaires divers:
Les processus lancés au démarrage du système par /etc/rc sont assignés à la classe daemon.
Bien que le fichier /etc/login.conf qui est fourni avec le système est une bonne source de valeurs raisonnables pour la plupart des limites, seul vous, l'administrateur, peut savoir ce qui est approprié à votre système. Fixer une limite trop haute peut laisser la porte ouverte aux abus, alors qu'une limite trop basse peut être un frein à la productivité.
Les utilisateurs du système X Window (X11) devraient se voir allouer plus de ressources que les autres utilisateurs. X11 par lui-même utilise beaucoup de ressources, mais il encourage également les utilisateurs à exécuter plus de programmes simultanément.
Souvenez-vous que de nombreuses limites ne s'appliquent qu'aux processus
individuels, et non pas à l'utilisateur globalement. Par exemple, paramétrer
openfiles à 50 signifie que chaque processus que
l'utilisateur exécute pourra ouvrir jusqu'à 50 fichiers. Ainsi, la quantité totale
de fichiers qu'un utilisateur peut ouvrir est la valeur openfiles multipliée par la valeur maxproc.
Ceci s'applique également à la consommation de mémoire.
Pour de plus amples informations sur les limites et les classes de session et les capacités en général, veuillez consulter les pages de manuel appropriées: cap_mkdb(1), getrlimit(2), login.conf(5).
| Précédent | Sommaire | Suivant |
| Modifier des comptes | Niveau supérieur | Groupes |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.