大きなファイルをアーカイブ解除すると、Linuxのクロールが遅くなります
この数ギガバイトの大きさのRARファイルのアーカイブを解除し始めました。コンピューターの速度が非常に遅くなり、ほとんどフリーズしています。マウスを少し動かすことができることもありますが、それだけです。アーカイブ解除プロセスが停止したように見えるので、今私にできることはシステムを再起動することだけです。 Linuxでこのファイルをアーカイブ解除できないと思います。
私はWindowsでこの問題を経験したことはありません。これはどのように修正できますか？
減速はおそらくiowaitが原因で発生しています。 ioniceコマンドを使用すると、作業を続行できます。
ionice-c3コマンド
Nice ユーティリティを使用して、優先度の低いコマンドを実行してみてください。大きなファイルの解凍はCPUに負担をかける可能性があるため、通常、CPUのベンチマークとレビューでパフォーマンスを測定するために使用されるツールの1つです。
例：
$ニース-15./myprogram
指定する数値は、デフォルトのニースレベルの調整です。 -20が最高の優先順位で、19が最低の優先順位です。負の数はrootユーザー用に予約されています。
私も同じ現象がありましたが、答えは見つかったと思います。以前は、1つのディスクでunrarを使用して、読み取りと書き込みを行っていました。これはたくさんあるので、他のすべてのプロセスはディスク上で作業する時間がありませんでした。ここで、unrarに、解凍したアイテムを別のパーティションではなく、別の物理ディスクではなく、別のディスクに配置させます。これにはいくつかの利点があります。
- それははるかに速く進むので、あなたがより遅いコンピュータを持っている時間はより少なくなります。
- コンピュータは、一方のディスクで読み取り、もう一方のディスクに書き込むため、以前のように停止することはありません。言い換えれば、ディスクは作業の総量を分割します。
これは単純な解決策ですが、機能します。
ほぼ200.000個の小さなファイルを含む大きな.Zipファイル（1.4 Gb）でも同様の問題が発生しました。私のUbuntu13.1064ビットは10時間以上かかったでしょう。フリーズすることはなく、システムが実際に遅くなることはありません。解凍が非常に遅いというだけです。
VirtualboxとW764を使用して、上記の仮想マシンソリューションを試しました。驚きがあります。
1）最初に、フォルダーを仮想マシンと共有し、7-Zipと同じ場所（W7の仮想F：ユニット）で解凍しようとしました。運がない、永遠にかかるのと同じくだらない速度。 7-Zipは200Kb/sの初期出力を報告しましたが、停止するまで速度が低下し続けました（100 kb/s未満でETAは7時間ですが、おそらくもっと遅くなり、時間がかかりました）。
2）次に、.Zipファイルを仮想マシンの「ハードディスクドライブ」（仮想マシンがHDDと見なすもの）内に移動しました。 したがって、ファイルはUbuntuとの共有フォルダーにありませんでした。驚いたことに、驚いたことに、2000 Kb/sの出力で、15分もかからなかったので、うまく機能します。
3）ちなみに、7-Zipによると、まったく同じハードウェアを備えた32ビットのWindows 7システム（仮想マシンではない）は約1時間かかり、安定した出力は約500 kb/sでした。 32ビットから64ビットへの変更がファイルの解凍にどのように影響するかはわかりません。比較することをお勧めします。
Ubuntu 13.10 64ビットとext4、W7とNTFSの両方、vm64ビットと32ビットの通常システム。私を本当に当惑させているのは、W7 vmが実際に基盤となるext4ファイルシステムを使用しているという事実です。これはvmであり、それでもこれらの速度を達成しているためです。
一部の教祖がこれを読んで理解してくれることを願っています。これは非常に迷惑で興味をそそるものです。
私は解決策を見つけました。 LinuxにWindows仮想マシンがすでにインストールされています。アーカイブがあるフォルダーを仮想マシンと共有しました。次に、Windows内で、7-Zipを使用してファイルをアーカイブ解除すると、すべてがスムーズに進みました。長い時間がかかりましたが、システムのパフォーマンスに目立った違いは見られませんでした。 7-ZipはLinuxでは使用できません。 Windowsはまだ時々便利です！
大きなアーカイブのアーカイブを解除することは問題ではないはずです。何か他の症状が見られるだけです。
Linuxパーティションは容量に近づいていますか？ 95％以上がいっぱいですか？その場合、多くのファイルシステム（ext3、ext4、reiserfsを含む）の速度が大幅に低下します。
LinuxではディスクI/O速度は問題ありませんか？プログラムは妥当な時間で起動しますか？ファイルマネージャでディレクトリを閲覧するのは速いと感じますか、それとも遅いと感じますか？ bonnie ++やioniceなどのベンチマークプログラムを試しましたか？
アンアーカイバーは使用可能なすべてのメモリを割り当てますか？そのパッケージをアーカイブ解除しようとしている間はtopを参照してください。
デフォルトのcfqディスクI/Oスケジューラは、長時間実行されるディスクアクティビティバースト中に奇妙な問題を引き起こす可能性があります。代わりに、deadlineまたはanticipatoryスケジューラーを試すことができます。たとえば、deadlineはデータベースのワークロードに非常に適している傾向があるため、この場合にも機能する可能性があります。
echo deadline >/sys/block/sda/queue/scheduler
または
echo anticipatory >/sys/block/sda/queue/scheduler
sdaをハードディスクの名前に置き換えます。
これは一時的な変更であり、通常、デスクトップでの使用でcfqを変更することはお勧めしませんが、このアーカイブされていないもの以外のI/Oの問題がある場合は、試してみる価値があります。これがすべてRAMを使い果たしたという理由だけでない限り... :-)
RAMが不足していることが原因である可能性があります。ハードドライブを再パーティション化して大きなスワップパーティションを含めることもできますが、それだけです、AFAIK。
だから私はUbuntu16.04で同様の問題を経験しています。 This 回答は一度は機能したように見えましたが、その後は機能しませんでした。多分それはこれらの分野が何をするかについてもう少し理解している誰かを助けるでしょう。以下に手順を示しますが、参照されている回答から直接取得されています。
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
/etc/sysctl.confに。次に
Sudo sysctl -p