0

結果を誤解iostatしているのでしょうか、それとも 1 分間に 3.06 MB しか書き込みをしていないのでしょうか?

# zpool iostat -v 60

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   356G   588G    465     72  1.00M  3.11M
  xvdf       356G   588G    465     72  1.00M  3.11M
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   356G   588G    568     58  1.26M  3.06M
  xvdf       356G   588G    568     58  1.26M  3.06M
----------  -----  -----  -----  -----  -----  -----

現在rsync、別の HDD ( ext4) からファイルを書き込んでいます。私たちのファイル特性 (~50 KB ファイル) に基づくと、計算は正しいようです3.06 * 1024 / 58 = 54 KB

記録のために:

  • primarycache=metadata
  • compression=lz4
  • dedup=off
  • checksum=on
  • relatime=on
  • atime=off

サーバーは にありEC2、現在 1 コア、2GB RAM ( t2.small)、HDD - Amazon で最も安いものです。OS - Debian Jessie、リポジトリzfs-dkmsからインストール。debian testing

それが本当に遅いのなら、なぜですか?すべてを SSD に移行して 8 GB の RAM を追加せずにパフォーマンスを向上させる方法はありますか? VPSそれはまったくうまく機能しますか、それともZFSベアメタルを念頭に置いて設計されていますか?

編集

ZIL回答で提案されているように、として使用する 5 GB の汎用 SSD を追加しました。ZILまったく使用されていないように見えるので、それはあまり役に立ちませんでした。次の Oracle の記事によると1/2、RAM のサイズについては5 GB で十分です。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   504G   440G     47     36   272K  2.74M
  xvdf       504G   440G     47     36   272K  2.74M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   504G   440G     44     37   236K  2.50M
  xvdf       504G   440G     44     37   236K  2.50M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

編集

ddテストはかなりまともな速度を示しています。

# dd if=/dev/zero of=/mnt/zfs/docstore/10GB_test bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 29.3561 s, 366 MB/s

ただしiostat、出力は帯域幅に関してあまり変化していません。書き込み操作の数が多いことに注意してください。

# zpool iostat -v 10
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0     40  1.05K  2.36M
  xvdf       529G   415G      0     40  1.05K  2.36M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      2    364  3.70K  3.96M
  xvdf       529G   415G      2    364  3.70K  3.96M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    613      0  4.48M
  xvdf       529G   415G      0    613      0  4.48M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    490      0  3.67M
  xvdf       529G   415G      0    490      0  3.67M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0    126      0  2.77M
  xvdf       529G   415G      0    126      0  2.77M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zfs-backup   529G   415G      0     29    460  1.84M
  xvdf       529G   415G      0     29    460  1.84M
logs            -      -      -      -      -      -
  xvdg          0  4.97G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
4

2 に答える 2

2

それは VPS でうまく機能しますか、それとも ZFS はベアメタルを念頭に置いて設計されたものですか?

はい、両方に。

もともとはベア メタル用に設計されており、それは自然に最高のパフォーマンスと完全な機能セットを取得することでした (それ以外の場合は、たとえば同期書き込みを要求するときに書き込みが実際にディスクにコミットされている場合など、基盤となるストレージを信頼する必要があります)。vdev は利用可能な任意のファイルまたはデバイスで構成できるため、非常に柔軟性がありますが、もちろん、パフォーマンスは基盤となるストレージと同程度にしかなりません。

考慮すべき点:

  • 異なるZFSファイルシステム間でファイルを移動することは、リンクの再配置だけでなく、常に完全なコピー/削除です(あなたのケースには当てはまりませんが、将来的には可能性があります)
  • 同期書き込みは非同期よりもはるかに遅く (ZFS はすべての単一の要求がコミットされるのを待たなければならず、通常の方法で書き込みをキューに入れることができません*)、ZFS インテント ログを専用の vdev に適切な vdev に移動することによってのみ速度を上げることができます。書き込み IOPS が高く、レイテンシが低く、耐久性が高い (ほとんどの場合、これは SLC SSD などになりますが、既にプールにあるデバイスとは異なるデバイスである可能性があります)。ZIL を専用の SLOG デバイスに分離しなくても、110 MB/秒の非同期を簡単に飽和させることができる通常のディスクを備えたシステムでは、約 0.5 ~ 10 MB/秒の同期パフォーマンスが得られる可能性があります (vdev によって異なります)。したがって、私はあなたの価値観が異常だとは思いません。
  • 優れたハードウェアを使用しても、柔軟性と安全性のためのオーバーヘッドがあるため、ZFS は単純なファイル システムほど高速にはなりません。これは Sun が最初から述べていることであり、驚くべきことではありません。何よりもパフォーマンスを重視する場合は、他のものを選択してください。
  • 問題のファイル システムのブロック サイズはパフォーマンスに影響を与える可能性がありますが、信頼できるテスト番号は手元にありません。
  • RAM は読み取りキャッシュとしてのみ使用されるため (重複排除を有効にしている場合を除く)、RAM を増やしても (システム自体のしきい値が約 1 GB と低い場合) あまり役に立ちません。

提案:

  • プールに高速な (仮想) ディスクを使用する
  • 別の(仮想)デバイスを使用して、ZILを通常のプールから分離します。できればプールよりも高速ですが、同じ速度のデバイスで他のデバイスにリンクされていない場合でも、ケースが改善されます
  • 同期の代わりに非同期を使用し、トランザクションの後で (またはかなりのチャンクで) 自分で検証します

*) より正確に言えば、一般に、特定のサイズを下回るすべての小さな同期書き込みは、RAM からディスクに書き込まれる前に、ZIL に追加で収集されます。これは、5 秒ごとまたは約 4 GB のいずれか早い方で発生します (これらのパラメーターはすべて、変更されます)。これは、次の理由で行われます。

  • RAM から回転ディスクへの 5 秒ごとの書き込みは連続して実行できるため、少量の書き込みよりも高速です。
  • 突然の停電が発生した場合、中断された実行中のトランザクションは ZIL に保存され、再起動時に再適用できます。これは、トランザクション ログを持つデータベースのように機能し、ファイル システムの一貫した状態 (古いデータの場合) と、書き込まれるデータが失われないこと (新しいデータの場合) を保証します。

通常、ZIL はプール自体に常駐し、冗長 vdev を使用して保護する必要があります。これにより、操作全体が停電、ディスク クラッシュ、ビット エラーなどに対して非常に回復力が高くなります。より効率的な連続転送で同じデータをディスクにフラッシュできます。したがって、ZIL を別のデバイスに移動することをお勧めします。通常はSLOGデバイス (別のLOGデバイス) と呼ばれます。これは別のディスクである可能性がありますが、SSD はこのワークロードではるかに優れたパフォーマンスを発揮します (ほとんどのトランザクションがそれを通過するため、かなり早く消耗します)。クラッシュが発生しない場合、SSD は決して読み取られず、書き込まれるだけです。

于 2016-06-15T08:16:37.430 に答える
1

この特定の問題は、ノイズの多い隣人が原因である可能性があります。t2 インスタンスであるため、優先度が最も低くなります。この場合、インスタンスを停止/開始して、新しいホストを取得できます。

インスタンス ストレージを使用していない限り (実際には t2 インスタンスのオプションではありません)、すべてのディスク書き込みは本質的に SAN ボリュームに対して行われます。EBS システムへのネットワーク インターフェイスは、同じホスト上のすべてのインスタンスで共有されます。インスタンスのサイズによって、インスタンスの優先度が決まります。

あるボリュームから別のボリュームに書き込んでいる場合、すべての読み取りおよび書き込みトラフィックが同じインターフェイスを介して渡されます。

使用しているボリューム タイプや、t2 インスタンスに CPU クレジットが残っているかどうかによっては、他の要因が関係している可能性があります。

于 2016-06-14T22:24:30.443 に答える