web-dev-qa-db-ja.com

ZFSプールの遅い順次読み取り

この問題について関連する質問がありますが、複雑すぎて大きすぎたため、問題をNFSとローカルの問題に分割する必要があると判断しました。また、zfs-discussメーリングリストでこれについて質問してみましたが、あまり成功していません。

同じサーバー上のNFS/CIFSディレクトリ間の低速コピー

概要：設定方法と期待される内容

  1. 4つのディスクを持つZFSプールがあります。ストライプ化された2つのミラーとして構成された2TB RED（RAID 10）。 Linuxでは、zfsonlinux。キャッシュまたはログデバイスはありません。
  2. データはミラー間で分散されます（ZFSにとって重要）
  3. 各ディスクは147MB /秒で並行して読み取り（raw w/dd）できるため、合計スループットは588MB /秒になります。
  4. 同様の4TB REDディスクのベンチマークに基づくと、各ディスクからのシーケンシャルデータの書き込みは約115MB /秒、読み取りは138MB /秒、再書き込みは50MB /秒と予想しています。最近はどのディスクでも実行できるため、100MB /秒以上の読み取りまたは書き込みを期待しています。
  5. 100％IO使用率が4つすべてのディスクで使用されており、シーケンシャルデータの読み取りまたは書き込みが行われている場合、使用率が100％であるときにディスクが100MB /秒を超えて出力することになります。
  6. このプールでは、1つのディスクで約2倍の書き込み、2倍の再書き込み、4倍の読み取りパフォーマンスが得られると思いました-間違っていますか？
  7. [〜＃〜] new [〜＃〜]同じプール上のext4 zvolはZFSとほぼ同じ速度になると思いました

実際に得られるもの

プールの読み取りパフォーマンスが期待したほど高くない

bonnie ++数日前のプールのベンチマーク

バージョン1.97 ------順次出力-------順次入力--ランダム-
同時実行1 -Per-Chr- --Block-- -Rewrite--時間あたり--ブロック--シーク-
マシンサイズK /秒％CP K /秒％CP K /秒％CP K /秒％CP K /秒％CP /秒％CP 
 igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

bonnie ++単一の4TB REDドライブ上のzpool内にある

バージョン1.97 ------順次出力-------順次入力--ランダム-
同時実行1 -Per-Chr- --Block-- -Rewrite--時間あたり--ブロック--シーク-
マシンサイズK /秒％CP K /秒％CP K /秒％CP K /秒％CP K /秒％CP /秒％CP 
 igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8

これによると、読み取りと再書き込みの速度は、単一の4TB REDドライブ（2倍）の結果に基づいて適切です。ただし、期待していた読み取り速度は約550MB /秒（4TBドライブの4倍の速度）で、少なくとも約400MB /秒を期待していました。 代わりに、約260MB /秒

bonnie ++以下の情報を収集しながら、今すぐプールで。以前とまったく同じではなく、何も変更されていません。

バージョン1.97 ------順次出力-------順次入力--ランダム-
同時実行1 -Per-Chr- --Block-- -Rewrite--時間あたり--ブロック--シーク-
マシンサイズK /秒％CP K /秒％CP K /秒％CP K /秒％CP K /秒％CP /秒％CP 
 igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256.4 18

書き込み中のzpool iostat。私には問題ないようです。

容量操作帯域幅
 pool alloc free read write write read write 
 ------------------------- ------------------- ----- ----- ----- ----- ----- ----- 
 pool2 1.23T 2.39T 0 1.89K 1.60K 238M 
ミラー631G 1.20T 0 979 1.60K 120M 
 ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469--0 1007 1.60K 124M [。 ____。 ____。] ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE--0 953 0 117M

書き換え中のzpool iostat。 私は思います。

容量操作帯域幅
 pool alloc free read write write read write 
 ------------------------- ------------------- ----- ----- ----- ----- ----- ----- 
 pool2 1.27T 2.35T 1015 923 125M 101M 
ミラー651G 1.18T 505 465 62.2M 51.8M 
 ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469--198 438 24.4M 51.7M 
 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX--306 384 37.8M 45.1M 
ミラー651G 1.18T 510 457 63.2M 49.6M 
 ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T29304129 M 43.3M 
 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE--206 423 25.5M 49.6M

これは何が起こっているのだろうと思っているところです

zpool iostat読み取り中

容量操作帯域幅
 pool alloc free read write write read write 
 ------------------------- ------------------- ----- ----- ----- ----- ----- ----- 
 pool2 1.27T 2.35T 2.68K 32 339M 141K 
ミラー651G 1.18T 1.34K 20 169M 90.0K 
 ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469--748 9 92.5M 96.8K 
 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX--623 10 76.8M 96.8K 
ミラー651G 1.18T 1.34K 11 170M 50.8K 
 ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T042929 95.7M 56.0K 
 ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE--599 6 74.0M 56.0K

iostat -x同じ読み取り操作中。 IO％が100％ではないことに注意してください。

デバイス：rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm％util 
 sdb 0.60 0.00 661.30 6.00 83652.80 49.20 250.87 2.32 3.47 3.46 4.87 1.20 79.76 
 sdd 0.80 0.00 735.40 5.30 93273.20 49.20 251.98 2.60 3.51 3.51 4.15 1.20 89.04 
 sdf 0.50 0.00 656.70 3.80 83196.80 31.20 252.02 2.23 3.38 3.36 6.63 1.17 77.12 
 0.7s 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

zpoolとテストデータセットの設定：

  • 時はオフです
  • 圧縮はオフです
  • ashiftは0（自動検出-私の理解ではこれは問題ないということでした）
  • zdbによると、ディスクはすべてashift = 12です。
  • モジュール-オプションzfs zvol_threads = 32 zfs_arc_max = 17179869184
  • 同期=標準

編集-2015年10月30日

さらにテストを行いました

  • データセットbonnie ++ w/recordsize = 1M =書き込み226MB、読み取り392MBはるかに良い
  • データセットdd w /レコードサイズ= 1M =書き込み260MB、読み取り392MBはるかに良い
  • zvol w/ext4 dd bs = 1M = 128MB書き込み、107MB読み取りなぜ遅いのか
  • データセット2が並行してプロセスを処理する=書き込み227MB、読み取り396MB
  • dd direct ioは、データセットとzvolで違いはありません

レコードサイズが大きくなったので、とても満足しています。プール上のほとんどすべてのファイルは1MBをはるかに超えています。そのままにしておきます。ディスクの使用率はまだ100％になっていないため、さらに高速になる可能性はありますか。そして今、私はzvolのパフォーマンスがなぜそれが私が（軽く）使用しているものであるため、それほどひどいのかと思います。

コメント/回答で要求された情報を提供させていただきます。私の他の質問にもたくさんの情報が投稿されています： 同じサーバー上のNFS/CIFSディレクトリ間の遅いコピー

私は私が何かを理解していないだけで、これがまったく問題ではないかもしれないことを十分に承知しています。前もって感謝します。

それを明確にするために、質問は次のとおりです：なぜZFSプールが期待したほど速くないのですか？そして、おそらく他に何か問題がありますか？

linuxraidperformancezfszpool
10
Ryan Babchishin

予想していた数に非常に近い速度を得ることができました。

400MB /秒を探していて、管理されていました392MB /秒。だから私はそれが問題を解決したと言います。後でキャッシュデバイスを追加して、458MB/秒の読み取りを管理しました（キャッシュされていると思います）。

1。これは、最初はZFSデータセットのrecordsize値を1Mに増やすだけで実現されていました

zfs set recordsize=1M pool2/test

この変更により、ディスクアクティビティが減少し、大規模な同期読み取りおよび書き込みがより効率的になると思います。まさに私が求めていたもの。

変更後の結果

  • bonnie ++ =書き込み226MB、読み取り392MB
  • dd =書き込み260 MB、読み取り392 MB
  • 並列2プロセス=書き込み227MB、読み取り396MB

2。キャッシュデバイス（120GB SSD）を追加すると、さらにうまく管理できました。書き込みは少し遅いです、なぜかわかりません。

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

キャッシュデバイスのトリックは、/ etc/modprobe.d/zfs.confにl2arc_noprefetch=0を設定することでした。 ZFSがストリーミング/シーケンシャルデータをキャッシュできるようにします。これは、キャッシュデバイスが私のようなアレイよりも高速である場合にのみ実行してください。

データセットのレコードサイズの変更の恩恵を受けた後、zvolのパフォーマンスの低下に対処するための同様の方法である可能性があると思いました。

volblocksize=64kを使用して優れたパフォーマンスが得られると言っている厳しい人々に出会ったので、それを試しました。運が悪い。

zfs create -b 64k -V 120G pool/volume

しかし、次に、ext4（テストに使用したファイルシステム）がstrideやstripe-widthなどのRAIDのオプションをサポートしていることを読みました。だから私はこのサイトを使って必要な設定を計算しました： https://busybox.net/~aldot/mkfs_stride.html そしてzvolを再度フォーマットしました。

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

シンプルなベンチマークを行うためにbonnie++を実行しましたが、結果は優れていました。残念ながら私には結果はありませんが、思い出すと、書き込みの場合は少なくとも5〜6倍高速でした。ベンチマークをもう一度行ったら、この回答をもう一度更新します。

10
Ryan Babchishin

結果は完全に合理的ですが、期待はそうではありません。RAID1によって（さらにはRAID10によって）与えられた読み取りパフォーマンスの向上を過大評価しています。重要なのは、2方向のミラーリングでは、最大で2倍の読み取り速度が単一ディスクの読み取り速度/ IOPの2倍になることですが、実際のパフォーマンスは1倍から-2x。

例を挙げて説明します。各ディスクが100 MB /秒（順次）と200 IOPSに対応できる2面ミラーのシステムがあると想像してください。キューの深さが1（最大1つの未処理の要求）の場合、このアレイには単一のディスクよりもnoの利点があります。RAID1分割IO要求ですが、1つの要求を2つのディスクに分割しますしません（少なくとも、私が見た実装は動作します）反対に、IOキューが大きい場合（例：未処理の要求が4/8ある場合）、合計ディスクスループットは単一ディスクよりも大幅に高くなります。

RAID0についても同様のことができますが、この場合、平均的な改善を決定するのは、キューサイズだけでなく、IO要求サイズの関数でもあります。 ：平均IOサイズがチャンクサイズよりも小さい場合、2つ以上はストライプされません ）ディスクですが、1つのディスクで提供されます。Bonnie++レコードサイズを増やした結果は、この正確な動作を示しています。ストライプ化は、サイズの大きいIO。

RAID10アレイで2つのRAIDレベルを組み合わせるとしない線形のパフォーマンススケーリングにつながるが、上限。複数のdd/bonnie ++インスタンスを実行する場合（またはfioを使用してIOキューを直接操作する場合）の場合、元の期待に沿った結果が得られると確信しています、単純にIO配列に単一のシーケンシャルにロードするのではなく、より完全な方法（複数の独立したシーケンシャル/ランダムIOリクエスト））で課税するためIOリクエストのみ。

0
shodanshok