キャパシティプランニングのための正確な傾向のランダムI / Oパフォーマンス
私が働いている場所には、Xenハイパーバイザーを使用して多くの仮想マシンをホストするために使用される多数の「ビッグアイアン」サーバーがあります。これらは通常、32GB RAM、デュアルクアッドコアプロセス、およびI/O容量のゴブを備えた高速ディスクで構成されます。
私たちは、既存のハードウェア構成が少し長くなっている時点で、外に出て、より大きく、より速く、より光沢のある新しいハードウェアを調達する時が来ました。
上記のように、既存のキットは32GB RAMで展開されており、ホストに展開できるVMの数が事実上制限されています。
ただし、新しいハードウェアを調査すると、単一のシャーシ内に64、72、さらには96GBの単一のマシン内でより多くのRAMを取得できることは明らかです。これにより、取得できるようになります。特定のホストへのマシンの数が増えると、常に勝利になります。これまでに完了した分析では、制限要因がディスクサブシステムにシフトされることが示されています。
問題は、私たちがどこにいるのかを把握しようとしていることです...使用法のおかげで、I/O帯域幅の点で制限されていないことがわかります。つまり、ランダムなIの数です。完了することができる/ O操作..このポイントに達すると、iowaitはスカイロケットになり、マシンのパフォーマンス全体が犬に行くことを偶然に知っています。
これが私が尋ねている質問の核心です。特に、完了しているランダムI/O操作の数に関連して、既存のI/Oパフォーマンスを正確に追跡/傾向分析する方法を知っている人はいますか？
私が実際にメトリックを取得しようとしているのは、「この構成はX個のランダムI/O要求を正常に処理でき、現在（平均して）ZopsのピークでYopsを実行している」ということです。
前もって感謝します！
sarはここでうまく機能します。トランザクション数と1秒あたりの読み取り/書き込みセクターを収集します。これを使用して、IOワークロードを比較的適切な精度で再生できます（読み取り/書き込み比率の観点から、また、トランザクションサイズは、IOがランダム」であるかどうかを決定する要因です。これは完璧ではありませんが、私の経験では、ある種の見積もりを行うのに十分な仕事をしています。あなたが見ている。
したがって、これは監視と容量レポートの問題のように見えます。トレンド統計の測定を開始する場合は、全体的に調べて、比較、相関などを行うことができます。
ツールに関しては、オープンソースの世界には神経節、ゼノス、ナギオなどがあり、他にも多数のベンダー製品があります。
関心のあるKPIを追跡、測定、および保存するように構成し、定期的にレポートすることができます。
RAM使用量に関するクエリを考えると、メモリ統計、スワップ使用量、およびCPUも含めるのが理にかなっているので、同じ期間にそれらを全面的に比較して、どれが制限されているなど。
データをキャプチャしたら、レポート用にすべてを素敵な大きなDBに保存できます。たとえば、履歴データを希薄化する可能性があります。さらに遡ると、5秒ごとのメトリックを6か月間、次に分単位で、次に5単位で、次に1時間ごとに保存します。そのようなことは、スクリプトを作成してcron、autosysなどで実行できます。
これらのレポートは、経営陣が望むものを提供します。きれいなグラフのあるもの。
また、日常の管理では、コンソールを介してチャート/図のリアルタイム情報を確認し、特定の瞬間のパフォーマンスを確認できます。
collectl を使用します。これは、必要なすべての情報を1つのファイルにプルして、必要に応じて統計を再生できるためです。これにより、記録間隔ごとのIOPSの数、コンテキストスイッチ、メモリ統計を確認できます。これをディスクごとに分類することも、システム全体を確認することもできます。 Collectlは光沢もサポートしています。
これは、システム全体のパフォーマンスの概要を把握するための優れたツールです。幸運を祈ります。ランダムアクセスを行う場合、SATAディスクは通常200〜300IOPSで最高になります。
他のすべてのメトリックを実行するのと同じ方法で、ディスクI/Oを記録およびグラフ化します。
データは、SNMPを使用してホストから取得されます。 NAS/SANボックスはこれをネイティブに実行します。すべてのLinuxホストで net-snmp を使用し、 SB-DISKIO-MIB からこの情報を提供します。
データは（RRD形式で）保存され、 Cacti を使用してグラフ化されます。一部の ディスクIOテンプレート トランザクションの数とサイズを、通常の現在、平均、およびピークの形式で表示します。
これらのメトリックは、ホストでiostat/dstat/sarを使用する場合ほど有限である必要はありません。しかし、それは火事で忘れてしまいます。これは、新しいマシンが試運転されると自動的にセットアップされ、一元的に保存され、将来の参照に利用できるようになります。
このデータを使用して、運用ベースで異常な傾向を警告し、容量計画を実行するときは常にそれを振り返ります。
私が実際にメトリックを取得しようとしているのは、「この構成はX個のランダムI/O要求を正常に処理できる[..]」です。
これにはいくつかの問題があります。
ランダムI/OをシーケンシャルI/Oから分離して定量化することは非常に困難です。 2つの基本的な違いは、ディスクプラッターに格納されているブロックの物理的な場所です。多くの小さなトランザクションおそらくがディスクに点在する小さなファイルに関連していることに基づいて、トランザクションのサイズから知識に基づいた推測を行うことができます。しかし、保証はありません。 mightは、単一のファイルまたはディスク上の隣接するブロックから少量のデータを順番に読み取っている可能性があります。
メトリックを記録すると、現在のコミットメント、時間の経過とともにどのように変化するか、したがって将来どのように変化するかを非常によく把握できます。それがあなたに教えてくれないのは、天井が何であるかです。少なくとも手遅れになる前ではありません。これを決定するには、（ハードウェア仕様から）いくつかの計算、ベンチマークを行う必要があります（私は
bonnie++私自身）そしてそれらのdomUが何をしているのか/何のために使われているのかについてのロジスティックな考えを持っていることは役に立ちます。
人々がSARを使用している場合、少なくとも数秒ごとにデータをサンプリングしていることを願っています。 collectlを使用するときは、1秒に1回サンプリングします。ランダムI/Oのパフォーマンスを測定する限り、Robin Millerのdt（google it）などのツールを使用すると、ランダムI/Oを簡単に生成して、collectlで測定するだけで何人かを確認できます。 1秒あたりに実行できます。一般的なディスクは通常、回転待ち時間にほぼ基づいて、最大200〜300 I/Os /秒を実行します。ディスクが正しい位置に来るのを1/2回転待つと、他のすべてが圧倒されるため、ブロックサイズの影響は最小限でした。
ところで-iowaitは最も誤解されている測定値の1つです。 CPUの負荷とは何の関係もありません。つまり、I/Oが発生している間CPUが他に何もしていなかったことを意味します。実際、100％iowaitを使用している場合、それは基本的に約100％アイドル状態であることを意味します。
-マーク
ストレージバックエンド（IBM SVC/DS8000）によっては、ランダムIOPSに関連する統計をストレージバックエンドから直接取得できる場合があります。
サーバーから統計をプルするには、 nmon を使用できます。それは無料です（ビールのように）。もともとIBMfor AIXによって開発されたもので、Linuxでも動作します。