Nous continuons d'étudier les groupes de contrôle (Cgroups) dans Red Hat Enterprise Linux 7. Prenons soin de la mémoire.
Vous vous souvenez qu'il y a deux ajustements à l'allocation du temps processeur: CPUShares pour définir les partages relatifs et CPUQuota afin de limiter l'utilisateur, le service ou la machine virtuelle (VM) en valeurs absolues (pourcentage) du temps processeur. De plus, ces deux réglages peuvent être utilisés simultanément. Par exemple, si un utilisateur a un quota CPU de 50%, sa boule CPU sera également prise en compte jusqu'à ce qu'il sélectionne complètement son quota à 50% du temps processeur.
Quant à la RAM, systemd n'offre qu'une seule façon de régler, à savoir ...
Quantité de mémoire pouvant être allouée à un utilisateur ou à un service. Supposons que nous voulions limiter l'utilisateur mrichter à 200 Mo de RAM. Si vous vous souvenez, son UID est 1000, nous entrons donc la commande suivante:
systemctl set-property user-1000.slice MemoryLimit = 200M
Maintenant, mrichter veut vérifier ses limites et lance l'utilitaire de test de stress stress, qui commence à consommer intensément la mémoire. Et le stress produit très rapidement une erreur:
Selon le journal système, le stress a été simplement interrompu par OOM (Out Of Memory) Killer.
Ici, il est important de faire attention à cela: par défaut, la limite de RAM ne s'applique qu'à la mémoire résidente. Autrement dit, si le processus peut aller dans le fichier d'échange («échange»), il contournera la limite établie. Dans notre exemple, le stress s'est écrasé car il dépassait la limite de mémoire résidente.
Et si nous ne voulons pas que le programme fusionne en un échange?
Ceci, en général, est facile à interdire. Eh bien, ou relativement facile ... En général, il faut grimper quelque part.
Il existe des paramètres de groupe de contrôle qui ne sont pas accessibles via la commande systemctl ou via les fichiers d'unité. Cependant, ces paramètres peuvent être modifiés à la volée dans les fichiers du dossier / sys / fs / cgroup /. Voici à quoi ressemble, par exemple, crich de l'utilisateur mrichter en mémoire:
Le fichier responsable de la quantité de mémoire pouvant aller dans le swap est évidemment appelé memory.swappiness. Voyons ce qu'il y a dedans:
S'il vous arrive de jouer avec les paramètres du noyau et le sous-système swap, vous verrez immédiatement la valeur par défaut standard pour le paramètre swappiness ici. Si vous le changez à zéro, le contrôleur RAM de l'utilisateur mrichter lui interdit généralement d'utiliser un swap.
Au fait, ici, vous pouvez consulter les statistiques de mémoire de l'utilisateur mrichter:
La valeur du paramètre hierarchical_memory_limit est le même MemoryLimit que nous avons spécifié avec la commande systemctl. Le paramètre hierarchical_memsw_limit représente la limite totale (mémoire résidente et mémoire dans le fichier du fichier). Nous avons empêché l'utilisateur mrichter d'utiliser le fichier d'échange, donc la valeur de ce paramètre est tellement bizarre.
Passons maintenant aux problèmes de l'approche qui vient d'être décrite:
- Vous ne pouvez apporter des modifications à ces fichiers que lorsque l'utilisateur mrichter s'est connecté au système. Jusqu'à ce qu'il se connecte, son groupe de contrôle sera inactif.
- Ces paramètres ne sont pas enregistrés après un redémarrage. De plus, ils seront perdus si le mrichter se déplace.
Le script pam_exec aidera à faire face à ces problèmes (voir
access.redhat.com/solutions/46199 pour plus de détails ).
Voici le script que nous allons créer dans le dossier / usr / local / bin:
Et puis ajoutez son appel à la dernière ligne de /etc/pam.d/sshd. Par conséquent, ce script sera exécuté à chaque fois qu'un utilisateur se connecte via ssh. C'est pourquoi nous vérifions dans le script qu'il s'agit bien de l'utilisateur mrichter, avant de modifier les paramètres.
Nous avons donc coupé l'utilisateur mrichter du fichier d'échange.
Bien sûr, vous pouvez aller encore plus loin et modifier les fichiers de configuration du groupe de contrôle actif à la volée, mais pour l'instant nous allons reporter cette entreprise risquée. Cependant, la méthode générale de modification des paramètres utilisateur est quelque chose que vous avez détecté.
Et avec les services, c'est encore plus simple. Dans le fichier d'unité de service, vous pouvez utiliser la directive ExecStartPost = pour exécuter un script qui modifie les paramètres. Par exemple, voici comment modifier le fichier d'unité de service foo pour désactiver l'échange:
Exécutez foo - et pas d'échange:
Eh bien, pour aujourd'hui, peut-être, ce chamanisme nous suffit.
Mais avant de terminer, nous allons nous attarder sur la documentation de cgroup, où vous pouvez trouver des informations sur tous ces paramètres de régulateur cachés. Vous pouvez installer le paquetage kernel-doc sur votre ordinateur, comme je l'ai fait en le téléchargeant depuis le dépôt rhel-7-server-rpms.
Après l'installation, ouvrez le dossier / usr / share / docs qui correspond à votre noyau et accédez au dossier cgroups, qui contient les dernières informations sur tous les régulateurs.
La prochaine fois, nous parlerons d'E / S. Et en passant, nous avons presque découvert comment les cgroups ont conduit à l'émergence de conteneurs (en fait, les cgroups sont un composant clé des conteneurs dans Red Hat Enterprise Linux et Red Hat OpenShift Container Platform).