USBデバイスとの間でファイルをコピーするときにパフォーマンスが低下する


11

USBデバイス(カメラ、HDD、メモリカード)との間でファイルをコピーすると、システムが非常に遅くなります。たとえば、ウィンドウを閉じたい場合はマウスを動かしますが、マウスカーソルが動くまでに約2秒以上かかります。最後にカーソルをxの上に置いてクリックすると、10秒以上何も起こりません。すべてのデスクトップ効果を無効にしてこれを試しましたが、問題は解決しません。

ソフトウェア:Linux Mint 9 KDEハードウェア:

  • Asus SLIマザーボード
  • NVidia 6600 GPU
  • 2 GB RAM
  • 2 GBスワップ
  • AMD Athlox X2 @ 3800+

私にとって、このハードウェアでこのソフトウェアを実行しても問題は発生しません。USBを使用してファイルをコピーするまで問題は発生しません。これを理解するためにどこから始めればよいですか?私は、グラフィックスドライバーが問題の一部である可能性があると考えていますが、確かではありません。


2
USBポートがUSB 2.0対応であることを確認してください。一部のUSBポート、特にデスクトップの前面には、USB 1.0のみが使用されていました。また、BIOS設定がUSBパフォーマンスに最適であることを確認してください。一部のUSB速度設定、および/またはパフォーマンスに影響する可能性のあるUSBレガシー設定がある可能性があります。
Tim Kennedy

デバイスはNTFSとしてフォーマットされていますか?もしそうなら、私はそれをFAT32(またはLinuxでのみ使用する予定の場合はEXT4)として再フォーマットしてみます。
RobinJ

3
Linuxのメモリ管理の巨大なページに問題があるようです。ほとんど発生しませんが、気づいたように聞こえます。
artistoex

@artistoex-その記事は私が経験していた行動を完全に要約しています。残念ながら具体的な修正はありません。これが後のバージョンで修正されるかどうか誰でも知っていますか?とにかくアップグレードの時間です。
ジョン

記事にあるように、透過的な巨大ページ機能を無効にしてカーネルを再コンパイルします。
artistoex

回答:


7

linuxesのメモリ管理の巨大なページに問題があるようです。ほとんど発生しませんが、気づいたように聞こえます。

原因

これは、記事によれば、何が起こったかについての私の非常に単純化された説明です。

運が悪いと、プロセスはメモリアクセスを発行した瞬間にスタックします。これは、透過的なヒュージページが有効になっている場合、メモリアクセスが同期圧縮(メインメモリのデフラグ)をトリガーする可能性があるため、圧縮が完了する前にメモリアクセスが終了しないためです。これ自体は悪いことではありません。しかし、(たとえば、バッファされたデータのUSBへの)ライトバックが同時に発生した場合、圧縮が停止し、ライトバックが完了するのを待ちます。

したがって、すべてのプロセスは、遅いデバイスがバッファリングされたデータの書き込みを完了するのを待つことになります。

治す

OPと同様にメインメモリをアップグレードすると、問題の遅延に役立つ場合があります。しかし、そのオプションを考慮しない人のために、2つの明白な回避策があります。どちらもカーネルの再コンパイルが必要です。


2

これは、ここでの私の質問と同じように聞こえます(答えが私にこの質問を示した場合):

/programming/10105203/how-can-i-limit-the-cache-used-by-copying-so-there-is-still-memory-available-for

しかし、理論は完全に異なり、私が使用した解決策はあなたのものとは無関係ですが、完全に機能します。

私はrsyncを使用していたので、--drop-cacheオプションを使用するだけで済みました。(副作用としてコピーが少し遅くなります)


0

私が見つけた唯一のトリックは本当に機能します: Gnome、nautilusがUSBにファイルをコピーすると、100%またはそれに近いところで停止します

パワーユーザーのトリックを試したい場合は、/ proc / sys / vm / dirty_bytesを15728640(15 MB)のように設定することで、Linuxが使用するバッファーのサイズを減らすことができます。これは、アプリケーションが実際の進捗状況より15 MB以上多く取得できないことを意味します。

副作用として、この設定ではコンピューターのデータ書き込みスループットが低下する可能性がありますが、全体として、プログラムが大量のデータを書き込んでいる間、プログラムが長時間実行されていることと、プログラムはその仕事を終えたように見えますが、カーネルが実際の仕事をするので、システムはひどく遅れています。また、dirty_bytesを適度に小さい値に設定すると、空きメモリが不足して突然大量のデータを書き込むプログラムを実行したときにシステムが応答しなくなるのを防ぐのに役立ちます。

ただし、小さすぎないようにしてください。カーネルがバッファを通常のハードドライブに1/4秒以下でフラッシュできるというおおよその見積もりとして15MBを使用します。それは私のシステムが「だらしない」と感じるのを防ぎます。

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