Journal Rah nice && cgroups

Posté par . Licence CC By‐SA.
Étiquettes :
14
16
mai
2012

Grande découverte en essayant Mageia 2 RC. On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste!

Exemple : lancer dans 3 consoles 7z b , nice -20 7z b et top.
Les deux instances de 7z ont droit à 50% de CPU chacune. Par contre, si on les lance dans une seule console :

(nice -20 7z b &);(7z b &);top

Ils se partagent correctement : 90%/10% environ. Mais alors, comment lancer un service en arrière plan qui ne bouffe pas 50% du CPU?

Merci aux rois du cgroup, puisque je suppose que ça vient de cette belle évolution qui permet à Linus de regarder un film en faisant make -j48.

  • # Non, définitivement

    Posté par . Évalué à 5.

    "On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste" je ne comprends pas cette phrase.

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: Non, définitivement

      Posté par . Évalué à 0.

      ben "man nice"

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Non, définitivement

        Posté par . Évalué à 10. Dernière modification le 16 mai 2012 à 17:46.

        man ironie

        $ echo "On ne peut plus se suffire de lancer un truc lourd avec nice pour pas qu'il fasse ramer le reste" < gcc -x Français --pedantic -o PostLinuxFr
Syntax Error Try "Il ne suffit plus de lancer nice sur un truc lourd pour qu'il ne fasse plus ramer le reste" instead

      • [^] # Re: Non, définitivement

        Posté par (site web personnel) . Évalué à 2. Dernière modification le 16 mai 2012 à 18:05.

        ben "man nice"

        Justement tu devrais le relire parce que nice -20 pour éviter de faire ramer ta bécane, heu comment dire… ou alors je n'ai pas non plus compris ton message. Je devrais peut-être essayer un
        $ apropos zino

        Ou sinon: CGROUP_SCHED=n

        • [^] # Re: Non, définitivement

          Posté par . Évalué à 1.

          Ah okokok…. en fait c'est pas nice moins vingt, mais nice tiret vingt. Ça ajoute 20 à la valeur par défaut!

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Documentation

    Posté par . Évalué à 2.

    Voir ici

    J'ai essayé vite fait avec un groupe à 100 cpu share et un à 900.

    100 shares:

    Dict Compressing | Decompressing
 Speed Usage R/U Rating | Speed Usage R/U Rating
 KB/s % MIPS MIPS | KB/s % MIPS MIPS
22: 2281 91 2430 2219 | 30548 110 2512 2756
23: 2684 113 2424 2735 | 39540 145 2493 3618
24: 3412 148 2483 3669 | 108073 391 2562 10026
25: 8092 348 2654 9239 | 105097 388 2548 9883
----------------------------------------------------------------
Avr: 175 2498 4465 259 2528 6571
Tot: 217 2513 5518

    900 shares:

    Dict Compressing | Decompressing
 Speed Usage R/U Rating | Speed Usage R/U Rating
 KB/s % MIPS MIPS | KB/s % MIPS MIPS
22: 7785 299 2537 7573 | 92630 326 2565 8357
23: 5872 232 2580 5983 | 88638 316 2568 8111
24: 6840 284 2591 7355 | 91305 332 2549 8470
25: 5969 259 2632 6815 | 90866 337 2534 8545
----------------------------------------------------------------
Avr: 268 2585 6932 328 2554 8371
Tot: 298 2569 7651

    • [^] # Re: Documentation

      Posté par . Évalué à 2.

      J'y suis passé en fouillant, mais c'est pas concluant : même avec 2 shares, mon processus de fond arrive à prendre 30% de cpu sur mon mono-processeur. C'est sûr qu'avec un tri-cpu comme le tien ça se sent même pas, mais c'est pareil : 100% environ et 300% respectivement.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Documentation

        Posté par . Évalué à 3.

        Quelques précisions pour comprendre la mécanique des cgroups :
        - la valeur dans cpu.shares est un poids attribué au process (normalisé à 1024) lors de l'attribution de temps sur un core ; Si tu lances deux benchs dans deux cgroups différents sur un même core, tu verras la répartition souhaitée, si tu les mets sur deux core ils mangeront chacun de leur côté.
        - Tu peux contrôler l'affinité, c'est à dire le core sur lequel réside un process, en restreignant les core accessibles grâce à cpu.cpus ; Cela permet par exemple de garantir que certains core restent disponibles.
        - Enfin l'attribution du temps n'a de sens que si le process en demande ; Si celui-ci est bloqué dans une IO il n'en recevra pas même si il a un poids maximum.

        Le cgroup cpu faut vraiment expérimenter un moment pour comprendre. :)

        • [^] # Re: Documentation

          Posté par . Évalué à 6.

          Cette mécanique est exactement celle permise avec la priorisation nice depuis aussi longtemps que je connais linux. cgroups apporte surtout la possibilité de grouper les taĉhes, pour que 48 processus en basse priorité ne finissent pas par faire saccader un processus unique genre lecteur vidéo en priorité normale. L'idée est que chaque groupe de processus est vu comme un seul droit processeur.

          Mais en fait, j'ai fini par trouver comment faire fonctionner le nice "normalement" :

          echo "kernel.sched_autogroup_enabled = 0" >> /etc/sysctl.conf
sysctl -p

          https://bugzilla.redhat.com/show_bug.cgi?id=721416

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # schedtool et ionice

    Posté par . Évalué à 2.

    Tu peux essayer du cote de schedtool et ionice
    exemple: schedtool -D -n 19 -e ionice -c 3 '7z b'

Suivre le flux des commentaires

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