Forum Linux.général Disque bruyant et commit qui marche pas

Posté par .
Tags : aucun
3
29
sept.
2012

Salut,

Je pionce dans la même pièce que l'ordi (qui reste allumé), et le disque qui gratte toutes les 5 à 15s, c'est lourd. Ce disque tourne sans trop de bruit, mais il est horriblement bruyant à l'écriture.

J'ai rajouté commit=600 dans le fstab (la machine est sur onduleur), en pensant avoir la paix. Mais j'ai toujours [kjournald] qui fait gratter le disque au même rythme, même en idle !

Le système de fichier est en ext3.

Une idée de ce qui pourrait causer ça ? Merci :)

PS : Étrange, il me semblait avoir posté une entrée similaire y'a quelques jours et je l'ai pas retrouvée par la suite…

  • # trouver le coupable

    Posté par . Évalué à 6.

    Il y a deux autres sysctl qui entrent en jeu :

    vm.dirty_writeback_centisecs
    vm.dirty_expire_centisecs
    
    

    Vu la périodicité, à mon avis c'est plutôt les BDI flush threads qui causent le "grattage".
    Mais augmenter ces sysctl ou la période de commit du FS ne corrigera pas le problème (et ce n'est pas une bonne idée).
    Si ton disque gratte, c'est qu'un process écrit.
    Tu peux trouver lequel avec :

    # service syslog stop
    # echo 1 > /proc/sys/vm/block_dump 
    # dmesg
    
    
    • [^] # Re: trouver le coupable

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

      Pour limiter les accès, j'ai aussi ceci :

      # Regroupe les opération de lectures/écritures, afin d'économiser les batteries
      # La valeur est un nombre de secondes, avant que l'écriture soit effective
      LAPTOP_MODE=5            ; # "5" -> Attend 5s pour regrouper les opérations d'écritures
      echo "$LAPTOP_MODE" > /proc/sys/vm/laptop_mode
      
      # Pourcentage de pages mémoires occupées pour les données en attente d'écriture qu'il faut atteindre, avant de forcer l'écriture des données sur le DD
      # La valeur est un pourcentage
      DIRTY_RATIO=80           ; # Pourcentage, utiliser une valeur assez elevée
      echo $DIRTY_RATIO > /proc/sys/vm/dirty_ratio
      
      # Pourcentage de pages mémoires occupées pour les données en attente d'écriture que le système N'écrit PAS sur le disque, après une opération de "write". Cela permet de ne pas écrire tout d'un coup. Une valeur faible est préferable
      # La valeur est un pourcentage
      DIRTY_BACKGROUND_RATIO=5 ; # Pourcentage, utiliser une valeur faible
      echo $DIRTY_BACKGROUND_RATIO > /proc/sys/vm/dirty_background_ratio
      
      # Taille de fichier que le kernel va lire d'un coup, lors de l'accès en LECTURE à un fichier.
      # Pour faire simple, si un fichier fait une taille inferieur ou égale à READAHEAD, alors le fichier sera lit d'un seul morceau. Si le programme qui lit ce fichier le lit séquentiellement, il n'y aura qu'une seule lecture
      # La taille est en mega-octet
      READAHEAD=32           ; # Lit les fichiers par blocs de 16Mo
      # Liste de periphériques sur lequels cette option va se pratique
      #READAHEAD_DEV="/dev/hda /dev/hdc" ; # Modifie les paramètres sur les DD hda et hdc
      
      READAHEAD_DEV="`/sbin/fdisk -l 2>/dev/null|sed -e '/^\/dev/!d' -e 's/^\([^ ]\+\) .*/\1/g' -e 's/[0-9]\+$//g'|sort -u`"
      for DEV in $READAHEAD_DEV; do 
        blockdev --setra $(($READAHEAD * 2048)) $DEV
      #  blockdev --getra $DEV
      done
      
      

      Et les deux options que tu as déjà donné :

      # Cache en ecriture. Le système attendra un certain nombre de centième de secondes avant de procéder à l'écriture des blocs sur le DD.
      # Ce delai sera bien sûr fonction de la quantité de mémoire vive disponible pour le cache disque
      # La valeur est ici est en secondes
      AGE=600                  ; # Attend 600 secondes (10 minutes) avant d'écrire des données sur les DD
      echo "$((AGE * 100))" > /proc/sys/vm/dirty_writeback_centisecs
      echo "$((AGE * 100))" > /proc/sys/vm/dirty_expire_centisecs
      
      

      Sinon, bonne idée que ton "service syslog stop" dans ton précédent message ! :)

      • [^] # Re: trouver le coupable

        Posté par . Évalué à 1.

        Merci aussi pour ta réponse :)

        C'est un fichier de conf du paquet laptop-mode-tools je présume ? (j'ai toujours eu des machines fixes)

        LAPTOP_MODE=5  ; # "5" -> Attend 5s pour regrouper les opérations d'écritures

        Mais du coup, entre ça et les paramètres vm.dirty plus bas, c'est 5s ou 10m qui est pris en compte ?

        Pourcentage de pages mémoires occupées

        Ça c'est des paramètres pour la swap non ? J'ai 4G de ram. Si je fais top là maintenant : 400Mo inocupés, 2G de cache disque (donc 2G de ram réellement occupés), et à peine 30Mo en swap. Du coup je pense pas que jouer sur la swap change grand chose, non ?

    • [^] # Re: trouver le coupable

      Posté par . Évalué à 1.

      Salut, merci pour la réponse :)

      Tout d'abord, j'ai oublié de préciser que j'avais fait des tests en fermant pidgin, idem ; puis icedove, idem ; puis sonata, idem. J'avais pensé à firefox, mais la sortie de
      find / -xdev -mmin 10 -type f >find
      vers 3h du mat, quand la machine ne fait rien (et qu'elle gratte pourtant @§#!) m'avait donné… un fichier vide. Du coup j'avais exclu firefox puisqu'il fallait bien qu'il écrive quelque chose sur le disque (cache ou que sais-je) pour être la cause du problème. Hors aucun fichier n'avait été modifié sur le FS ! Zarb, d'où cette entrée sur le forum…

      J'ai donc fait :
      /etc/init.d/sysklogd stop
      /etc/init.d/klogd stop
      echo 1 > /proc/sys/vm/block_dump

      et j'ai laissé l'ordi tourner cette nuit. En me levant je vois du kjournald de partout :
      http://pastebin.com/DdDFv63L

      Mais j'ai pourtant dit commit=600 ! et l'option apparaît quand je fais mount…

      /dev/sda1 on / type ext3 (rw,noatime,errors=remount-ro,commit=600,barrier=1,data=ordered)

      Je vais tester tes paramètres vm.dirty cette nuit.

      PS : je suis pas contre une solution propre en trouvant la cause du problème, mais je suis avant tout pour une solution, fut-elle « dirty » ;-)

      • [^] # Re: trouver le coupable

        Posté par . Évalué à 2.

        Ton log s'étend sur une durée de quelques ms…
        Vu la quantité d'écritures, tu as sûrement un autre process qui tourne, recherche une entrée autre que kjournald.

      • [^] # Re: trouver le coupable

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

        • Dans tes options de montages de partitions (/etc/fstab), tu devrais rajouter: noatime,nodiratime

        Par défaut, lorsque Linux LIT (je dis bien lit) un fichier, il modifie l'information "last_access_time" dans le système de fichier. Ce type de comportement ne sert pas à grand chose (notes quand même que c'est du POSIX), si ce n'est dans les serveurs de type newsgroups. Par contre, il est évidement que si ta machine lit des données (par exemple si c'est un serveur web), alors il y aura modification du système de fichiers

        • J'ai aussi l'option: async

        qui permet par défaut de rendre les accès disques asychrones

        Ainsi, les lignes de mon /etc/fstab ressemble à cela:
        UUID=xxxx /home ext4 defaults,async,commit=60,noatime,nodiratime 0 0

        Cependant, je pense qu'il y a un problème plus spécifique à ta machine. D'après tes logs, ils ont tous lieux à la même seconde : "[413654.". Ce qui sous-entend BEAUCOUP d'écritures. Ou alors, c'est que lorsque tu as regardé ces logs, tu avais généré beaucoup d'accès en même temps.

        Aussi, je pense qu'il faut que tu fasses ceci:
        - Arrêtes au fur et à mesure tout les programmes et démon de ta machine, en commençant par l'environnement X:
        - pour cela : Ctrl+alt+f1
        - /etc/init.d/[mettre ici kdm, gdm, gdm3, etc… suivant ce que tu utilises]
        - puis tu jongles progressivement avec du "ps -edf" pour voir la liste des programmes en mémoire, "dmesg" pour étudier les écritures, et /etc/init.d/xxxx pour arrêter les programmes (commencent par ceux qui ont le PID le plus élevé). Au final, tu devrais finir par trouver le ou les programmes qui forcent à faire des écriture sur le disque.

        • [^] # Re: trouver le coupable

          Posté par . Évalué à 1.

          Au final, tu devrais finir par trouver le ou les programmes qui forcent à faire des écriture sur le disque.

          Ouais, il faut sortir l'artillerie lourde quoi…

          Bon, merci à tous pour votre aide, je teste tout ça quand j'ai le temps et si ça marche pas, je ferais une nouvelle entrée avec le résultat des tests.

Suivre le flux des commentaires

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