abstract ：現在のパフォーマンスと理論上のパフォーマンスの違い。 待ち時間とIOPS、ディスク負荷の独立性の概念。 試験準備; 典型的なテストパラメータ; 実用的なコピーペーストのハウツー。



警告：多くの手紙、長い読み。

歌詞

非常に一般的な問題は、「サーバーの速度」を理解しようとする試みです。すべてのテストの中で、ディスクサブシステムのパフォーマンスを評価する最も哀れな試みです。 私の人生で見た恐怖は次のとおりです。

• ddを使用してクラスターFS速度を評価した科学的出版物（およびファイルキャッシュを有効にした、つまり直接オプションなし）
• ボニー++を使用して
• iozoneを使用する
• ランタイム測定でのcpバンドルの使用
• 64ビットシステムでダイナモでiometerを使用する

これらはすべて完全に間違った方法です。 さらに微妙な測定誤差を分析しますが、これらのテストに関しては、1つだけ言うことができます-それを捨てて、使用しないでください。





ボニー++とイオゾンは、ファイルシステムの速度を測定します。 これは、キャッシュ、カーネルの思慮深さ、ディスク上のFSロケーションの成功などに依存します。 間接的に、iozoneで良好な結果が得られた場合、それは良好なキャッシュ、または愚かなパラメーターセット、または非常に高速なディスク（どのオプションを取得したかを推測します）であると言えます。 ボニー++は、一般的にファイルのオープン/クローズ操作に焦点を当てています。 つまり 彼女は特にディスクのパフォーマンスをテストしていません。



ダイレクトオプションなしのddは、キャッシュ速度のみを表示します。 一部の構成では、キャッシュを使用した場合よりもキャッシュを使用しなくても線形速度を得ることができます。 一部では、メガバイト単位の線形パフォーマンスで毎秒数百メガバイトを受信します。



directオプション（iflag =読み取り用に直接、oflag =書き込み用に直接）を使用すると、ddは線形速度のみをチェックします。 これは、最大速度（複数のディスクでRAIDを実行する場合、複数のストリームでRAIDを実行すると1つよりも高速になる可能性があります）または実際のパフォーマンスとはまったく異なります。



IOmeterは何よりも優れていますが、Linuxでの動作に問題があります。 64ビットバージョンでは、負荷の種類が正しく計算されず、過小評価された結果が表示されます（信じない人は、ramdiskで実行してください）。



ネタバレ：Linuxの正しいユーティリティはfioです。 しかし、それはテストの非常に思慮深い準備と結果のさらに思慮深い分析を必要とします。 以下は、理論の準備と、fioでの作業に関する実際的なメモのみです。

問題の声明

（現在のVS最大パフォーマンス）

今、さらに退屈な手紙があります。 誰かがお気に入りのSSD'shka、ラップトップネジなどのオウムの数に興味がある場合 -記事の最後にあるレシピをご覧ください。



ramdiskを除くすべての現代のメディアは、ランダム書き込み操作に対して非常に否定的な態度を持っています。 HDDの場合、書き込みと読み取りの間に違いはありません。ヘッドがディスクを駆動することが重要です。 ただし、SSDの場合、ナンセンスを読み取り、小さなブロックで書き込むランダム操作により、コピーオンライトが発生します。 最小記録サイズは1〜2 MBで、4 KBを書き込みます。 2MBを読み取り、4KBに置き換えて書き戻す必要があります。 その結果、たとえば、SSDに4kbを書き込むには1秒あたり400リクエストが必要になり、800 Mb / s（!!!!）を読み取り、それらを書き戻すことになります。 （ramdiskの場合、このような問題は同じかもしれませんが、DDRの「最小ブロック」のサイズは約128バイトであり、テストのブロックは通常4kbであるため、RAMディスクのパフォーマンスのテストではDDRの粒度は重要ではありません） 。



この投稿は異なるメディアの詳細に関するものではないため、一般的な問題に戻ります。



Mb / sでエントリを測定することはできません。 重要なことは、頭の動きの数と、SSDで乱れたランダムブロックの数です。 つまり アカウントはIOオペレーションの数になり、IO / sの値はIOPSと呼ばれます。 したがって、ランダムな負荷を測定するとき、IOPSについて話します（wIOPS、rIOPS、それぞれ書き込みおよび読み取り用）。 大規模なシステムでは、kIOPS値（注意、常にどこでも、1024なし）1kIOPS = 1000 IOPSを使用します。



そして、ここで、多くは第一種のtrapに陥ります。 彼らは、ドライブが何IOPSを提供しているかを知りたがっています。 またはディスクシェルフ。 または、カバーの下にディスクが詰められた200台のサーバーキャビネット。



実行された操作の数（12:00:15から12:00:16 245790のディスク操作が実行されたことが記録されます-つまり、負荷は245kIOPSでした）とシステムが最大操作を実行できる量を区別することが重要です。



実行される操作の数は常に既知であり、測定が容易です。 しかし、ディスク操作について話すときは、将来時制でそれについて話します。 「システムはいくつの操作を実行できますか？」-「どの操作ですか？」 異なる操作は、ストレージシステムに異なる負荷を与えます。 たとえば、誰かが1 MBのランダムブロックで書き込む場合、4 KBのブロックで順番に読み取る場合よりもかなり少ないiopsを受け取ります。



そして、負荷の場合に、「来た、処理された」リクエストの数について話しているなら、計画の場合、どのiopsになるかを知りたいです。



ドラマは、どんな要求が来るのか誰も知らないということです。 小さなもの？ 大きなもの？ 契約？ 意見の不一致？ それらはキャッシュから読み取られますか、それとも最も遅い場所に移動してディスクの異なる半分からバイトを選択する必要がありますか？



ドラマをこれ以上エスカレートするつもりはありません。簡単な答えがあります。

• ディスクテスト（ストレージ/アレイ）のベストケース（ヒット、キャッシュ、シーケンシャル操作）
• 最悪の場合のディスクテスト。 ほとんどの場合、このようなテストはディスクデバイスの知識を使用して計画されます。 「64MBのキャッシュがありますか？」 テスト領域のサイズを2GBにするとどうなりますか？」 ハードドライブは、ドライブの外側からより速く読み取りますか？ そして、テスト領域を内側（スピンドルに最も近い）領域に配置すると、ヘッドが移動する経路がより多くなりますか？ 彼は先読みをしましたか？ そして、逆の順序で読んだら？ 等

その結果、数字が得られますが、それぞれが間違っています。 例：15kIOPSおよび150 IOPS。



実際のシステムパフォーマンスはどうなりますか？ これは、負荷が良い側と悪い側にどれだけ近いかによってのみ決まります。 （つまり、ありふれた「人生が表示されます」）。



ほとんどの場合、彼らは次の指標に焦点を当てています。

1. その最良のケースは依然として最高です。 最悪から最高のケースがほとんど変わらないように最適化できるからです。 これは悪いことです（まあ、そういう最悪の最悪の事態があります）。
2. 最悪の場合。 それがあれば、ストレージシステムは得られた数値よりも速く動作すると言えます。 つまり 3000 IOPSを取得した場合、「最大2000」の負荷でシステム/ディスクを安全に使用できます。

さて、ブロックサイズについて。 従来、テストのブロックサイズは4kでした。 なんで？ これは、ファイルを保存するときにOSが使用する標準ブロックサイズであるためです。 これはメモリページのサイズであり、一般に、Very Round Computer Numberです。



システムが4kブロックで100 IOPS（最悪）を処理する場合、8kブロックでは処理が少なくなります（少なくとも50 IOPS、ほとんどの場合70〜80）。 さて、1MBブロックでは、まったく異なる数値が表示されます。



それだけですか？ いいえ、それは単なる紹介でした。 上に書かれているものはすべて多かれ少なかれよく知られています。 重要なことは以下から始まります。



最初に、「依存IOPS」の概念を見ていきます。 アプリケーションが次のように機能することを想像してください。

• 記録を読む
• レコードを変更する
• 書き戻す

便宜上、処理時間はゼロであると想定しています。 各読み取りおよび書き込み要求が1ミリ秒処理される場合、アプリケーションは1秒あたりいくつのレコードを処理できますか？ 500です。そして、アプリケーションの2番目のコピーの隣で起動するとどうなりますか？ 適切なシステムでは1000になります。1000を大幅に下回ると、システムパフォーマンスの限界に達しました。 そうでない場合、依存IOPSを持つアプリケーションのパフォーマンスは、ストレージパフォーマンスではなく、レイテンシとIOPS依存性の2つのパラメーターによって制限されることを意味します。



レイテンシーから始めましょう。 遅延 -要求の実行時間、応答前の遅延。 通常、「平均遅延」という値を使用します。 より高度なものは、特定の間隔（ほとんどの場合1秒）ですべての操作の中央値を使用します。 レイテンシーの測定は非常に困難です。 これは、ストレージシステムでは、リクエストの一部が迅速に実行され、一部が低速であり、非常に不快な状況に陥り、残りの何十倍ものサービスを提供できるという事実によるものです。



陰謀は、要求のキューの存在によって強化され、その中で要求の並べ替えとその並列実行を実行できます。 通常のSATAドライブのキュー深度（NCQ）は31であり、強力なストレージシステムは数千に達する可能性があります。 （キューの実際の長さ（完了を待機している要求の数）はむしろ負のパラメーターであることに注意してください。キューに多くの要求がある場合、それらはより長く、つまり遅くなります。スーパーマーケットのラッシュアワーに立っている人は、キューは、サービスが短くなります。



遅延は、シリアルアプリケーションのパフォーマンスに直接影響します。その例を上記に示します。 より高いレイテンシー-より低いパフォーマンス。 5msでは、リクエストの最大数は200 pcs / s、20ms-50です。さらに、1msで100個のリクエストを処理し、100msで9個のリクエストがある場合、1秒で平均109msのIOPSを取得します。 （平均）10ミリ秒。



したがって、結論を理解するのはかなり困難です。パフォーマンスへの負荷の種類は、「シーケンシャル」または「ランダム」だけでなく、ディスクを使用するアプリケーションの配置にも影響します。



例：アプリケーション（通常のデスクトップタスク）の起動は、ほぼ100％順次です。 アプリケーションを読み、必要なライブラリのリストを読み、各ライブラリを順番に読みます...だからこそ、デスクトップ上でSSDを非常に情熱的に愛しているのです-読み取りには微視的な遅延（マイクロ秒）があります-もちろん、お気に入りのフォトショップやブレンダーは10分の1秒で始まります。



しかし、たとえば、ロードされたWebサーバーの作業はほぼ並行して行われます-後続の各クライアントは、隣接するクライアントとは独立して処理されます。 待ち時間は各クライアントのサービス時間にのみ影響し、「最大クライアント数」には影響しません。 そして、私たちはその1ms、10msを認めます-とにかくウェブサーバーのために。 （ただし、10ミリ秒の並列リクエストをいくつ送信できるかは「すべて同じ」ではありません）。



脱穀 。 デスクトップユーザーは、システム管理者よりもこの現象に精通していると思います。 ハードドライブのひどいクランチ、言いようのないブレーキ、「何も機能せず、すべてが遅くなります。」



ディスクキューを詰まらせ始めると（またはストレージ、記事の文脈では両者に違いはありません）、待ち時間が急激に増加し始めます。 ディスクは制限まで実行されますが、サービスの速度よりも多くの着信呼び出しがあります。 遅延は急速に増加し始め、数秒という恐ろしい数に達します（これは、たとえば、アプリケーションが作業を完了するために100の操作を行う必要があるにもかかわらず、5ミリ秒の遅延では0.5秒の遅延を意味します...）。 この状態はスラッシングと呼ばれます。



びっくりするでしょうが、どのドライブやストレージでも、通常の読み込みよりもスラッシング状態でより多くのIOPSを表示できます。 その理由は簡単です。通常モードでキューがほとんど空で、レジ係が顧客を待って退屈している場合 、トラッシュ状態では一定のサービスがあります。 （ところで、スーパーマーケットが列を並べるのが好きな理由の説明はここにあります-この場合、レジ係の生産性は最大です）。 確かに、顧客はあまり好きではありません。 そして、良いスーパーマーケットでは、彼らはそのような体制を避けようとします。 キューの深さを上げ続けると、キューがいっぱいになり、キューに入るためのキューイングが要求されるため、生産性が低下し始めます（はい、手にボールペンを持つシリアル番号）。



そして、ここでは、ディスクパフォ​​ーマンスを測定する人々の次の頻繁な（そして、反論するのが非常に難しい）エラーを待っています。

テスト中の遅延制御

「私のディスクは180 IOPSを生成するため、10個のディスクを使用すると、1800 IOPSになります。」 （それはまさに、悪いスーパーマーケットが考えるもので、必要以上にレジ係を少なくします）。 同時に、レイテンシーは超越的であることが判明しました-そして、「そのように生きることはできません」。



実際のパフォーマンステストでは、レイテンシを制御する必要があります。つまり、レイテンシが合意された制限を下回るように、このようなテストパラメータを選択する必要があります。



そして、ここで私たちは2番目の問題に直面しています：制限は何ですか？ 理論はこの質問に答えることができません-この指標はサービス品質の指標です。 言い換えれば、誰もが自分で選択します。



個人的には、レイテンシが10ミリ秒を超えないように自分でテストを行っています。 この指標は、ストレージパフォーマンスの上限と考えています。 （同時に、私の心では、遅れが感じられる限界値は20ミリ秒だと思いますが、上記の例では900から1ミリ秒と10から100ミリ秒、平均が10ミリ秒になったことを覚えていますか？自分+ランダムバーストの場合は10ミリ秒）。

並行性

依存IOPSと独立IOPSの問題についてはすでに説明しました。 依存Iopのパフォーマンスはレイテンシによって正確に制御され、この問題についてはすでに説明しました。 しかし、独立したIOPS（つまり、並列ロード）でのパフォーマンスは、何に依存していますか？



答えは、ディスクを発明したか、ストレージを設計した人の想像力からです。 SSDのヘッド、スピンドル、並列書き込みキューの数については説明できますが、これはすべて推測です。 実用化の観点から、1つの質問に興味があります。 並列ロードストリームをどれだけ実行できますか？ （レイテンシーを天国に送信できるようにすると、並列スレッドの数がそこに移動しますが、その速度ではないため、レイテンシーを忘れないでください）。 質問は次のとおりです。指定されたしきい値未満のレイテンシで実行できる並列スレッドの数はいくつですか？ テストはこの質問に答える必要があります。

SANおよびNAS

それとは別に、ストレージをTCPを使用してネットワーク経由でホストに接続するときの状況について話す必要があります。 TCPについては、書き、書き、書き、書き直す必要があります。 Linuxには、さまざまな状況に合わせて設計されたネットワーク用の12の異なる輻輳制御アルゴリズムがあると言えば十分です。 また、約20のカーネルパラメーターがあり、それぞれが出力オウムに大きく影響する可能性があります（申し訳ありませんが、テスト結果）。



パフォーマンス評価の観点から、このルールを受け入れる必要があります。ネットワーク接続ストレージの場合、テストは複数のホスト（サーバー）から並行して実行する必要があります。 1台のサーバーからのテストはストレージテストではなく、ネットワーク、ストレージ、およびサーバー自体の正しい設定の統合テストになります。

バス飽和

最後の質問は、タイヤのシェーディングの問題です。 何言ってるの？ 400 MB / sを配信できるssdがあり、SATA / 300を介して接続する場合、すべてのパフォーマンスが表示されないことは明らかです。 さらに、レイテンシーの観点からは、各要求（およびその応答）がSATAケーブルのボトルネックをすり抜けるまで順番に待機する必要があるため、問題は300MB / sに近づくずっと前に現れ始めます。



しかし、もっと楽しい状況があります。 たとえば、SAS / 300x4を介して接続されたドライブのシェルフがある場合（つまり、それぞれ300MBの4本のSASライン）。 たくさんのようです。 また、シェルフに24個のディスクがある場合はどうなりますか？ 24 * 100 = 2400 MB / sで、1200（300x4）しかありません。



さらに、一部の（サーバー！）マザーボードでのテストでは、組み込みのSATAコントローラーがPCIx4を介して接続されることが多いことがわかりました。



繰り返しますが、バスの飽和の主な問題は、ストリップの「天井の下」を食べ尽くすことではなく、バスの負荷に応じてレイテンシーが増加することです。

スタントメーカー

実務的なアドバイスの前に、産業用ストレージで見られる有名なトリックについてお話します。 最初に、空のディスクを読み取る場合、「どこからでも」から読み取ります。 このシステムは、これまで書かなかったドライブの領域からゼロを提供するのに十分なほどスマートです。



第二に、多くのシステムでは、あらゆる種類のスナップショット、シンプロビジョニング、重複排除、圧縮、遅延割り当て、スパース配置などのメカニズムにより、最初のレコードが後続のものよりも悪い。 つまり、最初の記録後にテストする必要があります。



第三に、キャッシュ。 最悪のケースをテストする場合、キャッシュが役に立たないときのシステムの動作を知る必要があります。 これを行うには、そのようなテストサイズを取得して、「過去のキャッシュ」の読み取り/書き込み、つまりキャッシュからの脱出を保証する必要があります。



書き込みキャッシュは特別な話です。 すべての書き込み要求（シーケンシャルおよびランダム）を保存し、コンフォートモードで書き込むことができます。 唯一の最悪の場合の方法は「キャッシュトラッシング」です。つまり、そのようなボリュームで書き込み要求を送信し、書き込みキャッシュが書き込みを停止し、コンフォートモードではないデータを強制的に書き込み（隣接領域を結合）しますが、ランダムデータをランダムに破棄します書く。 これは、キャッシュサイズを超えてテスト領域を繰り返し超過することによってのみ実現できます。



判定-最小x10キャッシュ（率直に言って、数値は上限から取られています。正確な計算メカニズムはありません）。

OSローカルキャッシュ

もちろん、テストはローカルOSキャッシュの参加なしで行う必要があります。つまり、キャッシュを使用しないモードでテストを実行する必要があります。 Linuxでは、これはファイル（またはディスク）を開くときのO_DIRECTオプションです。

テストの説明

合計：

1）最悪のケース-ディスクサイズの100％をテストしています。これは、ストレージの推定キャッシュサイズの数倍です。 デスクトップの場合、これは単なる産業用ストレージの「ディスク全体」です。LUNまたは仮想マシンのディスクサイズは1TB以上です。 （Hehe、64GBのRAMキャッシュが多いと思うなら...）。

2）テストブロックを4kbサイズで実施します。

3）レイテンシが妥当な制限内に収まるように、操作の並列度を選択します。



出力では、IOPSの数、待機時間、キュー深度などのパラメーターに関心があります。 テストが複数のホストで実行された場合、インジケーターが要約され（iopsおよびキューの深さ）、待ち時間についてはすべてのホストのインジケーターからavgまたはmaxが取得されます。

フィオ

ここで、実際の部分に進みます。 必要な結果を達成できるユーティリティfioがあります。



通常のfioモードでは、いわゆる ジョブファイル、つまり テストの外観を正確に記述する構成。 ジョブファイルの例を以下に示しますが、ここでは、fioの仕組みについて説明します。



fioは、指定されたファイルに対して操作を実行します。 ファイルの代わりに、デバイスが示される場合があります。 ファイルシステムを考慮から除外できます。 いくつかのテストモードがあります。 randwrite、randread、randrwに興味があります。 残念ながら、randrwは依存iopsを提供します（読み取りは書き込み後に行われます）。完全に独立したテストを行うには、読み取り用と書き込み用（randread、randwrite）の2つの並行タスクを実行する必要があります。



そして、fioに「事前割り当て」を行う必要があります。 （メーカーのトリックについては上記を参照）。 次に、ブロックサイズ（4k）を修正します。



もう1つのパラメーターは、ディスクアクセス方法です。 最も速いのはlibaioで、これを使用します。

実用的なレシピ

fioのインストール：apt-get install fio（debian / ubntu）。 どちらかといえば、squezeにはまだありません。

このユーティリティは非常に巧妙に隠されているため、「ホームページ」はなく、gitリポジトリのみがあります。 ミラーの1つを次に示します。freecode.com / projects / fio



ディスクをテストするときは、ルートから実行する必要があります。

読書テスト

起動：fio read.ini

Read.iniコンテンツ

 [readtest]
ブロックサイズ= 4k
ファイル名= / dev / sda
 rw = randread
ダイレクト= 1
バッファリング= 0
 ioengine = libaio
 iodepth = 32

タスクは、avg.latencyが10ミリ秒未満になるようにこのようなiodepthを選択することです。

テストの記録

（注意！間違ったドライブ文字-データがないままになります）

 [書き込みテスト]
ブロックサイズ= 4k
ファイル名= / dev / sdz
 rw = randwrite
ダイレクト= 1
バッファリング= 0
 ioengine = libaio
 iodepth = 32

ハイブリッドテスト

最もおいしい部分：

（注意！間違ったドライブ文字-データがないままになります）

 [readtest]
ブロックサイズ= 4k
ファイル名= / dev / sdz
 rw = randread
ダイレクト= 1
バッファリング= 0
 ioengine = libaio
 iodepth = 32
 [書き込みテスト]
ブロックサイズ= 4k
ファイル名= / dev / sdz
 rw = randwrite
ダイレクト= 1
バッファリング= 0
 ioengine = libaio
 iodepth = 32

出力分析

テスト中、次のように表示されます。

ジョブ：2（f = 2）：[rw] [2.8％完了] [13312K / 11001K / s] [3250/2686 iops] [eta 05m：12s]

角括弧内はIOPSの数です。 しかし、私たちは待ち時間に興味があるので、喜ぶには早すぎます。



出力（Ctrl-C、または最後）で、次のようになります。



^ C

fio：シグナル2で終了

読み取り：（groupid = 0、jobs = 1）：err = 0：pid = 11048
  読み取り：io = 126480KB、bw = 14107KB / s、iops = 3526、runt = 8966msec
    スラット（usec）：最小= 3、最大= 432、平均= 6.19、標準偏差= 6.72
     clat（usec）：最小= 387、最大= 208677、平均= 9063.18、stdev = 22736.45
     bw（KB / s）：最小= 10416、最大= 18176、per = 98.74％、平均= 13928.29、stdev = 2414.65
   cpu：usr = 1.56％、sys = 3.17％、ctx = 15636、majf = 0、minf = 57
   IO深度：1 = 0.1％、2 = 0.1％、4 = 0.1％、8 = 0.1％、16 = 0.1％、32 = 99.9％、> = 64 = 0.0％
     送信：0 = 0.0％、4 = 100.0％、8 = 0.0％、16 = 0.0％、32 = 0.0％、64 = 0.0％、> = 64 = 0.0％
     完了：0 = 0.0％、4 = 100.0％、8 = 0.0％、16 = 0.0％、32 = 0.1％、64 = 0.0％、> = 64 = 0.0％
      r / wを発行：合計= 31620/0、短い= 0/0
      lat（usec）：500 = 0.07％、750 = 0.99％、1000 = 2.76％
      lat（ミリ秒）：2 = 16.55％、4 = 35.21％、10 = 35.47％、20 = 3.68％、50 = 0.76％
      lat（ミリ秒）：100 = 0.08％、250 = 4.43％
書き込み：（groupid = 0、jobs = 1）：err = 0：pid = 11050
  書き込み：io = 95280KB、bw = 10630KB / s、iops = 2657、runt = 8963msec
    スラット（usec）：最小= 3、最大= 907、平均= 7.60、stdev = 11.68
     clat（usec）：最小= 589、最大= 162693、平均= 12028.23、stdev = 25166.31
     bw（KB / s）：最小= 6666、最大= 14304、per = 100.47％、平均= 10679.50、stdev = 2141.46
   cpu：usr = 0.49％、sys = 3.57％、ctx = 12075、majf = 0、minf = 25
   IO深度：1 = 0.1％、2 = 0.1％、4 = 0.1％、8 = 0.1％、16 = 0.1％、32 = 99.9％、> = 64 = 0.0％
     送信：0 = 0.0％、4 = 100.0％、8 = 0.0％、16 = 0.0％、32 = 0.0％、64 = 0.0％、> = 64 = 0.0％
     完了：0 = 0.0％、4 = 100.0％、8 = 0.0％、16 = 0.0％、32 = 0.1％、64 = 0.0％、> = 64 = 0.0％
      r / wを発行：合計= 0/23820、短= 0/0
      lat（usec）：750 = 0.03％、1000 = 0.37％
      lat（ミリ秒）：2 = 9.04％、4 = 24.53％、10 = 49.72％、20 = 9.56％、50 = 0.82％
      lat（ミリ秒）：100 = 0.07％、250 = 5.87％

このうち、私たちは（最低限）次のことに興味があります：

読み取り：iops = 3526 clat = 9063.18（usec）、つまり9ミリ秒

書き込み：iops = 2657 clat = 12028.23



スラットとクラットを混同しないでください。 slatはリクエストが送信された時間（つまり、Linuxディスクスタックのパフォーマンス）であり、clatは完全なレイテンシ、つまり、私たちが述べたレイテンシです。 読むことは書くことよりも明らかに生産的であることがわかりやすく、過度の深さを示しました。



同じ例では、iodepthを16/16に下げて以下を取得します。



読み取り6548 iops、243.79usec = 2.4ms

書き込み5301 iops、3005.13usec = 3ms



明らかに、64の深さ（32 + 32）が大きすぎることが判明したため、最終的なパフォーマンスも低下しました。 深さ32は、テストにより適しています。

パフォーマンスオリエンテーション

もちろん、誰もが既にオウムを発見しています。 観察した値を示します。

• RAMDISK（rbd）-〜200kIOPS / 0.1ms（iodepth = 2）
• SSD（Intel 320thシリーズ）-40k IOPS読み取り（0.8ms）; レコードあたり約800 IOPS（長いテスト時間の後）
• SASディスク（15k RPM）-180 IOPS、9ms
• SATAドライブ（7.2、WD RE）-100 IOPS、12ms
• SATA WDラプター-140 IOPS、12mc
• SATA WD Green-40 IOPS、iodepth = 1でも20未満のレイテンシを達成できませんでした

警告：これを仮想マシンで実行すると、

a）IOPSのためにお金を取る場合、それは非常に具体的なお金になります。

b）ホスティング事業者のストレージが不十分で、数十ギガバイトのキャッシュのみに依存している場合、大きなディスク（> 1TB）を使用したテストは、ホスティング事業者とホスティングネイバーの問題につながります。 一部のホストは気分を害し、あなたに尋ねる場合があります。

c）テストの前にディスクをゼロにすることを忘れないでください（つまり、dd if = / dev / zero of = / dev / sdz bs = 2M oflag = direct）