USBデバイス(カメラ、HDD、メモリカード)との間でファイルをコピーすると、システムが非常に遅くなります。たとえば、ウィンドウを閉じたい場合はマウスを動かしますが、マウスカーソルが動くまでに約2秒以上かかります。最後にカーソルをxの上に置いてクリックすると、10秒以上何も起こりません。すべてのデスクトップ効果を無効にしてこれを試しましたが、問題は解決しません。
ソフトウェア:Linux Mint 9 KDEハードウェア:
私にとって、このハードウェアでこのソフトウェアを実行しても問題は発生しません。USBを使用してファイルをコピーするまで問題は発生しません。これを理解するためにどこから始めればよいですか?私はグラフィックスドライバーが問題の一部である可能性があると思っていますが、確かではありません。
linuxesのメモリ管理に巨大なページがある問題 があるようです。ほとんど発生しませんが、気づいたようです。
これは、記事によると、何が起こったかについての私の非常に単純化された説明です。
運が悪いと、プロセスはメモリアクセスを発行した瞬間にスタックします。これは、透過的なヒュージページが有効になっている場合、メモリアクセスが同期圧縮(メインメモリのデフラグ)をトリガーする可能性があるため、同期が完了する前にメモリアクセスが終了しないためです。これ自体は悪いことではありません。しかし、(たとえば、USBへのバッファリングされたデータの)ライトバックが同時に行われると、圧縮が停止し、ライトバックが完了するのを待ちます。
したがって、すべてのプロセスは、遅いデバイスがバッファリングされたデータの書き込みを完了するのを待つことになります。
OPと同様にメインメモリをアップグレードすると、問題の遅延に役立つ場合があります。しかし、そのオプションを考慮しない人のために、2つの明白な回避策があります。どちらもカーネルの再コンパイルが必要です。
私が見つけた唯一のトリックは本当に機能します: Gnome、nautilusがUSBにファイルをコピーすると、100%またはそれに近いところで停止します
パワーユーザーのトリックを試したい場合は、/ proc/sys/vm/dirty_bytesを15728640(15 MB)のように設定することで、Linuxが使用するバッファーのサイズを減らすことができます。つまり、アプリケーションは実際の進捗状況よりも15MB以上多く取得することはできません。
副作用として、この設定ではコンピューターのデータ書き込みスループットが低下する可能性がありますが、全体として、プログラムが大量のデータを書き込んでいる間、プログラムが長時間実行されていることと、プログラムはその仕事を終えたように見えますが、カーネルが実際の仕事をするので、システムはひどく遅れています。 dirty_bytesを適度に小さい値に設定すると、空きメモリが不足して突然大量のデータを書き込むプログラムを実行したときにシステムが応答しなくなるのを防ぐのにも役立ちます。
ただし、小さすぎないようにしてください。カーネルがバッファを通常のハードドライブに1/4秒以下でフラッシュできるというおおよその見積もりとして15MBを使用します。それは私のシステムが「だらしない」と感じないようにします。