rtprio
maximum realtime priority allowed for non-privileged processes (Linux 2.6.12 and higher)
priority
the priority to run user process with (negative values boost process priority)
Pourquoi sont-ils différents ?
Il existe différentes classes d'ordonnanceurs de processus sous Linux. Celui par défaut (CFQ) donne essentiellement un nombre égal de tranches de temps à chaque processus souhaitant s'exécuter et met en file d'attente les tâches exécutables de manière à ce que tout le monde attende en moyenne un temps égal pour son tour. Certaines exceptions à cette règle existent mais c'est l'idée de base.
Une autre classe de planificateur est le planificateur en temps réel. Le temps réel est un peu différent, plutôt mettre en file d'attente les tâches exécutables dans un schéma de mise en file d'attente équitable, le processus en temps réel obtiendra du temps CPU dès qu'il en aura besoin par le processus, cela expulse un processus en cours d'exécution du CPU afin de faire de la place pour le ' temps réel ' processus.
Quelles valeurs peuvent-ils adopter ?
Ce que la "priorité" fait, c'est modifier la gentillesse du processus afin que, lors de la connexion, votre processus principal démarre à une certaine gentillesse, tous les processus enfants que vous générez démarrent également à la même gentillesse.
Cela a pour effet de le rendre plus susceptible d'être planifié en faveur d'autres processus concurrents et l'expérience utilisateur peut être rendue plus réactive/interactive pour les valeurs de gentillesse inférieures et moins réactive/interactive si la gentillesse est augmentée.
Il peut être important que les utilisateurs de connexion normaux aient une priorité inférieure à celle des démons réparables par exemple, ou que root ait une priorité plus élevée lors de la connexion que tout le reste.
Comme pour le temps réel, les conflits sont gérés avec le champ 'rtprio'. Si vous avez deux tâches en temps réel à exécuter, la valeur 'rtprio' est utilisée pour déterminer lequel des processus choisir en priorité. Un rtprio plus élevé produit des tâches de priorité plus élevée.
Définir ceci dans le fichier limits.conf permet aux tâches en temps réel d'être définies sur une tranche de priorité particulière sans avoir besoin de root pour définir la valeur. Cela n'a aucun effet sur les tâches qui ne sont pas configurées pour s'exécuter à l'aide d'un planificateur en temps réel.
La valeur 'nice' devrait faire la même chose que 'rtprio' mais pour la programmation CFQ standard. Je n'ai jamais essayé cependant. Il définit le processus initial généré lorsque PAM définit ces limites sur cette valeur agréable, un utilisateur normal peut alors accéder à ce niveau agréable ou supérieur sans avoir besoin de root pour les définir. Si vous ne reniez pas explicitement, cela signifie que tous les processus générés à partir d'un shell à partir de cette connexion (par exemple) hériteront de la valeur nice définie dans le fichier limits.conf du processus parent initialement créé.
Quelles sont les valeurs par défaut ?
Les limites "par défaut" - techniquement, sont-elles toutes définies sur le pid 1 à moins qu'elles ne soient explicitement définies, les limites de ressources sont héritées du processus parent, si aucune limite n'a été définie ou remplacée nulle part, l'héritage de init est la valeur par défaut.
Autres valeurs
data
maximum data size (KB)
Lorsqu'un processus est initialisé, il alloue de la mémoire connue sous le nom de 'segment de données' lorsque le processus est copié dans la mémoire, c'est là que vit l'espace pour les globals, peut-être d'autres données initialisées et la mémoire allouée à partir du tas. La limite contrôle le montant maximum alloué qu'un processus peut prendre.
Il est peu probable que vous atteigniez cette limite, car malloc() surutilise rarement le segment de données pour stocker des données.
fsize
maximum filesize (KB)
Cela définit littéralement la taille maximale dans laquelle un fichier peut être écrit avec cet utilisateur.
memlock
maximum locked-in-memory address space (KB)
Presque toute la mémoire qu'une application a acquise est « évitable ». Cela peut être échangé. La mémoire verrouillée en mémoire n'est jamais permutable et reste résidente. Cette valeur est strictement contrôlée car elle peut être utilisée abusivement par des personnes pour affamer un système de mémoire et provoquer des échanges. Il est généralement utile avec les applications de sécurité (qui ne veulent jamais que leurs pages soient échangées - et deviennent lisibles à partir de la partition d'échange).
cpu
maximum CPU time (minutes)
Cela représente le temps total qu'un processus peut consommer sur un CPU. Un processus qui dépasse cette valeur est tué. Notez que ce n'est PAS le même que le temps qui s'est écoulé depuis le démarrage du processus. processus utilisé 50 % d'utilisation.
Que se passe-t-il lorsque le processeur est dépassé ?
Le processus reçoit un signal d'arrêt SIGXCPU qui termine le processus. Cela peut ensuite être intercepté par le processus parent et y être traité.
Un seul processus ou l'ensemble de l'utilisateur est empêché d'utiliser le processeur ?
Presque toutes les limites référencées sont gérées par processus. Temps CPU inclus. Les seuls qui ne le sont pas je crois être le nombre total de connexions et le nombre total de processus par cet utilisateur.
Voici quelques autres problèmes avec des limites :
- Le nombre maximal de processus inclut le nombre de threads légers.
- La limite RSS ne fait rien et ne l'a pas fait depuis plusieurs années, il est inutile de la définir.