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 sur Linux. La valeur par défaut (CFQ) donne fondamentalement une quantité égale de tranches de temps à chaque processus souhaitant s'exécuter et met en file d'attente les tâches exécutables de telle manière que tout le monde attend en moyenne un temps égal pour son tour. Il existe quelques exceptions à cette règle, 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 placez les tâches exécutables en file d'attente dans un schéma de mise en file d'attente équitable, le processus en temps réel obtiendra le temps CPU dès qu'il sera nécessaire par le processus, cela expulsera 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 prendre?
Ce que la «priorité» fait est de modifier la gentillesse du processus de sorte que lors de la connexion, votre processus principal commence à une certaine gentillesse, tous les processus enfants que vous générez commencent également à la même gentillesse.
Cela a pour effet de le rendre plus susceptible d'être programmé 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é plus faible que les démons réparables par exemple, ou que root ait une priorité de connexion plus élevée que tout le reste.
Quant au temps réel, le conflit est géré 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.
La définition de ce paramètre dans le fichier limits.conf permet de définir les tâches en temps réel sur une bande de priorité particulière sans avoir besoin de root pour définir la valeur. Cela n'a aucun effet sur les tâches non 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 ne l'ai jamais essayé cependant. Il définit le processus initial engendré lorsque PAM définit ces limites à ce joli vaule, un utilisateur normal peut ensuite atteindre 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 belle valeur définie dans le formulaire limits.conf du processus parent qui a été initialement créé.
Quels sont les défauts?
Les limites `` par défaut '' - techniquement, elles sont toutes définies sur ce qu'est le pid 1, sauf si elles sont définies explicitement, 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 initest 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 l'espace pour les globaux, peut-être d'autres données et mémoire initialisées allouées à 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 () sur-utilise 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 comme avec cet utilisateur.
memlock
maximum locked-in-memory address space (KB)
Presque toute la mémoire acquise par une application est «évictible». C'est peut être échangé. La mémoire verrouillée en mémoire n'est jamais échangeable et reste résidente. Cette valeur est strictement contrôlée car elle peut être utilisée abusivement par les gens 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 de swap).
cpu
maximum CPU time (minutes)
Cela représente le temps total qu'un processus peut consommer sur un processeur. Un processus qui dépasse cette valeur est tué. Notez que ce n'est PAS la même chose que le temps qui s'est écoulé depuis le démarrage du processus. IE une limite de cputime de 1 minute prendrait 1 minute à consommer si le processus avait une utilisation de 100% cpu, mais 2 minutes à consommer si le processus utilisait 50% d'utilisation.
Que se passe-t-il lorsque le processeur est dépassé?
Le processus reçoit un signal d' SIGXCPUarrêt qui met fin au processus. Cela peut ensuite être intercepté par le processus parent et y être géré.
Un seul processus ou l'ensemble de l'utilisateur est bagué à l'aide de la CPU?
Presque toutes les limites référencées sont traitées par processus. Temps CPU inclus. Les seuls qui ne le sont pas, je crois, sont le nombre total de connexions et le nombre total de processus par cet utilisateur.
Certains autres gotches avec des limites sont:
- Le nombre maximal de processus inclut le nombre de threads légers.
- La limite RSS ne fait rien et n'a pas depuis un certain nombre d'années, son inutile de fixer.