大きなファイルをUSBにコピーすると、システムがフリーズ/応答しない/使用できない


50

昨日、私はRAMが3 GBであるのに、書き込み速度が7 MB / sの低速な単一の8 GBファイルをUSBにコピーしていました。システムをコピー中に、カーソルを移動することさえできなかったポイントまで凍結しました。

私はなんとかテキストコンソールにログインし、実行iotopしたところ、指定されたプロセスkswapd0がIOの99.99%を使用していることがわかりました。

回避策があり、大きなファイルをコピーしてもシステムが使用できなくなりますか?


12
このバグは...そうばかげている
king_julien

はい、Ubuntuだけでなく、他のDebianフレーバーでも発生します。Kali LinuxとParrot OSでも同じ問題が発生しました。Kaliは最悪のシナリオを持ち、オウムはそれをスムーズにしますが、非常に大きなサイズではハングします。Linux Kernelの問題と、それがどのように書かれているのだと思います。これは、これまでのLinuxの最悪の悪夢です。
Mohith7548

回答:


32

このバグレポートによると、次の行を追加して解決しました

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

/etc/sysctl.confに

そして実行中

sudo sysctl -p

12
上記の行が何をするのかを説明することに注意してください?
nsane

3
@ nisargshah95申し訳ありませんが、手がかりはありません。自分で検索してください;-)
フィリップガショー

4
@ nisargshah95問題の詳細は、unix.stackexchange.com / a / 107722/ 52205
Rmano

1
ありがとう、私はちょうど私のUbuntu 16.04がこれらの2行なしで2つの1.4 GBファイルをUSBに書き込むことができないことを発見しました、私は何時間も凍りついていました、この解決された問題オン。
マイク

1
値は5と60でした。これらは操作に使用されるメモリの割合を制御し、絶対バイト値dirty_background_bytesdirty_bytes使用します。この問題は2番目の回答で修正しましたが、永続的に追加するには、この回答を参照してください。そのため、メモリをアップグレードするときにパーセント値を使用して調整します。sysctl.conf
PeterM

20

私は同様の問題に遭遇しました。私のものは64ビットUbuntu 14.04です。だから、長い闘争の後、私の問題を解決する答えを見つけまし。簡単に使用できるように、上記の回答で使用した以下のコマンドを追加しました。詳細な説明については、回答を確認してください。

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

上記のコマンドを使用した後、システムはファイルのコピーで正常に動作し始めました。

@Rmanoに感謝します


2
NAS共有が遅い12.04システムでは、比率の設定は役に立ちませんでした。しかし、ここで提案されているようにバイトを直接設定した後、NASにコピーしている間、私のシステムは再び使用可能になります。
mivk

6
この質問は3年前のものであり、ペンドライブへのコピー中に使用できないシステムにならないようにするためには、これが必要です。情報:ペンドライブがext4のようなLinux fsを使用してフォーマットされている場合、これは起こりません。「使用不可能なシステム」と言ったとき、マウスポインターが反応しなくなり、画面上を移動するように主張する必要があります。システムモニターを見ると、異常なリソースの使用はありません。カーネルの人々はすべて第6世代Intel CPUとSSDドライブを使用していますか?なぜ彼らはテスト中にこれに気付かないのでしょうか。
半蔵H

3
@HatoruHansou私も同じことを感じています。新しいDebian Stretchをインストールしたばかりで、このエラーもここにあります。私はそれがディストリビューションに依存するのではなく、カーネルソースに依存することを知っていますが、男性、なぜこれがまだ修正されていないのですか?
マレキー

1
@Marecky読んだ後、dirty_bytesはusbだけのものではないようです。それらはすべてのI / Oに影響するため、エコー処理を行った後、ペンドライブだけでなくシステム全体を変更します。現在のセッションについてのみ、私は思う。新しいストレージデバイスでは、カーネルの現在の値が微調整されているようです。遅いペンドライブは副作用として苦しみます。申し訳ありませんが、リンクはありませんが、グーグルで簡単に見つけることができます。
半蔵H

3
永続化するには、この回答を参照してください
PeterM

5

フラッシュドライブにコピーするときにシステムがフリーズするという同様の問題が発生しています。私はそれに関するバグレポートを提出しました:https : //bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648

回避策として、スワップを無効にすると問題が完全になくなることがわかりました。


1
残念ながら、これはUbuntu 16.04では機能しませんでした。
Programster

Ubuntu 16.04.3 LTS-Alienware 17 R2ラップトップでも動作しませんでした。
AnthonyK

4

はい、実際にディスクに書き込まれる前に書き込み済みとしてマークする必要があるデータの量を指定して微調整できるカーネル設定があります。それらのかなり包括的な説明については、こちらご覧ください。特に、適切に機能するdirty_ratioの値を検索する必要があります(通常、デフォルトではデスクトップ/ラップトップには高すぎますが、誰もが使用できるマジックナンバーはありません)。


2
ねえ、ラップトップの仕様に基づいて設定する必要のある数字を教えてください。askubuntu.com/questions/713723/を

1

ファイルをexfatドライブにコピーするときに同様の問題が発生しました。ext4USBハードドライブでファイルシステムを使用する際の問題が少なくなりました。


1
ext4でもこの問題がありました
PeterM

Fedora 27(カーネル4.17.5-100)は、USB接続の回転錆からUSB接続のフラッシュスティックにコピーします。これは、ミッドフェードでスクリーンロッカーをフリーズするまでのようです。:-( ~~~
デビッドトンホーファー

1

USBディスクからSATAディスクに大量のファイルをコピーしているときに、ubuntu 19.10で(2019年に)まったく同じ問題が発生しました。両方のファイルシステムはext4です。スワップをオフにすると、問題はなくなりました。ディスクバッファのメモリ割り当てのバグのように見えます-明らかに、カーネルはそのような状況ではできるだけ多くのメモリをディスクバッファに割り当てようとしますが、それは意味がありません(スワップでディスクバッファを作成する...)、またはキャッシュに使用できるメモリサイズを誤って計算するだけです...

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.