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. 負荷がかかってシーケンシャルデータの読み取りまたは書き込みを行っているときに、4つのディスクすべてでIO使用率が100％になると思いました。そして、そのディスクは100％の使用率で100MB /秒以上を出力します。
6. このプールでは、1つのディスクで約2倍の書き込み、2倍の書き換え、4倍の読み取りパフォーマンスが得られると思いました。
7. NEW同じプールのext4 zvolはZFSとほぼ同じ速度になると思いました

私が実際に得るもの

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

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

バージョン1.97 ------順次出力-------順次入力--ランダム-
同時実行性1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
マシンサイズ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

1つの4TB REDドライブ上のbonnie ++は、zpoolにあります。

バージョン1.97 ------順次出力-------順次入力--ランダム-
同時実行性1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
マシンサイズ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- -Per Chr- --Block-- --Seeks--
マシンサイズ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。私には問題ないようです。

                                                 容量操作の帯域幅
プール割り当て無料読み取り読み取り読み取り書き込み
-------------------------------------------- ------ ---- ----- ----- ----- -----
プール2 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-WCC4MLK57MVX--0 975 0 120M
  ミラー631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536--0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE--0 953 0 117M

書き換え中のzpool iostat。私には大丈夫だと思います。

                                                 容量操作の帯域幅
プール割り当て無料読み取り読み取り読み取り書き込み
-------------------------------------------- ------ ---- ----- ----- ----- -----
プール2 1.27T 2.35T 1015 923 125M 101M
  ミラー651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469--198438 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-WCC1T0429536--304371 37.8M 43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE--206 423 25.5M 49.6M

何が起こっているのかな

読み取り中のzpool iostat

                                                 容量操作の帯域幅
プール割り当て無料読み取り読み取り読み取り書き込み
-------------------------------------------- ------ ---- ----- ----- ----- -----
プール2 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-WCC1T0429536--774 5 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
sda 0.70 0.00 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プールが期待したほど速くないのですか？そして、おそらく他に何か問題がありますか？

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

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のようなRAIDのためのサポートオプションを（私がテストしていたファイルシステム）の読み取りstrideとstripe-width私は前に使ったことがありません、。したがって、私はこのサイトを使用して必要な設定を計算しました：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倍高速でした。ベンチマークを再度行った場合は、この回答を再度更新します。

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

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

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

RAID10アレイで2つのRAIDレベルを組み合わせても、線形のパフォーマンススケーリングにはつながらないことは明らかですが、上限が設定されています。複数のdd / bonnie ++インスタンスを実行する（またはfioIOキューを直接操作するために使用する）と、より完全な方法でIO配列に負荷をかけるだけなので、元の期待に沿った結果が得られると確信しています（単一の順次IO要求のみをロードするのではなく、複数の未処理の順次/ランダムIO要求）。