Bonjour,
J’utilise aide sur mes systèmes.
Le problème pour certain, c’est que celui-ci est très consommateur de CPU (90% de moyen avec des pics de plusieurs secondes à 100%).
J’ai vu qu’avec les cgroup on peut faire en sorte de limiter la consommation d’un service ou d’un process.
Mais c’est assez mal documenté et pas simple à mettre en place.
Y-a-t-il quelqu’un qui s’est frotté au sujet?
Tu peux essayer taskset qui colle un processus à un ou plusieurs cœurs.
Non cette solution est insuffisante et n’empêche pas réellement la nuisance.
Qui plus est cette commande ne semble pas pouvoir être paramétrée au niveau du système, mais à la volée.
Je n’ai ps envie d’avoir à lancer des commande à chaque lancement de aide.
Je ne veux pas non plus bidouiller les processus de lancement standards qui seront de toute façon écrasés à la prochaine mise à jour.
Je veux que aide ne puisse jamais dépasser un certain pourcentage d’utilisation d’un cœur de processeur, quelque soit ce cœur.
cgroup-tools semble le faire correctement, mais je n’ai pas réussi à faire la configuration. La documentation est très peu didactique.
cpulimit : limiter l’utilisation de l’ordi
sudo apt-get install cpulimit
limiter l’utilisation de l’ordi par un programme
il faut d’abord récupérer le PID
si on connaît le nom du programme, par exemple ici blender4 : ps -C blender4 -o pid=
on obitent un nombre (ou plusieurs ) : 771928
un ordinateur contient plusieurs "coeurs" , chacun compte pour 100% ainsi 8 coeurs = 800%.
exemple : on autorise la moitié de la puissance de l’ordi à 8 coeurs pour blender4 , soit 400% : cpulimit -l 400 -p 771928
(d’après Comment limiter l'utilisation du processeur d'un processus sous Linux)
cputool : limiter l’utilisation de l’ordi
sudo apt-get install cpuset
attention , cputool marche avec 1024 = 100%
limiter l’utilisation du processeur d’un processus portant l’ID 1234 à 50 % : sudo cpuset -p 1234 -u 512
allouer uniquement les cœurs de processeur 0 et 1 au processus portant l’ID 1234 : sudo cpuset -p 1234 -l 0,1
regroupement de processus :
créer un groupe : sudo mkdir /sys/fs/cgroup/cpuset/mycpuset
déplacer les processus dans le cpuset : echo 1234 | sudo tee /sys/fs/cgroup/cpuset/mycpuset/tasks
limiter l’utilisation du processeur du cpuset "mycpuset" à 20% : echo 20 | sudo tee /sys/fs/cgroup/cpuset/mycpuset/cpu.shares
( d’après CPUTool - Limiter et contrôler l'utilisation du processeur de n'importe quel processus sous Linux )
J’ai vu aussi, masi pareil, c’est à faire manuellement à chaque fois il me semble. Ou pour être plus exact, il faut que le processus soit déjà lancé.
Ce que je veux c’est pouvoir automatiquement limiter le CPU d’une application.
si tu utiliser systemd, il existe quelques options
https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html
d’après man cpulimit
cpulimit -l 25 – firefox -private
Launch Firefox web browser in private mode and limit its CPU usage to 25%
Sauf qu eje ne veux pas avoir à le faire par lancement manuel.
Aide est en service automatique au démarrage et se déclenche vie dailyaidecheck. Donc je veux intégrer cette limitation du cpu au système lui même; de façon que la limitation soit activée dès que aide est lancé quelque soit la façon dont il est exécuté.
Ca semble possible avec cgroup, mais soit j’ai un groupe mais pas les paramètres soit j’ai les paramètres mais impossible de mettre en place le groupe.
Et les how to éventuels sont trop peu documentés (voir inexact dans certains cas)
je ne connais ni dailyaidecheck ni aide, mais ne pourrais-tu pas simplement remplacer
-* dans dailyaidecheck le lancement de /usb/bin/aide par le lancement de /opt/aide.sh qui contient cpulimit -l 25 – aide ?
je viens de regarder ça paraît compliqué :;
pourquoi pas écrire déplacer /usr/bin/aide dans /opt/usr_bin/ et écrire dans /usr/bin/aide
#!/bin/bash
cpulimit -l 25 – /opt/usr_bin/aide
Tu vas me trouver chiant 
Mais bon, je ne bidouille pas. Car ce type de solution n’est pas maintenable ne serait-ce qu’à court ou moyen terme.
La première mise à jour venu écrasera ce que j’ai fait.
Et en plus, ce n’est pas propre.
Déjà déplacer /us/bin/aide dans /opt/usr_bin c’est du bricolage.
Je préfère trouver le moyen d’utiliser les fonctionnalités qui existe mais que pour une raison que je ne maîtrise pas, je n’arrive pas à faire.
Tous les système que je met en place utilise des fonctionnalités qui sont prévues pour ça.
Si je doit faire évoluer mon pot d’échappement je prend un pot qui est conçu pour la voiture et pour la fonctionnalité prévue et fixée avec les fixations prévues pour lui.
Pas de fil de fer, de bout de ficelle ou de scotch 
D’autant qu’avec ce genre de solution, quelques mois plus tard on ne s’en souvient plus et on se retrouve avec des problèmes XY dans tous les coins.
En plus, j’utilise aide sur tous mes systèmes.
je trouve aussi
cette page a l’air intéressante : Limit CPU with cgroups & slice in Linux [100% Working] | GoLinuxCloud
Tu peux essayer cela si tu ne l’a pas déjà fait : Limitation via systemd en configurant le service aidecheck.service
Si aide est lancé par dailyaidecheck.timer , alors ce *.timer appelle probablement un service dailyaidecheck.service . C’est ce service qu’il faut configurer avec une unité override .
Pour vérifier le service exact
systemctl list-timers | grep aide
Ensuite créer un drop-in avec la limitation CPU
sudo systemctl edit dailyaidecheck.service
Ajoute ceci
[Service]
CPUQuota=20%
De même que tu peux aussi fixer un nombre de CPU avec AllowedCPUs=0,1 par exemple, si tu veux restreindre à certains cœurs.
Faire ensuite un reload et un teste sans attendre le prochain timer qui te permettra de suivre l’utilisation du CPU
Autre question : est-ce à appliquer à tous les processus aide , même hors service ?
Vu que j’ai peu de chances de trouver de quoi il s’agit sur un moteur de recherche (vu la généralité du mot-clé) : juste par curiosité, c’est quoi aide ?
Qu’est-èce que tu entends par hors service? si aide ne s’exécute pas, il n’est pas impliqué. L’idée c’est de limiter sa consommation CPU dès qu’il y a un processus aide lancé, quoi qu’il fasse.
Advanced Intrusion Detection Environment (AIDE)
Je n’avais pas eu le temps de l’appliquer mais effectivement j’avais trouvé une page sur le sujet. Merci.
J’ai mis en place, et ça marche avec une précision de 2 à 5% près mais c’est suffisant pour mon besoin. Le CPU reste compris entre 49 et 52.
Aide utilise un seul coeur à chaque fois, mais non déterministe. Donc pour le moment je n’utilise pas le positionnement du cœur.
Qu’est-èce que tu entends par hors service? si aide ne s’exécute pas, il n’est pas impliqué. L’idée c’est de limiter sa consommation CPU dès qu’il y a un processus aide lancé, quoi qu’il fasse.
Si AIDE est exécuté en dehors d’un service systemd — par exemple, lancé manuellement depuis un terminal ou via un script indépendant de systemd — alors les limitations définies dans dailyaidecheck.service ne s’appliqueront pas** . Ces réglages (comme CPUQuota= ou AllowedCPUs= ) ne s’appliquent qu’au processus AIDE lancé via ce service spécifique .
Deux cas possibles :
dailyaidecheck.service )Les limitations définies dans l’unité ou le drop-in (comme CPUQuota=20% ) s’appliqueront uniquement dans ce contexte.
Ces processus ne seront pas couverts par les réglages systemd à moins d’encapsuler également ces lancements dans un service systemd dédié avec ses propres limitations.
En d’autres termes ont peut limiter tous les processus AIDE quel que soit leur mode de lancement. Pour cela il faut Utiliser cpulimit dans un script wrapper
Ou encore créer une unité systemd générique qui encapsule tous les appels à AIDE avec des limitations.
Ou encore, appliquer une limitation via systemd en créant un slice
Si AIDE est uniquement lancé via le service dailyaidecheck.service , alors l’ajout de CPUQuota dans son unité suffit. Mais si AIDE est susceptible d’être lancé par d’autres moyens, il faudra envisager une approche plus globale pour contrôler sa consommation CPU.
Bien entendu il s’agit là de « directive » standard donc « propre ». Rien n’est cassé, et c’est réversible si tu souhaites faire un « slice » ou créer un override avec systemctl edit
oups !
Non, je n’utilise pas de bidouille donc exit cron, ou script. Pas avec aide.
Le seul truc concernant aide qui pou_rrait faire l’objet d’un cron ou d’un script c’est le reporting, qui n’a pas besoin de lancer le process aide.
Oui mais pas propre au regard de l’utilisation de cgroup
Oui, tu as raison
cpulimitfonctionne bien pour des cas simples ou ponctuels, mais il ne s’intègre pas proprement dans la logique de gestion des ressources via les cgroups, surtout dans un système géré par systemd.
Avec systemd, c’est plus propre de définir des limites dans l’unité du service tout se passant par les cgroups V2. On garde ainsi une gestion centralisée, traçable et maintenable.
Disons quecpulimitpeut quand même dépanner sur des scripts ou des contextes où on n’a pas la main sur systemd. Mais cela reste moins « propre »
Et pour corroborer ton « commentaire » : cpulimit agit en user-space sur un PID, alors que systemd gère en kernel-space via cgroups — plus propre et plus robuste, surtout pour des services réguliers ou critiques.
