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

• # trouver le coupable

  Posté par neologix le 29 septembre 2012 à 10:20. É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 Olivier (site web personnel) le 29 septembre 2012 à 10:56. É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 Arathor le 30 septembre 2012 à 09:05. É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 Arathor le 30 septembre 2012 à 08:50. É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 neologix le 30 septembre 2012 à 10:47. É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 Olivier (site web personnel) le 30 septembre 2012 à 10:58. É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 Arathor le 01 octobre 2012 à 12:40. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.