web-dev-qa-db-ja.com

NFS / DRBD / XFSパフォーマンスの問題

xFSとdrbdの上にNFSがあり、恐ろしいパフォーマンス（iostat/iotopに示されているように約1MB /秒の読み取り/書き込み）を提供します。xfsボリュームのプロパティは次のとおりです。

meta-data=/dev/drbd0             isize=256    agcount=4, agsize=52427198 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=209708791, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sAS1068Eコントローラと2つのWD1TBディスクを備えたDellBoxがあります。ボリュームは現在、次のプロパティでマウントされています。

rw,noatime,nodiratime,attr2,nobarrier,logbufs=8,noquota

ファイルシステムには、サイズが約50〜100kの小さなファイルが大量に含まれており、ディレクトリツリー内に散らばっています。

ReadAhead値（現在は無効）とxfsマウントオプションを試してみましたが、これまでのところ何も成功していないようです。

Iotopで、kdmflushがiowaitを引き起こすプロセスであることに気づきました。このセットアップのパフォーマンスを改善するための提案はありますか？

linuxnfsxfsdrbd
2
tmsmaster

簡単に言えば、ディスクシステムはあなたがやろうとしていることに対してひどくアンダースペックであるということです。

1MB /秒はかなり典型的なランダムIO SATAディスク上のRAID1でのパフォーマンス。たとえば、wmarowのiopsおよびRAID計算機を参照 ここ 。2つのBarracuda ES.2SATAディスクを配置するRAID10（実質的にRAID1と同じ）では、100％の書き込みを0％の書き込みキャッシュヒットに設定すると、推定0.57MB /秒のスループットが示されます。実際のパフォーマンスは異なる場合がありますが、大幅な違いはありません。

Kdmflushを責任のあるカーネルプロセスとして特定するという事実は、これを補強します-ディスクシステムが負荷を処理できない場合、このプロセスでiowaitに費やされる時間が長くなります。 kdmflushは、デバイスマッパーのフラッシュプロセスであり、他の場所での読み込みが原因で延期された作業を処理します。

これを改善するには、いくつかの方法があります。より多くのディスクを取得する、より良いディスクを取得する、またはコントローラーで書き込みキャッシュをオンにする。

書き込みキャッシュをオンにすると、BBUも取得する必要があります。ただし、BBUはオンボードSAS1068Eのオプションではない可能性があるため、PCI-eコントローラーを入手する必要がある場合があります。

私が使用していたRAIDコントローラー（3ware 9550だと思います）で書き込みキャッシュが有効になっていないと、DRBDでひどいパフォーマンスが見られました。 DRBDのロードはほとんどランダムIOであるため、書き込みキャッシュはパフォーマンスに大きな影響を及ぼします。

SAS1068Eは非常にローエンドであり、問​​題の原因になっている可能性もあります。より多くのディスクまたはより良いディスクを入手する場合は、より良いコントローラーも入手することをお勧めします。

グーグルですばやく検索すると、使用しているのと同じモデルのRAIDコントローラーで 同様にパフォーマンスが低い であることがわかります。

3
Daniel Lawson

1MB /秒はおなじみのようです。推測では、問題はXFSが少なく、DRBDレイヤーが多いことです。何らかの理由でDRBDでのブロックレプリケーションが遅い場合、kdmflushが大量のIOWAITを引き起こしていることは完全に合理的です。その速度は、2つのDRBDホスト間のネットワーク接続が適切にネゴシエートされていないように聞こえます。

繰り返しますが、推測ですが、その速度はTCP接続なしのTCP Windowsが正しく機能しているように聞こえます。トラフィックは、多数のパケットと1つのackではなく、packet、ack、packet、ack、packet、ackのように見えます。

IotopがNFSサーバー自体ではなくNFS共有をマウントしているクライアントで実行されている場合は、その接続とDRBD接続を確認してください。

0
sysadmin1138

DRBDレプリケーションには10Mbpsを超えるネットワークを使用してください。 DRBDデバイスのディスクI/Oは、ネットワーク速度に制限されています（C以外のプロトコルを使用している場合を除きます。これは、が必要な場合に実行することですデータが破損して役に立たなくなる）。問題の原因がネットワークであることをテストするには、プライマリをセカンダリから切断すると、I/Oレートがすぐに上昇する可能性があります。

0
womble