Forum général.général Limité l'utilisation du processeur lors d'une compilation

Posté par .
Tags : aucun
1
19
oct.
2010
Bonjour,
j'ai un petit problème avec mon portable lorsque je lance une grosse compilation telle que ROOT (développé au CERN) par exemple. Il me faut bien 30 minutes à 1 heure pour terminer la compilation. Or pendant ce temps mon PC chauffe beaucoup et il est tr_s fréquent qu'il dépasse le seuil maximum de température autorisé ce qui fait que le noyau envoie une demande d'arrêt de l'ordinateur.
Je souhaiterais donc trouver un moyen de limiter l'utilisation du processeur pour la compilation (ce n'est pas grave si ça prend plus de temps). J'ai entendu parlé dde cpulimit mais je ne sais pas comment m'en servir dans mon cas car le numéro du processus change sans arrêt (certains processus s'arrêtent et d'autres commencent avec un nouveau numéro) pendant la compilation et il y a plusieurs noms de processus différent (cc1plus, cc1, as)
Quel genre de technique je peux utiliser pour pallier à mon problème ?
Merci d'avance.
  • # Cpuspeed / Fréquence processeur

    Posté par . Évalué à 2.

    Réponse de 3 heures du mat' à prendre avec des pincettes :

    -> Pourquoi ne pas utiliser cpuspeed (ou tout autre dæmon contrôlant les fréquences des processeurs) ? Si j'ai bonne mémoire, ils ont une option pour soit forcer les fréquences à leur minimum, soit automatiquement le faire en cas de dépassement d'une température CPU pré-définie par l'utilisateur.

    Autrement, tu as essayé d'utiliser cpulimit sur le processus père des cc1plus, cc1 et consorts ? (`ps -eH | less -pmake`)
    • [^] # Re: Cpuspeed / Fréquence processeur

      Posté par . Évalué à 1.

      Bon tu m'as l'air bien réveillé quand même vu l'heure qu'il est chez toi :)
      Je viens de tester cpulimit sur le processus père et ça a l'air de fonctionner. Je ne sais pas pourquoi je n'y ai pas songé moi-même. En tout cas merci. Je vais pouvoir laisser tourner ma compilation cette nuit ^^
    • [^] # Re: Cpuspeed / Fréquence processeur

      Posté par . Évalué à 1.

      Bon en fait je me suis emballé trop vite, en moins de 5 minutes cpulimit semble m'avoir fait craché ma compilation. En fait certains processus sont arrêtés et se transforment en zombie ce qui fait crasher la compil. Je vais me pencher sur cpuspeed.
  • # nettoie-le

    Posté par . Évalué à 3.

    Dans un premier temps, je te conseille de nettoyer la ventilation de ton portable, pour enlever la poussière accumulée.
    Ce n'est pas normal qu'il s'éteigne à cause d'une température trop élevée lors d'une utilisation normale (ou alors il a un gros problème de desgin...).
    • [^] # Re: nettoie-le

      Posté par . Évalué à 5.

      Perso j'ai eu des problèmes de ce type avec un portable HP il y a quelques années, et nettoyer les ventilos n'y changeait rien : c'était bien un problème de design.

      Quand le PC tournait à 100%, la température augmentait, mais ne se stabilisait pas. On arrivait à 80°, parfois à 90° et ensuite le portable se mettait en sécurité.

      J'ai fait don de ce portable à quelqu'un qui, pour contourner le problème, a acheté une tablette avec des ventilateurs dessus. Depuis ça marche mieux...

      Enfin c'était juste pour dire que les problèmes de ce type, ça arrive, et pour l'instant, tous les portables HP que j'ai pu voir avaient ces problèmes de surchauffe.
  • # verifie les options de make ou gcc

    Posté par . Évalué à 3.

    en effet, il y a des options (-j X ou X est un chiffre)
    qui peuvent rendre une compilation CPUvore.

    dans le man de make, il faut avoir X = nombre de coeur +1
    si on met juste -j, ca essaie de compiler un max de chose en paralelle => CPU = 100%

    en enlevant cette option -j
    ou en reduisant le chiffre pour l'adapter à ma machine (core 2 duo)

    meme une compilation kernel ne me prend pas 100% du CPU.
  • # man ulimit

    Posté par . Évalué à 1.

    Tout est dans le titre.
    • [^] # Re: man ulimit

      Posté par . Évalué à 3.

      ulimit pour contrôler la mémoire, oki. Mais pour l'utilisation CPU du fait comment ?

      Il y a bien -t The maximum amount of cpu time in seconds, mais je ne pense pas que ça réponde au problème.
      • [^] # Re: man ulimit

        Posté par . Évalué à 2.

        Ah merde, j'ai effectivement parlé un peu vite, désolé. Là comme ça je n'ai pas trouvé de solution à ton problème, à part changer de portable.

        Moi, comme d'autres, je trouve que ce n'est pas normal qu'il surchauffe. Et j'ai déjà « réparé » un portable comme ça : nettoyage des ventilos et radiateurs, remise de pâte thermique neuve (après nettoyage à l'alcool) et configuration correcte du portable (cpufreq configuré en ondemand, CG configurée en dynamicclock, etc). Et bien après tout ça, il ne chauffait quasiment plus.
  • # réponse de papi

    Posté par (page perso) . Évalué à 3.

    bout de code pour la postérité, comme Linus notre dieu à tous, commença par créer le monde avec open ..., et que sous linux on peut s'amuser un peu !

    -----------------
    cat lol.c
    #include <dlfcn.h>

    int open(const char *pathname, int flags)
    {
    void *libc;
    int (*open_call)(const char *,int);
    int ret=-1;
    if(libc=dlopen("/lib/libc.so.6",RTLD_LAZY)) {
    open_call = dlsym(libc,"open");
    usleep(1000000);
    ret=(*open_call)(pathname,flags);
    dlclose(libc);
    }
    return ret;
    }
    -----------------
    gcc -shared -o lol.so lol.c -fPIC -ldl
    export LD_PRELOAD=/home/npa/lol.so
    -----------------
    time tail -1 /etc/passwd
    statd:x:124:65534::/var/lib/nfs:/bin/false

    real 0m1.010s
    user 0m0.010s
    sys 0m0.010s

    Bon après je te laisse comprendre tout seul le code et modifier le 1000000 à souhait !,
    plus simple, envoyer des kill -STOP , kill -CONT sur les process le temps de laisser refroidir !!, jouer avec cpufreq et quelques echos bien placés dans /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq , mais c'est tout de suite moins drole alors ...

    Nicolas

Suivre le flux des commentaires

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