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.
Forum Linux.noyau Flush disque qui fait "freezer" la machine
6
jan.
2010
# Si la piste du processus noyau est la bonne ...
Posté par slack . Évalué à 6.
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 NeoX . Évalué à 3.
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 254crw-rw---- 1 root root 254, 0 2010-01-06 09:41 rtc0
[^] # Re: Si la piste du processus noyau est la bonne ...
Posté par Sphax . Évalué à 2.
# 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 neologix . Évalué à 2.
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 Sphax . Évalué à 1.
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted quand j'utilise strace -T -p
- cat /proc/meminfo
MemTotal: 2057484 kBMemFree: 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 Sphax . Évalué à 1.
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 neologix . Évalué à 1.
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 Sphax . Évalué à 2.
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 0x00000000ffff880003e60d60 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 !
[^] # Re: Si la piste du processus noyau est la bonne ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La tu as des pelles d'erreur de read().
"La première sécurité est la liberté"
[^] # Re: Si la piste du processus noyau est la bonne ...
Posté par Sphax . Évalué à 2.
# scheduler d'I/O
Posté par Bruno Muller . Évalué à 1.
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 slack . Évalué à 3.
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 Sphax . Évalué à 3.
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 slack . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.