昨日、私はRAMが3 GBであるのに、書き込み速度が7 MB / sの低速な単一の8 GBファイルをUSBにコピーしていました。システムをコピー中に、カーソルを移動することさえできなかったポイントまで凍結しました。
私はなんとかテキストコンソールにログインし、実行iotop
したところ、指定されたプロセスkswapd0
がIOの99.99%を使用していることがわかりました。
回避策があり、大きなファイルをコピーしてもシステムが使用できなくなりますか?
昨日、私はRAMが3 GBであるのに、書き込み速度が7 MB / sの低速な単一の8 GBファイルをUSBにコピーしていました。システムをコピー中に、カーソルを移動することさえできなかったポイントまで凍結しました。
私はなんとかテキストコンソールにログインし、実行iotop
したところ、指定されたプロセスkswapd0
がIOの99.99%を使用していることがわかりました。
回避策があり、大きなファイルをコピーしてもシステムが使用できなくなりますか?
回答:
このバグレポートによると、次の行を追加して解決しました
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
/etc/sysctl.confに
そして実行中
sudo sysctl -p
私は同様の問題に遭遇しました。私のものは64ビットUbuntu 14.04です。だから、長い闘争の後、私の問題を解決する答えを見つけました。簡単に使用できるように、上記の回答で使用した以下のコマンドを追加しました。詳細な説明については、回答を確認してください。
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
上記のコマンドを使用した後、システムはファイルのコピーで正常に動作し始めました。
フラッシュドライブにコピーするときにシステムがフリーズするという同様の問題が発生しています。私はそれに関するバグレポートを提出しました:https : //bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648
回避策として、スワップを無効にすると問題が完全になくなることがわかりました。
はい、実際にディスクに書き込まれる前に書き込み済みとしてマークする必要があるデータの量を指定して微調整できるカーネル設定があります。それらのかなり包括的な説明については、こちらをご覧ください。特に、適切に機能するdirty_ratioの値を検索する必要があります(通常、デフォルトではデスクトップ/ラップトップには高すぎますが、誰もが使用できるマジックナンバーはありません)。
ファイルをexfat
ドライブにコピーするときに同様の問題が発生しました。ext4
USBハードドライブでファイルシステムを使用する際の問題が少なくなりました。