[flush-8：16]および[jbd2 / sdb2-8]がGUIを応答不能にするのを防ぐにはどうすればよいですか？[閉まっている]

週に約2回、Webの閲覧や論文の執筆などの簡単なタスクを行っている間、グラフィカルインターフェイス全体が警告なしに約10〜20秒間ロックされます。これが発生すると、GUI要素はマウスまたはキーボード入力に応答せず、システムモニターアプレットは100％のIOWaitプロセッサ使用率を表示します。

今日、私はついに問題が始まったときにGNOMEターミナルをすでに開いていることがありました。Google Chrome、Firefox、GNOME Do、GNOME Panelなどの他のアプリケーションが応答しないにもかかわらず、端末は使用可能でした。私は走ったiotopとコマンドが名前のことを観察[flush-8:16]し、[jbd2/sdb2-8]交互に99.99％IOを使用していました。

これらは何ですか？また、GUIが応答しなくなるのを防ぐにはどうすればよいですか？

詳細

$ 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あるOCZ-VERTEX2と/dev/sdbあるWD10EARS。ここにとがdumpe2fs /dev/sdb2ありsmartctl /dev/sdb --allます。

dmesgまたはで異常なものは見当たりません/var/log/syslog。

私は理論に挑戦します：

/dev/sdb1 おそらくスワップスペースですか？

グラフィカルインターフェイスの中心的なものがディスクにオフロードされた場合、GUIはそれらのデータを受信するまで続行できません。スワップディスクがスリープしている場合、これはディスクが応答するまでスタックしていることを意味します。

これにより一時的なロックアップが発生し、10〜20秒の期間が、スリープディスクが応答するのにかかる時間に収まると思います。必要なのはすでにRAMにあるため、ターミナルはおそらくまだ応答しています。

理論を探求するいくつかの端末ツール：

• hdparm -C /dev/sdX ディスクがスリープしているかどうかを示します：

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

  active/idle実行中であることを意味します。状態にあるstandbyかsleeping、回転が停止し、再び起動するまでに時間がかかります。をご覧くださいman hdparm。

• free -m 使用されるスワップ領域の量を示します。

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

  「Swap：」は関連する行です。この例では、6.2 GBのスワップが使用可能であり、何も使用されていません。

これが問題になる場合は、スワップをsdaに移動するか、sdbのスピンダウンを無効にすることができます。