私は困惑しており、誰かがこの問題の症状を認識してくれることを願っています。
ハードウェア：新しいDell T110 II、デュアルコアPentium G850 2.9 GHz、オンボードSATAコントローラー、ボックス内に新しい500 GB 7200 RPMケーブル接続ハードドライブ、他のドライブは内部にありますがまだマウントされていません。RAIDなし。ソフトウェア：VMware ESXi 5.5.0（ビルド1746018）の下の新しいCentOS 6.5仮想マシン+ vSphere Client。2.5 GBのRAMが割り当てられています。ディスクは、CentOSがそれを設定するために提供した方法、つまり、LVMボリュームグループ内のボリュームとして提供されたものです。ただし、個別の/ homeを省略し、単に/と/ bootを指定しました。CentOSにパッチが適用され、ESXiにパッチが適用され、最新のVMwareツールがVMにインストールされます。システムにユーザーがいない、サービスが実行されていない、ディスクにファイルがない、OSのインストールのみ。vSphere ClientのVM仮想コンソールを介してVMと対話しています。
先に進む前に、多かれ少なかれ合理的に設定したことを確認したいと思いました。VMのシェルでrootとして次のコマンドを実行しました。
for i in 1 2 3 4 5 6 7 8 9 10; do
dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done
つまり、ddコマンドを10回繰り返すだけで、毎回転送速度が出力されます。結果は気がかりです。それはうまく始まります：
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...
しかし、これらの7-8の後、それは印刷します
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s
かなりの時間、たとえば30〜45分待ってからもう一度実行すると、再び105 MB / sに戻り、数回（場合によっては数回、場合によっては10以上）になると、約20〜再び25 MB /秒。
考えられる原因、特にVMware KB 2011861の予備的な検索に基づいて、Linux i / oスケジューラをnoopデフォルトではなく「」に変更しました。 cat /sys/block/sda/queue/scheduler有効であることを示しています。しかし、それがこの振る舞いに何らかの変化をもたらしたとは思えません。
vSphereのインターフェースでディスクレイテンシをプロットすると、低いスループットを報告する時間中に、ディスクレイテンシが1.2〜1.5 秒に達する期間が示されddます。（そして、はい、それが起こっている間、物事はかなり応答しなくなります。）
何が原因でしょうか？
同じシステムで追加のボリュームとして他の2つのディスクも構成していたので、ディスクの障害が原因ではないことは快適です。最初はそのボリュームで何か問題があると思っていましたが、/ etc / fstabからボリュームをコメントアウトして再起動し、上記のように/でテストを試みたところ、問題が別の場所にあることが明らかになりました。おそらくESXi構成の問題ですが、ESXiの経験はあまりありません。おそらくばかげているかもしれませんが、何日にもわたって何時間もこれを理解しようとしても、問題が見つかりません。誰かが私を正しい方向に向けてくれることを願っています。
（PS：はい、このハードウェアコンボがサーバーとしてのスピードアワードを獲得できないことはわかっています。このローエンドハードウェアを使用して単一のVMを実行する理由はありますが、それはこの質問の要点ではないと思います[ただし、実際にはハードウェアの問題です。
補遺＃1：このような他の回答を読んで、私はに追加oflag=directしてみましたdd。ただし、結果のパターンに違いはありません。最初は多くのラウンドで数値が高く、その後20〜25 MB / sに低下します。（最初の絶対数は50 MB /秒の範囲です。）
補遺＃2：sync ; echo 3 > /proc/sys/vm/drop_cachesループに追加しても違いはありません。
補遺＃3：さらに変数を取り出すために、dd作成するファイルがシステムのRAMの容量よりも大きくなるように実行します。新しいコマンドはdd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=directです。このバージョンのコマンドの初期スループット数は、約50 MB /秒です。南に行くと、20〜25 MB /秒に低下します。
補遺＃4：iostat -d -m -x 1パフォーマンスが「良好」であるときに別のターミナルウィンドウで実行した場合の出力と、「悪い」場合の出力です。（これが実行されている間、私は実行していdd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=directます。）最初に、物事が「良い」場合、次のように表示されます。
物事が「悪い」となると、iostat -d -m -x 1これを示しています：
補遺＃5：@ewwhiteの提案でtuned、さまざまなプロファイルを使用してみましたiozone。この補遺では、さまざまなtunedプロファイルがdd上記の動作に影響を与えたかどうかを実験した結果を報告します。私はにプロファイルを変更してみましたvirtual-guest、latency-performanceそしてthroughput-performance、他のすべて同じに保ち、各変更後、再起動し、各時間が実行されていますdd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct。これは動作に影響を与えませんでした。以前と同様に、最初からうまくいき、多くの繰り返し実行でdd同じパフォーマンスが示されますが、10〜40回の実行後のある時点でパフォーマンスが半分に低下します。次に、を使用しましたiozone。これらの結果はより広範囲なので、以下の補遺＃6として追加します。
補遺＃6：@ewwhiteの提案で、インストールしてiozoneパフォーマンスのテストに使用しました。さまざまなtunedプロファイルで実行し、非常に大きな最大ファイルサイズ（4G）パラメータを使用しましたiozone。（VMには2.5 GBのRAMが割り当てられており、ホストには合計4 GBが割り当てられています。）これらのテストの実行にはかなり時間がかかりました。FWIW、生データファイルは以下のリンクから入手できます。すべての場合において、ファイルの作成に使用されたコマンドはでしたiozone -g 4G -Rab filename。
- プロフィール
latency-performance：- 生の結果：http : //cl.ly/0o043W442W2r
- プロットを含むExcel（OSXバージョン）スプレッドシート：http : //cl.ly/2M3r0U2z3b22
- プロフィール
enterprise-storage：- 生の結果：http : //cl.ly/333U002p2R1n
- プロットを含むExcel（OSXバージョン）スプレッドシート：http : //cl.ly/3j0T2B1l0P46
以下は私の要約です。
前回の実行後に再起動する場合もあれば、再起動しない場合もありiozone、でプロファイルを変更した後に再度実行しただけtunedです。これは全体的な結果に明らかな違いをもたらすようには見えませんでした。
tunedプロファイルは特定の詳細に影響を与えましたが、さまざまなプロファイルは（私の専門知識のない人の目には）によって報告された広範な動作に影響を与えていないようiozoneでした。まず、当然のことながら、一部のプロファイルは、非常に大きなファイルを書き込むためにパフォーマンスが低下するしきい値を変更しました。iozone結果をプロットすると、プロファイルの0.5 GBで切り立った崖が見られますlatency-performanceが、この低下はプロファイルの下で1 GBとして現れますenterprise-storage。第2に、すべてのプロファイルは小さなファイルサイズと小さなレコードサイズの組み合わせで奇妙な変動性を示しますが、変動性の正確なパターンはプロファイル間で異なりました。つまり、以下のプロットでは、左側の凹凸パターンはすべてのプロファイルに存在しますが、ピットの位置とその深さはプロファイルごとに異なります。（ただし、私は、変動のパターンは、実行の間で著しく変化した場合に確認するために、同じプロファイルの繰り返し実行しなかったiozoneことがあるので、同じプロファイルの下で可能なプロファイル間の違いのように見えるものは本当にただのランダムな変動であること。）
以下はiozone、のtunedプロファイルのさまざまなテストの表面プロットですlatency-performance。テストの説明は、のドキュメントからコピーされますiozone。
読み取りテスト：このテストは、既存のファイルを読み取るパフォーマンスを測定します。
書き込みテスト：このテストは、新しいファイルの書き込みパフォーマンスを測定します。
ランダム読み取り：このテストでは、ファイル内のランダムな場所へのアクセスが行われたファイルの読み取りパフォーマンスを測定します。
ランダム書き込み：このテストでは、ファイル内のランダムな場所へのアクセスが行われるファイルの書き込みパフォーマンスを測定します。
Fread：このテストは、ライブラリ関数fread（）を使用してファイルを読み取るパフォーマンスを測定します。これは、バッファリングおよびブロックされた読み取り操作を実行するライブラリルーチンです。バッファはユーザーのアドレス空間内にあります。アプリケーションが非常に小さなサイズの転送で読み取る場合、fread（）のバッファーおよびブロックされたI / O機能は、実際のオペレーティングシステムコールの数を減らし、オペレーティングシステムでの転送サイズを増やすことにより、アプリケーションのパフォーマンスを向上させることができます。呼び出しが行われます。
Fwrite：このテストでは、ライブラリ関数fwrite（）を使用してファイルを書き込むパフォーマンスを測定します。これは、バッファリングされた書き込み操作を実行するライブラリルーチンです。バッファはユーザーのアドレス空間内にあります。アプリケーションが非常に小さなサイズの転送で書き込む場合、fwrite（）のバッファおよびブロックされたI / O機能により、実際のオペレーティングシステムコールの数を減らし、オペレーティングシステムでの転送サイズを増やすことで、アプリケーションのパフォーマンスを向上できます。呼び出しが行われます。このテストは新しいファイルを書き込むため、メタデータのオーバーヘッドが測定に含まれます。
最後に、iozoneその作業を行っている間に、vSphere 5のクライアントインターフェイスでVMのパフォーマンスグラフも調べました。仮想ディスクとデータストアのリアルタイムプロットを切り替えました。データストアで利用可能なプロットパラメータは仮想ディスクよりも大きく、データストアのパフォーマンスプロットはディスクと仮想ディスクのプロットが行っていたものを反映しているように見えたため、ここでは、iozone終了後に取得したデータストアグラフのスナップショットのみを示します（tunedプロファイルの下）latency-performance）。色が少し読みづらいですが、おそらく最も注目に値するのは、読み取り時の鋭い垂直スパイクレイテンシ（たとえば、4：25、4：30の少し後、4：50〜4:55）。注：ここに埋め込むとプロットは判読できないため、http：//cl.ly/image/0w2m1z2T1z2bにもアップロードしました
私は認めざるを得ません、私はこれすべてをどうするかわかりません。特に、iozoneプロットの小さなレコード/小さなファイルサイズの領域での奇妙なポットホールプロファイルを理解していません。
iostat、それは前後で約90％の使用率を示しました。しかし、私はこれらのことを判断する専門家ではありません-多分飽和がどこかで起こっています。iostat役立つ場合に備えて出力を表示するように質問を更新しています。
