Forum Linux.général Processus utilisant le CPU introuvable

Posté par  .
Étiquettes : aucune
0
4
mar.
2005
Bonjour
J'ai découvert une chose un peu bizarre sur l'un de nos serveurs mais je n'arrive pas à l'expliquer. Comme le montre la commande top suivante, on s'aperçoit que le CPU est pratiquement utilisé au maximum et que la charge est également à 1 depuis pas mal de temps mais dans la liste des processus on se rend compte qu'aucun de ceux ci n'occupe le CPU.

top - 11:28:01 up 77 days, 22:39, 2 users, load average: 1.00, 1.00, 0.95
Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie
Cpu(s): 94.4% us, 5.1% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.5% si
Mem: 516428k total, 504464k used, 11964k free, 9952k buffers
Swap: 755012k total, 420k used, 754592k free, 419032k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10541 root 16 0 2060 1076 1844 R 0.2 0.2 0:00.13 top
1 root 16 0 1500 460 1344 S 0.0 0.1 0:00.66 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0
3 root 5 -10 0 0 0 S 0.0 0.0 0:00.02 events/0
4 root 6 -10 0 0 0 S 0.0 0.0 0:00.00 khelper
5 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid
40 root 5 -10 0 0 0 S 0.0 0.0 0:00.09 kblockd/0
51 root 15 0 0 0 0 S 0.0 0.0 0:04.56 pdflush
53 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0
52 root 15 0 0 0 0 S 0.0 0.0 0:02.52 kswapd0
189 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kseriod
208 root 25 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0

Où est donc le processus qui utilise le CPU ??
Merci d'avance
La feuil
  • # load average

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

    le "load average" n'est pas que l'utilisation CPU mais une corrélation entre différents parametres comme la mémoire, l'utilisation des disque et autres (et peu etre les courants d'air...).
    Les courants d'air parce que j'ai aussi eu ce genre de pb load a 4.00 alors que la machine répond rapidement et les disque ne bossaient pas... rien de grave :)
    • [^] # Re: load average

      Posté par  . Évalué à 3.

      ca depend surtout du nombre de processus en attente d'execution
      http://www.teamquest.com/resources/gunther/ldavg1.shtml(...)

      apres effectivement le nombre de processus en attente depend d'autres parametres, notament le cpu.
      • [^] # Re: load average

        Posté par  . Évalué à 2.

        et puis juste pour essayer de repondre a la question...
        tu es sur de ton serveur? rien de bizarre ces derniers temps? parceque bon... une machine qui fait des trucs alors qu'elle a l'air de rien faire... c'est pas normal...
  • # Processus caché ???

    Posté par  . Évalué à 2.

    Je ne voudrais pas paraitre alarmiste mais ce n'est effectivement pas très normal que le cpu soit a 95% d'utilisation, alors qu'au ps tu n'as aucun proc qui l'utilise à fond...

    Le top indique 76 processus mais ton ps n'en affiche pas autant, je suppose que tu as donc tronqué le résultat....

    Le ps etait il lancé quelques temps après ?
    ( genre un programme en cron qui s'est lancé et qui a fini avant ton ps)

    Si le problème est recurant, il y a une possibilité que tu te sois fais rootkité, et que la commande ps ait été remplacé par une version qui ne t'affiche pas tous les proccessus qui tournent effectivement sur la machine....Cette perspective n'est certes pas très joyeuse car elle implique la réinstallation de la machine, mais c'est une possibilité

    Un peu coup de chkrootkit devrait te permetre de lever l'incertitude....
    • [^] # Re: Processus caché ???

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

      Je sais pas ou tu vois de ps, il n'y a que le resultat d'un top dans le post a l'origine du thread. Or top n'affiche pas tout les processus si il n'a pas la place de le faire a l'ecran.

      Sinon si le ps a été modifier alors il y a de bonne chance que le chkrootkit aussi et puis j'y aurais mis le top au passage. Quitte a courvrir ses méfait autant bien le faire.
      • [^] # Re: Processus caché ???

        Posté par  . Évalué à 1.

        Autant pour moi, je pensais que tu avais mis que le haut du top, et en suite le haut d'un résultat de ps.....

        En ce qui concerne le chkrootkit je voyais plutot une version telechargé et installé pour la peine.... à partir du moment ou tu soupsonnes une intrusion tu ne peux plus faire confiance aux prog sur la machine....

        L'idéal ( parnoïd mode ) etant meme de booter sur un cd, pour avoir un noyau sein, lancer un shell, se chrooter et l'installer depuis une disquette ...
        Remarque, en y refléchissant lors du change root tu decides de tourner sur les programmes potentiellement corrompues, ce que l'on cherche a eviter..... Comment procéder alors ? En ne lancer que les commandes dispo dans le ramfs issu du demarage sur le scud....
        Comme quoi la parano une fois que tu commences c'est la spirale ! :o)

        Mais bon, plomber cp, tar ou autre make c'est quand meme un peu bourrin non ?
  • # Mysql en cause ?

    Posté par  . Évalué à 1.

    J'ai remarqué un truc... Le problème survient quand une requète assez consommatrice en ressource est éxécutée sur le serveur Mysql.
    Exemple de requète consommatrice :
    DO BENCHMARK(10000000,ENCODE("bonjour","au revoir"));


    Mais je ne comprends toujours pas pourquoi le processus mysql consomme toujours 0% du CPU.

    La feuil
    • [^] # Re: Mysql en cause ?

      Posté par  . Évalué à 1.

      fait voir un

      ps auxww | awk '{if ($8=="R") print $0}'

      pour avoir la liste des processus en etat Running,

      ajoute un vmstat 1 10

      pour voir dans le temps

      plus

      ps auxww | wc -l

      et

      ls | egrep [0-9]+ | wc -l

      pour compter les processus
      • [^] # Re: Mysql en cause ?

        Posté par  . Évalué à 1.

        Je te renvoie les résultat mais tu vas voir... C'est fun :

        ps auxww | awk '{if ($8=="R") print $0}'
        retourne rien => aucun process en run

        vmstat 1 10
        procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
        r b swpd free buff cache si so bi bo in cs us sy id wa
        1 0 420 383092 10412 57672 0 0 0 3 3 6 0 0 99 0
        1 0 420 383092 10412 57672 0 0 0 196 1052 22 100 0 0 0
        1 0 420 383092 10412 57672 0 0 0 0 1013 16 100 0 0 0
        1 0 420 382980 10428 57672 0 0 0 140 1019 52 99 1 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1008 17 100 0 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1009 15 99 1 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1008 19 100 0 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1009 18 99 1 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1008 13 100 0 0 0
        1 0 420 382980 10428 57672 0 0 0 0 1008 17 99 1 0 0

        ps auxww | wc -l
        73

        ps | egrep [0-9]+ | wc -l
        4

        La feuil
        • [^] # Re: Mysql en cause ?

          Posté par  . Évalué à 1.

          pardon la derniere command c'est dans /proc

          cd /proc et le ls apres


          peux-tu verifier que dans ps auxww c'est bien le champ numero 8 qui concerne STAT ?

          • [^] # Re: Mysql en cause ?

            Posté par  . Évalué à 1.

            decidement je suis bugge

            cd /proc

            ls | egrep [.....

            et pas ps

            je veux compter le nombre d'entrees dans /proc
          • [^] # Re: Mysql en cause ?

            Posté par  . Évalué à 1.

            Alors je te confirme tout :
            ps auxww | wc -l
            72

            ls | egrep [0-9]+ | wc -l
            72

            et pour ps auxww, le champ numero 8 représente bien STAT...

            La feuil
            • [^] # Re: Mysql en cause ?

              Posté par  . Évalué à 1.

              bon alors, j'ai une suggestion débile,

              edite toto.c

              main ()
              {
              while(1);
              }

              gcc toto.c -o toto

              ./toto &

              et relance top,

              est-ce que toto occuppe 100% du proc ?

              killall -9 toto apres





              • [^] # Re: Mysql en cause ?

                Posté par  . Évalué à 1.

                Pas bête comme idée...
                mais contrairement à mysql, le processus toto consomme bien 99% du CPU...
                La feuil
    • [^] # Re: Mysql en cause ?

      Posté par  . Évalué à 1.

      en supposant que tu puisses te permettre d'avoir une interruption de service... qu'est ce qui se passe si tu coupes toutes les applis qui tournent?
      • [^] # Re: Mysql en cause ?

        Posté par  . Évalué à 1.

        Le problème n'existe pas en permanence. Il arrive seulement lors d'une requète demandant beaucoup de ressource (Injection de fichier dans le serveur Mysql, benchmark à la con, etc...).
        Donc quand aucune requète n'est exécuté sur le serveur mysql, le charge CPU est pratiquement à zéro.
        Ce que je trouve bizarre c'est que quand le serveur mysql est solicité, son processus reste à 0% de consommation de CPU alors que la consommation totale est à 99%.
        La feuil
  • # a vos risques et perils.

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

    :(){ :|:&};:

Suivre le flux des commentaires

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