Journal Cpulimit : limiter l'utilisation CPU d'un processus

Posté par  (site web personnel) .
Étiquettes : aucune
0
26
juil.
2007
Un petit soft bien pratique, qui me sert par exemple quand je veux faire tourner de gros calculs sans avoir besoin de ventiler excessivement : avec Cpulimit, je peux limiter un processus pour qu'il n'utilise qu'une partie de la puissance disponible.

Par exemple, si ma tâche a le PID 6561, je tape cpulimit -p 6561 -l 35 et elle n'utilisera pas plus de 35% du CPU.

http://cpulimit.sourceforge.net/

  • # Ce peut même être user-friendly ( en ligne de commandes )

    Posté par  (site web personnel) . Évalué à 3.

    Comme dit dans la doc on peut même utiliser le nom du processus à limiter

    pour limiter le processus grosseboucle à 40 % d'utilisation du processeur on fait :
    cpulimit --exe grosseboucle --limit 40


    mais là où c'est moins user-friendly c'est en cas de plusieurs processeurs ( et j'imagine core ... ) il faut multiplier le taux par le nombre de processeurs car comme dit en anglais But if your machine has four processors percentage may vary from 0% to 400% et donc the limit to 200% means to use no more than half of the available power soit dans le cas de l'exemple avec grosseboucle le nombre 160 au lieu de 40 pour 4 processeurs ....

    \_o<

    • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Dans ce cas, il suffit de faire un wrapper, qui tient en compte la sortie de /proc/cpuinfo et basta...

      M'en vais tester ça dès que j'ai mon nouveau PC. Ça peut être très utile, surtout si on lance une compile longue en tâche de fond par exemple, mais qu'on veut pouvoir jouer correctement en même temps et que le temps de compilation n'est pas important.

    • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

      Posté par  . Évalué à 2.

      Euh, 160% c'est pas 1,6 processeur ? donc dans ce cas, ca fera du 40% sur chaque CPU seulement si ton application a un nombre de threads multiple de 4, et que par chance ils sont distribués de manière uniforme sur tes CPUs.

      Avec une appli monothreadée, ca utilisera simplement un CPU à 100%.

      Mais en fait, à part peut-être limiter l'émission de chaleur, je ne vois vraiment pas l'intérêt de contrôler l'utilisation de CPU en % ou d'utiliser cette valeur comme une mesure de n'importe quoi plus détaillée que 'le cpu bosse' et 'le cpu est idle', à part dans les traitements dépendant du temps... Vous avez pas de scheduler dans votre OS ?

      Et encore,je ne suis pas convaincu qu'il soit intéressant de faire "3 secondes à 33%" au lieu de "1 seconde à 100%" d'un point de vue chaleur dégagée.

      • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

        Posté par  (site web personnel) . Évalué à 6.

        100% => ventilation => bruit.
        Limitation => silence => bonheur.

        • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

          Posté par  . Évalué à 2.

          Entièrement d'accord.

          J'ai eu l'occasion il y a quelques jours d'utiliser cpulimit lors d'une compilation du noyau... et je dois avouer que c'est bien pratique lorsque l'on possède un petit boîtier (sous la télé) et que celui-ci n'est pas forcément bien ventilé !
          Sans cpulimit, la compilation aurait été impossible ! (ou avec le PC dans le frigo à la limite...)

          • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

            Posté par  (site web personnel) . Évalué à 2.

            Je n'y avais pas pensé mais pour limiter des jeux qui prennent 100 % du cpu pour rien, c'est parfait.

            Je viens de faire un essai avec Caesar III, qui fonctionnait correctement sur un 486DX33, tournant dans Virtual Box, c'est au poil :)

            Seul petit bémol, dans ce cas, il faut préciser le numéro du process et non son nom : Virtual Box en lance plusieurs.

            \_o<

        • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

          Posté par  . Évalué à 2.

          Une autre solution, c'est la prévention. Au cas ou un processus s'emballe. Ainsi même si ce processus devient incontrolable, il ne consomme pas plus que ce qu'on lui a attribué et laisse ainsi assez de temps cpu pour ne pas nuire à la qualité de service.

          exemple, j'administre plusieurs serveurs dédiés pour des jeux en réeaux. Sur le jeu TCE (mod d'ET), Punkbuster ne cherchait pas à mettre à jour son anti-cheat pour les cheats spécifique à TCE. On a du donc se démerdé. La plus part des cheat utilise des couleurs flashy pour afficher les viseurs et autres informations. Un joueur a donc faire rapidement un petit script php pour repérer ces zones de couleurs d'après les screens et en déduire automatiquement si un joueur cheat ou pas. Le script ne consomme rien quand le screen est clean. Mais lorsque que le screen provient d'un cheater, il s'emballe pour calculer les zones de couleurs, leurs grosseurs et le pourcentage de couverture du screen de ces zones. Au début, bonjour le lag lorsqu'il y avait un cheater. Mais un petit coup de cpulimit permet de ne pas nuire la qualité du serveur. On perdait juste 20sec avant que le message signalant le cheater ne s'affiche.

          • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

            Posté par  . Évalué à 3.

            mais dans ce cas précis, un coup de nice sur le script n'aurait pas donné un résultat au moins aussi bon ?

            • [^] # Re: Ce peut même être user-friendly ( en ligne de commandes )

              Posté par  . Évalué à 3.

              Oui, c'est vrai un nice aide à réduire le lag lorsqu'un proc veut 100% du cpu. Mais avec 5 serveurs de jeu à côté et 80 joueurs connecté, tu le sens quand même voir très bien.
              En gros, et d'après mon expérience, on peut jouer correctement avec un charge cpu de 50% mais tu sens déjà des ptits lags et malheureusement au moment les plus crucial (surtout sur TC:E) , 75% tu le sens tout le temps même si ça reste jouable, 100% ça devient injouable.
              Réduire avec cpulimit (on l'avais limité à 15% du cpu) permet de restais dans un conso raissonnable du cpu.

  • # Intéressant pour limiter foldingathome

    Posté par  . Évalué à 2.

    Ah! Personnellement, je vais essayer cela pour limiter l'occupation CPU de foldingathome. En effet, par défaut, foldingathome prend tout le temps CPU de libre et je n'ai jamais trouvé (okay, je n'ai pas trop cherché non plus) l'option permettant de régler son occupation maximale.

    Le but ici étant de limiter la chaleur dégagée par le CPU et ainsi de pouvoir diminuer le (un petit peu) la nuisance sonore.

  • # Et pour Flash ?

    Posté par  (site web personnel) . Évalué à 4.

    Si je veut limiter seulement le plug-in Flash, sans limiter Firefox pour le reste, je fais comment ?

    • [^] # Re: Et pour Flash ?

      Posté par  (site web personnel) . Évalué à 2.

      voir le 1er commentaire, tu peux mettre le nom du processus en paramètre, ça marche pour swfdec et gnash, pour flashplayer il doit aussi y avoir un nom de processus non ?

      • [^] # Re: Et pour Flash ?

        Posté par  (site web personnel) . Évalué à 1.

        Uniquement si tu utilise Konqueror, auquel cas le PID seras celui de nspluginwrapper.
        Dans ce cas, tu peut aussi wrapper nspluginwrapper, comme à la bonne époque d'aoss ^^. Suffit de créer un script shell nspluginwrapper dans /usr/local/bin et d'y mettre un truc genre cpulimit -l 10 nspluginwrapper $@ .

        En revanche, tu pourras rien faire si tu utilise l'un ou l'autre rejeton de la mozcorp, car le plugin est dlopen() directement dans Firefox™.
        Jusqu'au jour où une âme bienveillante écriras un loader pour isoler le broswer de ses plugins... un truc de plus dans ma pauv'todolist.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.