最大スループットのためのLinuxディスクキャッシュ動作の調整


12

ここで最大スループットの問題に直面しているため、ノブを調整する方法についてのアドバイスが必要です。バックアップ配布用に10Gbitファイルサーバーを実行しています。これは、LSI MegaRAIDコントローラ上の2ディスクのS-ATA2セットアップです。サーバーは24gigのメモリも取得しました。

最後にアップロードしたバックアップを最大スループットでミラーリングする必要があります。

「ホット」バックアップ用のRAID0では、書き込みが約260 MB /秒、読み取りが約275 MB /秒です。サイズが20GBのtmpfsをテストすると、約1GB /秒になります。この種のスループットが必要です。

Linuxの仮想メモリサブシステムを調整して、最後にアップロードされたファイルをディスクに書き出さずにできるだけ長くメモリにキャッシュする(またはさらに良い方法:ディスクに書き込んでメモリに保存する)にはどうすればよいですか?

次のsysctlをセットアップしましたが、期待されるスループットを提供しません。

# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000

理論上、これ I / Oのキャッシュに16GBを与え、ディスクへの書き込みまで数分待つ必要があります。それでも、サーバーのベンチマークを行っても、書き込みに影響はありませんが、スループットは増加しません。

ヘルプまたはアドバイスが必要です。


できるだけ早く書き始める方が理にかなっていますか?そうしないと、最大バッファサイズに達し、突然停止します。それがずっと書いていたなら、それはあなたにより多くの時間を与える。
ザンリンクス

私のアプリケーション(ベースlinux + vsftpd)は4GB(合計24GB)未満を使用するため、バッファ用に20GBのメモリがあります。私のバックアップは20GB以下です。バックアップの実行後にそれらをバッファに書き込み、ディスクに順番に書き込むことができる場合、バックアップソース(仮想サーバー)のダウンタイムを大幅に削減できます。PS:サーバーはその後停止する可能性がありますが、問題ありません。回復に30分かかりました:)
ピーターマイヤー

ネットワーク経由でデータを転送するために使用しているアプリケーションが、ディスクに同期しているように聞こえます。データがキャッシュ内に収まるように、それを行わないようにする必要がありますが、ディスクが保持できる速度よりも速くデータを大量にバーストできるようにしたいのはなぜですか。それはどこかで設計上の欠陥を指摘しています。
-psusi

これは欠陥のように思えます。バックアップソリューションでは、サーバーを常にシャットダウンする必要はありません。
-psusi

1
@PeterMeyer:RAMがたくさんある場合でも、書き込みが開始されるのを待つのは間違いです。まったく意味があるのは、ディスクに到達する前にファイル(一時ファイルなど)を編集または削除する場合だけです。バックアップはそれを行いません。バックグラウンド書き込みをできるだけ早く開始したい場合。1または2にごbackground_ratioを設定する
斬Lynxの

回答:


6

設定した変数を見ると、書き込みパフォーマンスにほとんど関心があり、停電によるデータ損失の可能性は気にしていないようです。

遅延書き込みのオプションと、非同期書き込み操作でのライトバックキャッシュの使用のみが可能になります。同期書き込み操作ではディスクへのコミットが必要であり、遅延書き込みは行われません。ファイルシステムが頻繁なページフラッシュと同期書き込みを引き起こしている可能性があります(通常、ジャーナリング、特にdata = journalモードのext3が原因)。さらに、「バックグラウンド」ページフラッシュでさえ、キャッシュされていない読み取りや同期書き込み干渉するため、速度が低下します。

一般に、何が起こっているのかを確認するには、いくつかのメトリックを使用する必要があります。pdflushによってI / O作業が行われるのを待機しているコピープロセスが「D」状態になっていますか。ディスクに大量の同期書き込みアクティビティがありますか?

他のすべてが失敗した場合は、明示的にtmpfsファイルシステムをセットアップして、バックアップをコピーし、事後にディスクとデータを同期することを選択できます-inotify を使用し自動的に

読み取りキャッシュの場合、処理は非常に簡単です。ファイルのコンテンツをバッファキャッシュにロードするようカーネルに通知するパラメーターを持つfcoretools fadviseユーティリティがあり--willneedます。

編集:

vm.dirty_ratio = 70

理論的には、これによりI / Oのキャッシングに16GBが与えられ、ディスクへの書き込みまで数分待つ必要があります。

これはテストシナリオに大きな影響を与えることはありませんでしたが、理解には誤解があります。dirty_ratioパラメータは、システムの合計メモリの割合ではなく、システムの空きメモリの割合です。

より詳細な情報を含むWrite-Heavyロードのチューニングに関する記事があります。


はい、書き込み後のパフォーマンスです。バックアップをバックアップスレーブにファンアウトするのにかかる時間は、私の心配ではありません。プライマリバックアップサーバーに障害が発生し、バックアップがバックアップスレーブに到達しない場合、再送信用のスクリプトも用意されています。PS私はすでにリンクを読んで、それに応じて調整しました。無料vsバッファリングvs合計のミスでごめんなさい。
ピーターマイヤー

3

または、単にディスクを追加してください...持っているドライブアレイ構成は、必要な全体をサポートしていません。これは、実際のニーズに合わせてソリューションを再設計する必要がある場合です。これはバックアップにすぎないことを理解していますが、気の毒な修正を避けることは理にかなっています。


同意した。いくつかのSATA(SATA?真剣に?)ドライブが275MB / sを維持する方法はありません。また、それらから得られるひどいIOPについても話していません。
アダプター

1
私は彼がどこに向かっているのかを見ることができます-これは単なるデータのバックアップ先であるため、彼は停電による時折のデータ損失の可能性を気にしません。そして、利用可能な最大スループットを提供することにより、バックアップウィンドウに必要な時間を最小限に抑えたいと考えています。この方法で20 GBのデータを30秒未満で書き込むことができます。何らかの理由でバックアップにダウンタイムやサービスへの影響が含まれる場合、20分よりも30秒の方が確実に簡単です。
the-wabbit

完全に正しい。同期中にダウンしている仮想マシンイメージ(計算ノード用の非常に小さいイメージ)を同期しています。アプリはtarのように動作します| ssh、しかしftpを使用。そしてまあ、シミュレーションを実行する必要があります... :)
ピーターマイヤー

1
SATAの品種は関係ありません。7200RPMの非エンタープライズディスクは、単にスループットまたは遅延を保証できません。
アダプター

1
@adaptr、バックアップは順次書き込みになります。
psusi

1

メモリキャッシュを使用すると、何かがおかしくなった場合、メモリ内にありディスクに保存されていないデータが失われるため、データが失われる可能性があります。

ただし、ファイルシステムレベルで行うべきチューニングがあります。

たとえば、ext4を使用している場合、マウントオプションを試すことができます。

バリア= 0

つまり:「jbdコードで書き込みバリアの使用を無効にします。書き込みバリアは、ディスク上のジャーナルコミットの適切な順序付けを強制し、揮発性ディスク書き込みキャッシュを安全に使用します。パフォーマンスが低下します。マウントオプション「barrier」および「nobarrier」は、他のext4マウントオプションとの一貫性を保つために、バリアを有効または無効にするためにも使用できます。

詳細:http : //www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt


高度に調整されたXFS を使用してます。上記のコメントで調整されている点についての詳細:)
ピーターマイヤー

ファイルシステムはmkfs.xfs -l lazy-count = 1、version = 2、size = 256m -i attr = 2 -d sunit = 512、swidth = 1024で作成され、rw、noatime、logbufs = 8で
ピーターマイヤー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.