Forum Linux.noyau Flush disque qui fait "freezer" la machine

Posté par .
Tags : aucun
1
6
jan.
2010
Bonsoir,

je me trimballe un soucis depuis que je suis passé en 2.6.32 je pense, de temps à autre mes applications se retrouvent dans l'état "En attente disque".

Quand je regarde avec atop, à ce moment là ce qui utilise le plus le disque c'est soit un processus "flush-254:0" soit un processus "jbd/2".

D'après moi ce sont des processus du noyau, mais je n'ai aucune idée de pourquoi ça freeze...ça arrive le plus souvent quand je lance deux applis qui utilisent beaucoup le disque en même temps (exemple unrar, bittorrent en fond et firefox), mais je n'ai jamais eu ce soucis auparavant.

Est-ce qu'il existe une option du noyau qui permettent de faire en sorte que tous les process auront toujours accès au disque, quitte à perdre un peu de temps sur les gros transferts.

C'est quand même bien embêtant, surtout que ça dure minimum 10s à chaque fois.

Merci à vous.
  • # Si la piste du processus noyau est la bonne ...

    Posté par . Évalué à 6.

    Avant le 2.6.32 les threads noyaux pdflush étaient chargés d'écrire sur les disques les données modifiées. Le 2.6.32 propose une nouvelle infrastructure : flush. Le noyau crée selon les besoins des threads flush-X:Y où X et Y désignent le majeur et le mineur du périphérique dont le thread est responsable. Avec ce système, un périphérique lent ne pénalise pas les périphériques rapides.

    Trois questions pour progresser :
    * Le processus flush est-il bien un processus du noyau ? Dans l'affirmative, il apparrait entre crochets avec la commande
    ps aux.

    * jdb = java debuger ?

    * Sur ton système, quel périphérique a pour majeur 254 et mineur 0 ?
    • [^] # Re: Si la piste du processus noyau est la bonne ...

      Posté par . Évalué à 3.

      une piste pour Sphax (au cas ou)

      ls -l /dev | grep 254 devrait te lister tous les peripheriques ayant 254 en majeur et mineur

      chez moi c'est /dev/rtc0
      ~$ ls -l /dev | grep 254
      crw-rw---- 1 root root 254, 0 2010-01-06 09:41 rtc0
    • [^] # Re: Si la piste du processus noyau est la bonne ...

      Posté par . Évalué à 2.

      Alors:
      # ps aux | grep flush
      root 4525 0.0 0.0 0 0 ? S Jan06 0:33 [flush-254:0]

      # ps aux | grep jbd
      root 4170 0.0 0.0 0 0 ? S Jan06 0:05 [jbd2/dm-0-8]

      Rien à voir avec du Java donc, et les deux sont bien des process noyau d'après ce que tu m'indiques.

      Ensuite:
      # ls -l /dev | grep 254
      0 brw-rw---- 1 root disk 254, 0 janv. 6 02:45 dm-0


      dm-0 c'est mon volume LVM contenant mes données, celui qui est utilisé donc.

      En tout cas merci de ces infos, j'étais pas au courant des changements avec le 2.6.32
      Serait-il possible que ce soit du au fait que j'utilise un LVM ?
      • [^] # Re: Si la piste du processus noyau est la bonne ...

        Posté par . Évalué à 2.

        On dirait que tu es tombé sur une régression...
        En vrac :
        - un "strace -T" sur les process en question serait utile pour voir où ils sont bloqués (mais c'est très probablement sur un write ;-)
        - la sortie d'un "cat /proc/meminfo" pourrait être intéressante
        - est-ce que des "sync" en background améliorent les choses ?
        - rien de spécial dans "var/log/messages" ?
        - que donne un "echo t > /proc/sysrq-trigger" lors d'un blocage ?

        Ce serait pas mal de reporter le problème sur la mailing liste du noyau...
        • [^] # Re: Si la piste du processus noyau est la bonne ...

          Posté par . Évalué à 1.

          - Comment je peux attacher strace à un process noyau ? Je me tape ça:
          attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted quand j'utilise strace -T -p

          - cat /proc/meminfo
          MemTotal: 2057484 kB
          MemFree: 344592 kB
          Buffers: 80816 kB
          Cached: 970452 kB
          SwapCached: 116348 kB
          Active: 714504 kB
          Inactive: 863260 kB
          Active(anon): 236104 kB
          Inactive(anon): 293600 kB
          Active(file): 478400 kB
          Inactive(file): 569660 kB
          Unevictable: 4916 kB
          Mlocked: 4916 kB
          SwapTotal: 979924 kB
          SwapFree: 643120 kB
          Dirty: 7232 kB
          Writeback: 0 kB
          AnonPages: 453740 kB
          Mapped: 71644 kB
          Shmem: 696 kB
          Slab: 58604 kB
          SReclaimable: 42064 kB
          SUnreclaim: 16540 kB
          KernelStack: 2088 kB
          PageTables: 19808 kB
          NFS_Unstable: 0 kB
          Bounce: 0 kB
          WritebackTmp: 0 kB
          CommitLimit: 2008664 kB
          Committed_AS: 1431644 kB
          VmallocTotal: 34359738367 kB
          VmallocUsed: 298704 kB
          VmallocChunk: 34359428868 kB
          HardwareCorrupted: 0 kB
          DirectMap4k: 3648 kB
          DirectMap2M: 2093056 kB


          - Qu'appelles-tu des "sync" en background ?

          - Rien de spécial dans les logs non

          - La commande ne donne rien, je l'ai lancé quand firefox était bloqué par exemple, après l'avoir lancé il était toujours en attente disque.
          • [^] # Re: Si la piste du processus noyau est la bonne ...

            Posté par . Évalué à 1.

            Hum en fait j'avais pas activé les sysrq, mais même en le faisant ça ne fait rien.
            D'après ça: [http://www.mjmwired.net/kernel/Documentation/sysrq.txt]
            La commande 't' devrait m'afficher une liste, mais je n'ai rien ni dans mon konsole, ni dans les tty :/
            • [^] # Re: Si la piste du processus noyau est la bonne ...

              Posté par . Évalué à 1.

              sysrq dump dans les logs noyaux, que tu peux voir avec un "dmesg" ou dans /var/log/messages.
              Pour le strace, il faut le faire sur les process qui bloquent, pas sur les process noyau.
              • [^] # Re: Si la piste du processus noyau est la bonne ...

                Posté par . Évalué à 2.

                Ok, j'ai vu le dump via "dmesg", et je sais pas du tout comment interpréter ça, c'est complètement indigeste :/
                Ca marche par thread ou par process ? Parce que j'ai plusieurs stacktrace de firefox par exemple, une dizaine d'amarok etc..

                Voilà un exemple:
                qbittorrent S 0000000000000000 0 32369 16980 0x00000000
                ffff880003e60d60 0000000000000082 0000000000000000 000000000000fc40
                00000000000f3e57 ffffffff81077179 ffff88007f85b580 ffff88007668a000
                ffff880003e61000 000000000000f888 ffff880003e61000 ffff88007668a000
                Call Trace:
                [<ffffffff81077179>] ? enqueue_hrtimer+0x79/0x100
                [<ffffffff8133294d>] ? schedule_hrtimeout_range+0xcd/0x180
                [<ffffffff810772c0>] ? hrtimer_wakeup+0x0/0x30
                [<ffffffff81332938>] ? schedule_hrtimeout_range+0xb8/0x180
                [<ffffffff8112036c>] ? poll_schedule_timeout+0x2c/0x50
                [<ffffffff811207f9>] ? do_sys_poll+0x3b9/0x4b0
                [<ffffffff81121930>] ? __pollwait+0x0/0x120
                [<ffffffff81121a50>] ? pollwake+0x0/0x60
                [<ffffffff81121a50>] ? pollwake+0x0/0x60
                [<ffffffff81121a50>] ? pollwake+0x0/0x60
                [<ffffffff81121a50>] ? pollwake+0x0/0x60
                [<ffffffff81121a50>] ? pollwake+0x0/0x60
                [<ffffffff8127f029>] ? sock_aio_read+0x169/0x170
                [<ffffffff8127ed40>] ? sock_aio_write+0x0/0x180
                [<ffffffff8110ecb4>] ? do_sync_readv_writev+0xd4/0x110
                [<ffffffff81074100>] ? autoremove_wake_function+0x0/0x30
                [<ffffffff8110eef2>] ? do_sync_read+0xe2/0x120
                [<ffffffff81074100>] ? autoremove_wake_function+0x0/0x30
                [<ffffffff81330aa0>] ? thread_return+0x4e/0x7ae
                [<ffffffff810199e5>] ? read_tsc+0x5/0x20
                [<ffffffff8107dfc1>] ? ktime_get_ts+0x61/0xd0
                [<ffffffff81120314>] ? poll_select_set_timeout+0x74/0xa0
                [<ffffffff81120af1>] ? sys_poll+0x71/0x110
                [<ffffffff81012082>] ? system_call_fastpath+0x16/0x1b

                Les "enqueue_hrtimer" sont récurrents sur beaucoup de process, comme les "schedule_hrtimeout_range", beaucoup de "sys_read", de "sys_write"..
                C'est très long le dump, je vais pas tout copier, mais si je sais plus précisément quoi regarder je le fais.

                Ensuite, j'ai donc attaché strace sur mon process de firefox, en même temps que j'ai lancé 2 décompressions avec unrar, et qbittorrent qui tourne en arrière plan (1 seul torrent en téléchargement). J'ai pleeeeein de lignes comme ça:
                read(10, "\372", 1) = 1 <0.000008>
                read(3, 0x7f44b7286074, 4096) = -1 EAGAIN (Resource temporarily unavailable) <0.000008>
                poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=20, events=POLLIN|POLLPRI}, {fd=22, events=POLLIN|POLLPRI}, {fd=23, events=POLLIN|POLLPRI}, {fd=24, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN}, {fd=29, events=POLLIN}, {fd=10, events=POLLIN}], 9, 0) = 0 (Timeout) <0.000009>

                C'est tout ce que j'ai vu de pertinent, mais encore une fois si je dois regarder autre chose dites le moi.

                Merci !
  • # scheduler d'I/O

    Posté par . Évalué à 1.

    Est-ce qu'il existe une option du noyau qui permettent de faire en sorte que tous les process auront toujours accès au disque, quitte à perdre un peu de temps sur les gros transferts.

    Essaye d'utiliser deadline à la place de cfq... (cf. http://www.mjmwired.net/kernel/Documentation/block/switching(...) )
  • # puisque la piste du processus noyau semble la bonne ...

    Posté par . Évalué à 3.

    peux-tu préciser ta configuration ?

    Quelle distribution utilises-tu ? Utilises-tu le noyau fourni par cette dernière ou bien un noyau que tu as configuré ?
    As-tu réinstallé ton système ou bien as-tu fais une mise à jour ?

    Ton périphérique LVM dm-0 est-il créé dans une partition de disque dur ou bien au dessus d'un raid ?

    Ensuite, peux-tu donnez le partitionnement du périphérique dm-0 et enfin préciser pour chaque partition, le système de fichiers utilisé, l'endroit où il est monté et les options de montage?


    L''un des treads noyau flush-254:0 ou jbd/2 semble vouloir écrire des données et faire appel à l'autre thread et cela semble bloquer le système.

    Utilises-tu un système de fichiers journalisé ? J'ai vu dernièrement qu'il y a des problèmes avec ext4.

    Peux-tu rebooter sur une version du noyau plus ancienne ? Le problème est-il toujours présent ?

    Bon courage.
    • [^] # Re: puisque la piste du processus noyau semble la bonne ...

      Posté par . Évalué à 3.

      La configuration du LVM c'est deux disques SATA 7200 rpm, un 1 To et un 640 Go. Je les ai simplement "collé" pour faire mon volume, pas de RAID donc.

      J'utilise ArchLinux, noyau Arch qui est un 2.6.32 de base + un patch qui ne modifie presque rien.
      Là je suis en train de compiler un 2.6.33-rc3, je vais voir si ça change.
      Si ça ne change rien, je testerai un 2.6.31 pour confirmer, mais je suis presque sûr qu'avant le 2.6.32 je n'avais pas ce soucis.

      Le partitionnement du volume est très simple, une seule partition qui prend toute la place disponible, c'est du ext4 monté sur mon home (/home/sphax) et les options de montage c'est juste "defaults" dans mon fstab.
      • [^] # Re: puisque la piste du processus noyau semble la bonne ...

        Posté par . Évalué à 2.

        J'utilise un noyau 2.6.32.2 compilé par mes soins sur une distribution slackware 12.2 et mes partitions sont formatées en reiserfs. Donc je ne pas réaliser de tests pour toi.

        Sur quel disque ta partition racine se trouve-t-elle ? De nombreuses écritures sur cette partition freezent-elles ton système ?

        Peux-tu remonter ta partition lvm en changeant les options de montages ?
        ATTENTION, d'après linux magazine n°122 de décembre 2009, activer l'option journal_checksum peut provoquer des corruptions sur les noyaux 2.6.31 et 2.6.32.

        Deux patches concernant ext4 ont été ajoutés depuis le tout nouveau 2.6.32.3. Je ne sais pas si cela solutionnera tes problèmes, mais tu peux tester ce dernier noyau.

Suivre le flux des commentaires

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