Forum Linux.général Identifier une surcharge des accès disque

Posté par  (site web personnel) .
Étiquettes :
2
15
avr.
2010
Bonjour,

Je possède un serveur debian Lenny avec de nombreux utilisateur unix (~50) qui se le partage et j'ai parfois un souci de performance qui rend le serveur inutilisable. Mon objectif est de trouver la cause (user unix ou bien quel processus) de ces baisses de performance.

J'ai déjà identifié grâce au logiciel "atop" que cela provient des accès disques en lecture qui sont tellement nombreux que le serveur devient quasi inutilisable sur une période donnée. "atop" permet d'avoir des stats détaillée sur la consommation des disques mais cela nécessite de patcher le noyau linux ce que j'aimerai éviter.

Avez vous des idées autre que atop pour identifier le user ou processus "coupable" ?

  • # iotop

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

    Mais j'imagine que ca utilise les même fonctionnalités du kernel:

    man iotop:
    iotop watches I/O usage information output by the Linux kernel (requires 2.6.20 or later) and displays a table of current I/O usage by processes or
    threads on the system. At least the CONFIG_TASKSTATS and CONFIG_TASK_IO_ACCOUNTING options need to be enabled in your Linux kernel build configura‐
    tion.


    Une fois que tu auras trouvé le coupable, fais lui découvrir la commande ionice.

  • # io disque != utilisateur

    Posté par  . Évalué à 2.

    Commence déjà par vmstat parce que io disque ne veut pas dire utilisateurs. Ca peut être la swap et donc le manque de mémoire.

  • # pas de trace dans le kernel ?

    Posté par  . Évalué à 3.

    dmesg n'indique rien de special ? (pas de too many file?)

    que donne "lsof -n | awk '{print $1}' | sort | uniq -c | sort -rn | head" quand ca tourne a fond
    (lsof permet de savoir les fichiers ouvert sur le systeme et la petite ligne la indique le nombre par process je l'ai trouvé la http://dev.petitchevalroux.net/linux/afficher-les-processus-(...) )



    que donne la commande top quand ca part en vrille ? (memoire swap utilisé par exemple..)

    • [^] # Re: pas de trace dans le kernel ?

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

      Merci pour la ligne de commande, je vais la mettre dans un crontab toutes les 10 minutes et j'analyserai les résultats au prochain coup de fouet. Je vous tiens au courant.

      • [^] # Re: pas de trace dans le kernel ?

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

        Voila ce que cela retourne en temps normal :
        root@grenoble:~/dsk_log1# lsof -n | awk '{print $1}' | sort | uniq -c | sort -rn | head
        46905 apache2
        2357 php-cgi
        2342 mysqld
        437 java
        253 mysqld_sa
        191 php5-cgi
        138 services
        125 master
        116 sshd
        60 slapd


        Et voila ce que cela retourne lorsque le serveur est surchargé :
        46448 apache2
        2331 mysqld
        2044 php-cgi
        432 java
        253 mysqld_sa
        191 php5-cgi
        138 services
        133 cron
        125 master
        113 sshd


        En gros, il ne semble pas y avoir bcp de différences ... peut-être que atop me donnerait une mauvaise piste ?

        • [^] # Re: pas de trace dans le kernel ?

          Posté par  . Évalué à 1.

          Si on décide de croire atop la presque seule différence dans le log est la ligne
          133 cron
          c'est une piste a voir non ?
          Sinon si on dit que les acces disques sont long et que le nombre de fichier ne change pratiquement pas on peut envisagé une defaillance disque dur peut etre aussi non ? sur-chauffe et temps de seek de la tete qui augemente ?
          Sinon je pense que pour creuser plus il faudra patcher le kernel pour avoir plus d'info avec atop mais peut etre aussi voir du coté des drivers ide ou sata si des infos de debug ne sont pas disponible.
          (modinfo nom-du-driver) puis rmmod insmod....

Suivre le flux des commentaires

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