標準のREAD / WRITEをODXと比較したときに、ある顧客が予想よりも遅いパフォーマンスを経験した方法、およびエンジニアリングチームがQumulo Coreのメトリック、高速リリースサイクル、およびシームレスなアップグレードエクスペリエンスを活用して、謎を明らかにして解決した方法。
ODX（Windows Storage Offloaded Data Transfer）とは何ですか？
Windows Storage Offloaded Data Transfer（ODX）は、サーバーメッセージブロック（SMB）プロトコルの一部であり、クライアントマシンを介してデータを送信せずに、ファイルのチャンクをあるファイルから別のファイルにコピーするようにQumuloファイルシステムに指示できます。 ODX コピーパフォーマンスを向上させます サーバーサイドコピー（SSC）によく似ています。 クライアントとサーバー間のネットワーク遅延を排除し、QumuloCoreがIOサイズとバッファリングを最適化できるようにします。 比較するとき ODXとSSC、内部テストの結果は、同じサーバー上の別の場所にファイルをコピーするときに発生する通常のREAD / WRITEシーケンスよりも、ODXが7倍、SSCが4倍高速であることを示しています。
レイテンシーミステリーを読む
2021年に、ODXサポートを出荷しました Qumuloコア バージョン3.0.0以降。 出荷後すぐに、お客様からODXのパフォーマンスが予想よりも遅いとの報告がありました。
ODXがXNUMXつのファイルから読み取り、別のファイルに書き込むことを知っていたので、最初は書き込みパフォーマンスが問題であると考えました。 通常、読み取り操作には最大で数ミリ秒かかります（ありがとう SSDのキャッシュとプリフェッチ！）。 しかし、私たちが見たとき 読み取り待ち時間、ODXレイテンシの大部分が予想よりも大きいことがわかりました。25ms（約）のオーダーで、40または50msへのスパイクが高くなっています。 それで何が起こっているのですか？ これは、ODX操作の読み取りフェーズの存続期間の視覚化です。
クラウド監視パイプラインを介して収集した低粒度の時系列パフォーマンスデータを確認しました。 平均して、RAMキャッシュのヒット率と遅延のメトリックは良好に見えました。 しかし、なぜODX固有の読み取りが一般的に遅いのでしょうか。
最初の手がかり
根本原因の解明に近づくにつれ、他の操作のノイズなしに、このクラスター上の単一のODXワークロードに固有のより高い粒度のメトリックが必要になりました。 幸いなことに、私たちはというツールを持っています trigger</var/www/wordpress>, which we built internally, which collects this kind of distributed performance data when needed. We worked with our customer to profile some specific ODX sequences, and used trigger</var/www/wordpress> to collect data during those sequences. We learned a couple of things. (Refer to , above.)
各読み取り操作では、ほとんどのブロックが RAM キャッシュ内にありましたが、各読み取りでいくつかのブロックのキャッシュが失われていました。 これが発生すると、ファイル システム トランザクションはストレージ デバイス自体からデータを読み取る必要があります。 この場合、メトリクスはデータが回転ディスク上にあることを示しました。
[ボックスタイプ=”シャドウ”]注： 心の中では、「もちろん、それは回転する円盤に違いない…それは」と考えていました。 ALWAYS 回転する円盤。」 レイテンシを 50 ミリ秒まで押し上げる可能性があるのはシークだけであることを知っておくべきでした。 スピニングディスクと私は最高の関係ではありません。 彼らは、パフォーマンスに敏感なコード パスでの意図しない動作を痛ましいほど暴露するという、腹立たしいながらも有益な習慣を持っています。[/box]
リクエストが連続した順序でキューに入れられると、スピニング ディスクはデータを効率的にストリーミングできます。 ファイルの先頭から開始して最後まで読み取ります。 ただし、この場合、ODX 読み取り操作ごとにキャッシュから失われたのは数ブロックだけでした。これは、回転ディスクに多数の不連続な読み取りとして現れました。 これは、ディスクの回転遅延にとっては悪いニュースです。
通常、ファイル システムの読み取り操作では、効果的なプリフェッチャーがあるため、この種の回転ディスクの遅延は発生しません。 プリフェッチャーは次に何が読み取られるかを推測し、事前にキャッシュにロードします。 プリフェッチャーには、回転ディスクから読み取るように最適化された IO パターンがあります。
では、なぜプリフェッチャーが機能しなかったのでしょうか?
私たちのプリフェッチャーには、平均してどの程度成功したかを示すメトリクスがあります。 これらのメトリクスから、プリフェッチされているすべてのデータが読み取られていることがわかりましたが、ファイル システムが読み取った一部のデータはプリフェッチされていませんでした…これは本当に奇妙です。 おそらく、ODX 操作が順番どおりに読み取られていないか、ランダムに飛び回っているのでしょうか? プリフェッチャーはランダム IO ではうまく機能しません。
操作ログを確認してIOパターンを確認しました。 操作ログは、オフセット、サイズ、キャッシュのヒット/ミスなど、各操作に関する情報を知らせるテキスト ログ ファイル ツールです。 しかし、操作ログに ODX の読み取りサイズとオフセットが必要になるとは予想していなかったので、その結果コードは接続されていませんでした。 そのため、さらにコードを記述し、アップグレードを待つ必要がありました…
犯人を見つける
数週間以内に新しいコードを出荷し、非常に優れたアップグレードを使用して、お客様はすぐに Qumulo ストレージ システムを最新バージョンにアップグレードすることができました。 彼らは私たちのためにテスト ワークロードを再実行しました。 改善された操作ログを使用して、別のパズルを発見しました。 操作ログを読むと (緑色の数字を読んでマトリックスの中にいるような気がしました)、ODX プロトコル コードがファイル システムにそれぞれ 8650752 バイトの連続読み取りリクエストを送信していることがわかりました。 計算してみると、8 メビバイト + 256KiB になります。 しかし！ 操作ログによると、各 ODX リクエストは実際にはキャッシュから 8388608 バイト (正確には 8 メビバイト) しか取得していませんでした。
最初は目が曇っていたのを覚えています…数字を読み間違えたのでしょうか？ 各リクエストが要求していた 256MiB のうち 8KiB だけのキャッシュが不足しているのはなぜですか? プリフェッチャーはどのようにして各リクエストのサブセットのみをフェッチするのでしょうか? それ無理！
[ボックスタイプ=”シャドウ”]注： すべてのバグの最初の段階は否定、つまりデータが間違っていると信じることです。 幸いなことに、これは私にとって初めてのロデオではありませんでした。 私はすぐに否定する気持ちを抑え、「どうしてそんなことが可能だろう？」と自問し始めました。[/box]
私は、一緒に調査に取り組んでいた同僚に、プリフェッチャーがどのように機能するかを説明し始めました。 読み取りワークロードの IO サイズが問題にならないように、プリフェッチャーは読み取りワークロードよりも先に動作する必要があります。 プリフェッチャーは常に、シークを回避するために回転ディスク上のキューイングが適切に順序付けられるような方法で、大きなチャンクでデータをフェッチします。 そして、それは私に衝撃を与えました…大きな塊…プリフェッチチャンクの大きさはどれくらいですか? OH…8 MiB です…待ってください、それは不気味です。 そして、読み取りワークロードをどのようにして処理するのでしょうか? OH、読み取りリクエストごとに 8 つのプリフェッチを開始します…待って…これら 8 つのことをまとめて…読み取りリクエストごとに 256 つのプリフェッチのみを開始し、プリフェッチ チャンク サイズが最大 8 MiB で、リーダーが 256MiB + のチャンクを読み取っている場合XNUMXKiB…そうすると、当然のことですが、プリフェッチャーが先に進むことはありません…常に次の XNUMXMiB をプリフェッチし、XNUMXKiB の末尾がキャッシュされないままになります。 ワオ。 （ガッツポーズ）。 Ok。 私たちは発煙筒を見つけました。
プリフェッチ問題の例
謎の解明
バグを特定することは始まりにすぎません。 すぐに XNUMX つの疑問が思い浮かびました。
- 標準のファイル システム読み取りテストでは、これと同じ問題が発生しないのはなぜですか?
- ODX がプリフェッチャーの最大 IO サイズよりも大きい 8 MiB + 256 KiB の IO サイズを使用しているのはなぜですか?
- ODX 固有のパフォーマンス テストでこれが見つからなかったのはなぜですか?
1. 標準のファイル システム読み取りパフォーマンス テストではこの問題が発生しないのはなぜですか?
当社のファイル システム プロトコル スケジューラは、すべてのプロトコル要求を処理します。 一般的なプロトコル要求のサイズは 1MiB です。 プロトコル読み取りリクエストを受信すると、それらを処理し、読み取りパフォーマンスを最適化するためにリクエストを結合する可能性があります。 これらのファイル システム リクエストには、当然のことながら、組み合わせた最大 IO サイズがあります。 IO サイズが大きくなりすぎると、リクエストが実行していた大きなシングル スレッド処理 (CPU、メモリ割り当てなど) がボトルネックになる可能性があります。 したがって、ファイル システム スケジューラは、合計読み取りリクエストの最大値を 8MiB にし、これはプリフェッチャーの最大 IO サイズと同じになります。 これは仕様によるものでした。 したがって、これらのワークロードでは、プリフェッチャーはすべてをプリフェッチしていますが、合計 IO サイズが 8 MiB である場合、8MiB を超えることはありません…(頭を引っ掻く...それも意図した動作ではありませんでした...）。
2. ODX が 8 MiB + 256 KiB の IO サイズを使用するのはなぜですか?
ODX 操作自体はスケジューラを経由しますが、内部読み取りリクエストはスケジューラを経由しません。 ODX は、スケジューラとは独立して、要求する最大 IO 読み取りサイズを設定していました。
スケジューラの最大 IO サイズと ODX の最大 IO サイズが異なる関数を使用していることがわかりました。
fs_target_transaction_size()
fs_max_transaction_size()</var/www/wordpress>
スケジューラーが使用していた fs_target_transaction_size</var/www/wordpress>, which is a minimum of fs_max_transaction_size</var/www/wordpress> and 8MiB! Whereas the ODX code was intuitively using fs_max_transaction_size</var/www/wordpress> - which is computed, and turned out to be 8MiB + 256KiB.
つまり、根本的な原因がそこにあったのです。 使用する ODX プロトコル コードを修正しました fs_target_transaction_size</var/www/wordpress>, and , no more uncached tails to the read requests.
3. ODX のパフォーマンス テストでこれが見つからなかったのはなぜですか?
当社の ODX パフォーマンス テスト した、実際には、キャッシュされていない末尾の動作を示します。 しかし、パフォーマンスはそれほど悪くはありませんでした。 なぜなら、このパフォーマンス テストでは、データが SSD キャッシュに収まるほど小さかったからです。
振り返ってみると 図1 (上) を見ると、SSD からの読み取りの遅延が回転ディスクよりもはるかに低いことがわかります。 したがって、プリフェッチャーが間違ったことを行っていることは、最上位のパフォーマンス テストの結果からは明らかではありませんでした。 このテストでは、プリフェッチャーのメトリクスを明示的にチェックしていませんでした。
SSD からデータを削除し、回転ディスクから読み戻すという XNUMX 番目のステップを実行するようにパフォーマンス テストを変更すると、トップラインのパフォーマンスが本来より大幅に低下し、バグが明らかになりました。 私たちはバグを修正し、この自動パフォーマンス テストの改善を観察しました。 2週間以内に改良版を発送しました。 再び Qumulo を活用 簡単なアップグレード、お客様は修正後すぐにアップグレードし、ODX パフォーマンスの向上を得ることができました。
