web-dev-qa-db-ja.com

大量のファイルをUSBドライブにコピーすると、デスクトップがロックされるのはなぜですか？

私のデスクトップは通常、負荷が高い場合でも非常に応答性が高くなります。しかし、ファイルをUSBドライブにコピーすると、しばらくすると常にロックされます。 「ロックアップ」とは、次のことを意味します。

  • あるウィンドウから別のウィンドウにフォーカスを移動するには、10〜20秒かかる場合があります
  • デスクトップの切り替えには10〜20秒かかる場合があります
  • ビデオはもう更新されません（YouTubeでは、オーディオは引き続き再生され、ビデオのみがフリーズします）

これが発生した場合、システム負荷は例外的に高くはありません。 xosviewに白がたくさん表示され、カーネルがどこかでビジーであることを示すことがあります。

一見すると、ファイルをUSBドライブにコピーすると、どういうわけかcompizに干渉するように見えますが、接続がどのようなものか想像できません。

htopの出力は次のとおりです。

Output of htop shortly after the hang

2分間のハング中のiostat -c -z -t -x -d 1の出力は次のとおりです。

19.07.2012 20:38:22
avg-cpu:  %user   %Nice %system %iowait  %steal   %idle
           1,27    0,00    0,38   37,52    0,00   60,84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdg               0,00     2,00    0,00  216,00     0,00 109248,00  1011,56   247,75  677,69    0,00  677,69   4,63 100,00

ご覧のとおり、外付けハードディスクのみがアクティブです。完全なログは次のとおりです。 http://Pastebin.com/YNWTAkh4

ハングは20:38:01に開始し、20：40：19に終了しました。

ソフトウェア情報：

  • openSUSE 12.1
  • KDE 4.7.x
  • ファイルシステム：内部ハードディスク上のreiserfsとbtrfs、USBドライブ上のbtrfs
linuxkdebtrfs
11
Aaron Digulla

このファイルシステムのI/Oプロセスが時々引き継ぐので、私の最初の推測はbtrfsでした。しかし、Xがロックする理由は説明できません。

割り込みを見ると、次のことがわかります。

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        179          0          0          0          0          0          0          0  IR-IO-APIC-Edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-Edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-Edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-Edge      i8042
 16:    3306384          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1

まあ、当たり前。 USBドライバーはグラフィックカードと同じIRQを使用し、チェーンの最初にあります。それがロックすると（ファイルシステムが何か高価なことをするため）、グラフィックカードは（そしてネットワークも）飢えます。

4
Aaron Digulla

openSUSE 12.1のlinux-3.1カーネルで同様の問題が発生し、透過的な巨大ページを無効にすると次のことが役立つことがわかりました。

echo never > /sys/kernel/mm/transparent_hugepage/enabled

根本的な問題は、アプリケーションが4MB以上を割り当てると、カーネルがそれに巨大なページを与えようとすることです。そのためには、連続した4MBのRAM全体が必要になります。ここで、低速のUSBデバイスに書き込む必要のあるダーティページが多数ある場合は、そのIOが終了するのを待ってから、メモリ割り当てを続行します。

2
Bernhard M.

前述のように、これはおそらくカーネルのhugepagesの設定に関係しています。私はこの問題を抱えている何人かの人々を知っています。あなたはそれについてのいくつかのドキュメントをウェブで見つけることができます、例えば。

次のようにして、セットアップの問題を完全に修正しました。 YMMVに注意してください。以下のすべての修正が必要なわけではなく、おそらく十分ではないでしょう。正直なところ忘れてしまったかもしれません。とにかくそれは私のセットアップであり、それは機能します。

  • Linux-ckカーネルを使用する
  • echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
  • echo never > /sys/kernel/mm/transparent_hugepage/defrag
1
AF7