Comment puis-je empêcher [flush-8: 16] et [jbd2 / sdb2-8] de provoquer une absence de réponse à l'interface graphique? [fermé]

11

Environ deux fois par semaine, l’intégralité de l’interface graphique se verrouille pendant environ 10 à 20 secondes sans avertissement lorsque je réalise des tâches simples telles que naviguer sur le Web ou écrire un papier. Lorsque cela se produit, les éléments de l'interface graphique ne répondent pas aux entrées de la souris ou du clavier et l'applet System Monitor affiche une utilisation du processeur 100% IOWait.

Aujourd'hui, j'ai finalement eu le terminal GNOME déjà ouvert lorsque le problème a commencé. Malgré le fait que d’autres applications telles que Google Chrome, Firefox, GNOME Do et GNOME Panel ne répondaient pas, le terminal était utilisable. J'ai exécuté iotop et observé que les commandes nommées [flush-8:16] et [jbd2/sdb2-8] utilisaient alternativement 99,99% IO.

Qu'est-ce que c'est, et comment puis-je les empêcher de provoquer une absence de réponse de l'interface graphique?

Détails

$ mount | grep ^/dev
/dev/sda1 on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=0)
/dev/sdb2 on /home type ext4 (rw,commit=0)
$ cat /proc/swaps 
Filename        Type        Size     Used    Priority
/dev/sdb3       partition   1052252  0       -1

/dev/sda est un OCZ-VERTEX2 et /dev/sdb est un WD10EARS . Voici dumpe2fs /dev/sdb2 et smartctl /dev/sdb --all .

Je ne vois rien d'inhabituel dans dmesg ou /var/log/syslog .

    
posée ændrük 13.03.2011 - 16:16
la source

1 réponse

4

Je vais tenter une théorie:

/dev/sdb1 est peut-être de l'espace d'échange?

Si un élément central de l’interface graphique a été déchargé sur le disque, l’interface graphique ne peut pas continuer tant qu’elle n’a pas reçu ces données. Si le disque d'échange est en veille, cela signifie qu'il reste bloqué jusqu'à ce que le disque réponde.

Je pense que cela donnerait un blocage temporaire, et la période de 10 à 20 secondes correspond au temps nécessaire à un disque en veille pour répondre. Le terminal est probablement toujours réactif car tout ce dont il a besoin est déjà en mémoire vive.

Quelques outils terminaux pour explorer la théorie:

  • hdparm -C /dev/sdX vous indique si un disque est en train de dormir:

    $ sudo hdparm -C /dev/sdb
    /dev/sdb:
    drive state is:  standby
    

    active/idle signifie qu'il est en cours d'exécution. Dans l'état standby ou sleeping , il a cessé de tourner et met du temps à redémarrer. Voir man hdparm .

  • free -m indique combien d'espace de swap est utilisé:

    $ free -m     
                 total       used       free     [...]
    Mem:          5973       4928       1045     [...]
    -/+ buffers/cache:       1091       4882
    Swap:         6234          0       6234
    

    "Swap:" est la ligne appropriée, dans cet exemple, le swap de 6,2 Go est disponible et rien n’est utilisé.

Si tel est le problème, vous pouvez déplacer swap vers sda ou désactiver les spindowns pour sdb.

    
réponse donnée j-g-faustus 13.03.2011 - 22:56
la source

Lire d'autres questions sur les étiquettes