SSDでの大量の書き込みアクティビティにより、システムのパフォーマンスが低下します


13

大量の書き込みアプリケーションを実行すると、システム全体の速度が低下することに気付きました。これをさらにテストするために、これを実行して(比較的)低CPU、高ディスクアクティビティを実行しました。

john -incremental > file_on_SSD

これにより、毎秒何万もの文字列がシステムディスク上のファイルに送り出されます。

これを行うと、マウスが遅れ、TTYが応答しなくなり、アプリケーションが「フェード」し、一般的にコンピューター全体が使用できなくなります。最終的にControl + Cができるjohnと、システムは数秒後に完全な強度に戻ります。

これは極端な例ですが、高速ソースからの大きなファイルのコピーやトランスコーディングなど、書き込みの負荷が少し少ないアクティビティで同様の問題が発生します。

私のメインOSディスクは、EXT4を備えた非常に高速なSSD(OCZ Agility 60GB)です。私の書き込みした場合johnEXT4との機械的なディスクへの出力レートがたくさん遅いものの、私は(SSDは毎秒〜42,000の単語を行い、機械は8000ワット/秒をして)同じスローダウンを経験しません。スループットが関係する場合があります。メカニカルディスクもシステムとは関係ありません。それは単なるデータです。

そして、カーネル2.6.35-2を使用していますが、この問題は、SSDを入手したときに、おそらく.31またはその頃の何かを使用していたときに気づきました。

それでは、減速の原因は何ですか?EXT4の問題?カーネルの問題?SSDの問題?上記のすべて?他に何か?

追加のテストを実行する必要があると思われる場合は、何をすべきかを伝えるコメントをドロップするだけで、質問に結果を追加します。


また、使用しているSSDについても言及する必要があります。すべてのSSDが同等というわけではありません。
クリスチャンシウピトゥ

@クリスチャン:追加。OCZの敏 '性です。
オリ

回答:


12

これはしばらくの間既知の問題でした。BtrfsのようなSSDで調整されたFSを使用すると役立つ場合がありますが、そうでない場合があります。

最終的に、これはIOスケジューラ/メモリ管理システムのバグです。最近、この問題に対処することを目的としたパッチがいくつかありました。「修正:Linuxデスクトップの応答性の問題?」を参照してください

これらのパッチは最終的にメインラインカーネルに組み込まれる可能性がありますが、現時点では、この問題を修正する場合はおそらく独自のカーネルをコンパイルする必要があります。


2
私が正しく理解していれば、これに対するパッチはlinux 2.6.37に入るはずです。
JanC

1

LinuxでSSDのパフォーマンスを向上させるために確認できることがいくつかあります。

  1. マウントポイントを「noatime」に設定します。アクセス時間を更新する余分なアクティビティは、通常、ほとんどのユースケースで無駄になります。特に、単一行を継続的にファイルに送り込む場合、アクセスごとにファイルシステムに複数の更新を強制します。

  2. エレベーターを確認してください。ほとんどのディストリビューションのデフォルトエレベーターは、ランダムアクセスの回転プラッター用に設定されています。SSDは追加のロジックを必要としないため、エレベーターをnoopに設定すると、ハードウェアに書き込みを管理させることでパフォーマンスを向上させることができます。

  3. ライトスルーvライトバックキャッシュ。これはもう少し難解ですがhdparm、デバイスで使用されるキャッシュ方法を確認できます。ライトバックキャッシングは、ライトスルーと比較してSSDのパフォーマンスにプラスの影響を与える可能性があります。


@nzwulfinはエレベーターの設定についてもう少し書いていただけますか?
グジェゴシWierzowiecki

SSDのパフォーマンスは良好だったようです。苦しむのはそれ以外のすべてです。
トールビョーンラヴンアンデルセン

0

ファイルキャッシングは、おそらくワークロードに合わせて誤って調整されています。残念ながら、Linuxカーネルはこれを自動的に処理できないほど愚かであり、RAMが多くブロックデバイスが十分に遅い場合、デフォルトはかなり悪いです。詳細については、https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/を参照してください。

/etc/sysctl.confどちらかを変更してみることをお勧めします

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

書き込みキャッシュによるRAMの負荷を大幅に軽減し、カーネルが他のタスクをより適切に処理できるようにします。これにより、遅延が改善され、スループットが低下します。

別の可能性は、キャッシュを増やすことですが、プロセスが常に新しいデータを常に書き込み続ける場合、キャッシュがいっぱいになった場合、非常に悪いレイテンシーが発生します。あなたがそれを試してみたいなら、あなたは次のようなことをすることができます

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

*_ratio設定は使用可能なRAMの割合を参照することに注意してください。より適切に制御したい場合は、*_bytes設定を使用します。私は個人的にワークステーションに次の設定を使用しています:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

これにより、バックグラウンド書き込みキャッシュが50 MBに制限され、200 MBがキャッシュにある場合は同期書き込みが強制されます。

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