ESXIがホストする環境でパフォーマンスが非常に低い特定のSQLクエリ
最近、8つのデュアルコアCPU、20 GBのRAM、およびある種のRAIDにセットアップされた3つの1 TBドライブを備えた新しいマシンをセットアップし、実際に使用できる2つの1 TBドライブを作成しました（私はここにハードウェアの男）。これはESXiホストとしてセットアップされており、その中にいくつかのテスト環境がセットアップされています。現在のテストは、SQL Server 2005 Standard64ビットSP3を搭載したWindows200364ビットで実行されています。すべてのレポートから、このシステムは、以前のセットアップよりもパフォーマンスが優れている環境をホストする必要がありますが、特定のタスクのパフォーマンスははるかに低くなっています。特定の条件下で非常にゆっくりと確実に実行される特定のSQLスクリプトを見つけましたが、これは理解できません。 SQLスクリプトは、次のように始まる1700以上のUPDATEステートメントの単純なシリーズです。
UPDATE SrfItem SET fkSrfItem = 5 WHERE id = 4
UPDATE SrfItem SET fkSrfItem = 8 WHERE id = 7
UPDATE SrfItem SET fkSrfItem = 10 WHERE id = 9
これらの仮想環境のいずれかで次の手順に従うと、スクリプトの実行に9〜12秒かかることがわかりました。
テストケース＃1
- 仮想SQLServer環境のバックアップからテストデータベースを復元する
- ローカルでデータベースに接続する
- スクリプトの実行-このステップには9秒かかります
デスクトップでの同じ手順で、手順3が1秒未満で実行されました。
テストケース＃2
- 物理SQLServer環境のバックアップからテストデータベースを復元する
- ローカルでデータベースに接続する
- スクリプトの実行-このステップは1秒未満で完了します
ただし、トランザクションでスクリプトを実行するとすぐに実行されます
テストケース＃3
- 仮想SQLServer環境のバックアップからテストデータベースを復元する
- ローカルでデータベースに接続する
- スクリプトの先頭に「BEGINTRAN」を追加します
- スクリプトの最後に「COMMITTRAN」を追加します
- スクリプトの実行-このステップは1秒未満で完了します
私が興味深いと思うのは、トランザクションで一度実行してロールバックした後でも、実行速度が遅いことです。
テストケース＃4
- 仮想SQLServer環境のバックアップからテストデータベースを復元する
- ローカルでデータベースに接続する
- スクリプトの先頭に「BEGINTRAN」を追加します
- スクリプトの最後に「ROLLBACKTRAN」を追加します
- スクリプトの実行-このステップは1秒未満で完了します
- トランザクションを含まないスクリプトの部分のみを実行します。この手順には9秒かかります。
Windows 200332ビットおよびSQL2005 32ビット以降の仮想システムと、Windows 200864ビットおよびSQL200864ビットの仮想システムでテストを実行しました。 Windows2003とSQL2005を搭載した物理システムと、Windows 764ビットとSQL2008 R264ビットを搭載した物理システムでテストを実行しました。私が試したすべての仮想システムはこの速度低下を示し、新しいESXi環境でホストされています。すべての物理システムがこの速度低下を示すわけではありません。
誰かが私がここで何が起こっているのか理解するのを手伝ってくれる？同様のパフォーマンスの問題が他の領域に影響を及ぼしているのではないかと心配しています。ホストまたはゲスト環境で何かを再構成する必要があります。これまでに考えられる唯一のことは、ホストマシンのBIOSでハイパースレッディングをオフにして、遅い動作を確認できなかった別の仮想環境とそのホストの構成に一致させることです（テストを観察しませんでした）遅くなかった他の仮想環境とホスト）。それはそのような大きなパフォーマンスの違いを生み出すことができますか？
編集：私の質問と最初の回答を確認した後、私が何とか実証したのはおそらくI/Oレイテンシのパフォーマンスの違いであることに同意します物理環境と仮想環境の間。また、他の詳細を提供する必要があることも認識しています。これらのイメージはシンプロビジョニングを使用しており、その下に2つまたは3つのスナップショットがあります。これはその統計にそれほど大きな影響を与えるでしょうか？ここで問題となるのは、この統計が仮想環境と物理環境の間で大幅に異なるのは正常なことですか？環境またはSQL構成でそれを最適化できる必要がありますか、それとも極端なI/O遅延のある仮想システムに対してより最適に記述されるのはソフトウェア自体次第ですか？
vSphereクライアントは、仮想ディスクの書き込み遅延が11〜40ミリ秒で、平均21ミリ秒であると報告しています。それは有用な統計ですか？それは極端ですか？
編集：ハードウェア（DL380 G6）には、 http://laez.nl/vmware-bad）で説明されているパフォーマンスの問題があるようです。 -performance-on-hp-proliant-dl380-g6-with-esxi-3-5-u4 / パフォーマンスを上げるには、再構成を行う必要があります。ディスクI/Oの待ち時間が問題であると私たちを正しい方向に導いた答えを受け入れます。
総括する：
- 実サーバーでは、1秒未満で1700のテーブル更新と1700のコミットを行うことができます。
- 仮想サーバーでは、9秒で1700のテーブル更新と1700のコミットを行うことができます。
- 仮想サーバーでは、1秒未満で1700のテーブル更新+1つのコミットを行うことができます。
したがって、問題は「実サーバーでは1秒未満で1700のコミットを実行できますが、仮想サーバーではパフォーマンスが10分の1に低下する」と再定義できるように思われます。
1700テーブルの更新と1700コミットの違いは何ですか？テーブルの更新は完全にキャッシュされ、ディスクI/Oにまったく依存しません。コミットでは、これはまったく異なります。トランザクションデータベースの性質上、データベースエンジンは、commitが実際にはディスクに保存されている（ログファイルに保存されている）であることを確認する必要があります。次のトランザクションのコミットを開始します。したがって、これらの1700コミットごとに、I/Oラウンドトリップ全体を待機する必要があります。要約すると、シナリオでは、I/Oのレイテンシーが非常に重要な役割を果たし、分析する必要があります（レイテンシーをI/Oレートまたはバイト単位のスループットと間違えないでください。これら3つはすべてまったく異なる動物です。常に個別に調整されます）。
IOMeterを使用してストレージをテストすることをお勧めします。ディスク全体をテストファイルでいっぱいにしようとするため、起動時にハングします。ファイルがかなりの量になるまで待ってからIOMeterを再起動すると、「不完全な」テストファイルで正しく機能します。
あなたの説明は、この問題にいくらかの光を当てています。
3ドライブSATARAID 5パックは、書き込みパフォーマンスに最適なディスク構成ではありません。各書き込みIOには[最大] 4つのディスクIOが発生します（現在のブロックの読み取り、現在のパリティの読み取り、新しいブロックの書き込み、新しいパリティの書き込み）。これにより、3つの7200rpmディスクがディスクになります。ベースドライブが7200rpmであると仮定すると、これは単一の5400rpmドライブのように動作します。
次に、SQLVMにアクティブなスナップショットが多数あると言います。 VMware ESXiスナップショットには、些細なことではないオーバーヘッドが発生します。実行内容によっては、アクティブなスナップショットがある場合、50〜100％IOオーバーヘッドが発生します。これは、読み取りと書き込みの両方に影響します。
第三に、シンプロビジョニングを使用していると言います。これはIOのパフォーマンスに影響を与えますが、他の2つほど重要ではありません。
最後に、ESXiホストで実行されている他のVMがあるかどうかはわかりません。ある場合は、特にRAID5 x 1TBSATAディスクセットアップで全体的なパフォーマンスに明らかに影響します。
仮想化システムに問題があると判断するためのテストは、それほど堅牢ではないと思います。 1秒間のテストでは、システムにストレスを与えて実際のボトルネックを明らかにするのに十分な時間がありません。
仮想化された世界とSQLServer内には多くの可動部分があります。ここではディスクIOが主要なプレーヤーですが、RAMもあると思います。ESXはオンデマンドでゲストからRAMを授受でき、場合によっては数秒かかることもあります。 ESXが反応し、短い一時停止が発生します。サーバーに一定の負荷がかかっている場合、ESXはRAMを安定させますが、テストが短くバーストしている場合は、立ち上がるまでに時間がかかることがあります。
赤ちゃんをお風呂の水で捨て始める前に、より長いテストを実行し、ESXで監視して、RAM使用量、ディスクIOレイテンシー、CPUキューの長さ良いテストは、物理マシンで実行するのに30〜60秒かかり、仮想マシンはその150％以内になると思います。