VMware上で実行されている仮想化SQLServerのCPUパフォーマンスの問題をトラブルシューティングするとき、私が最初に行うことの1つは、仮想マシンの構成がパフォーマンスの問題の原因ではないことを確認することです。物理サーバーにOS専用の利用可能なリソースが100％ある場合、仮想マシンにはありません。そのため、いくつかの基本的な項目を前もって確認することで、間違った問題のトラブルシューティングや時間を無駄にすることがなくなります。過去に、パフォーマンスの問題の基本的なトラブルシューティングのために、仮想センターforVMwareへの読み取り専用アクセスを持つDBAの重要性についてブログを書きました。ただし、Virtual Centerにアクセスしなくても、パフォーマンスに影響を与える潜在的なホストレベルの問題につながる可能性のあるWindows内の基本情報を見つけることは可能です。
すべてのVMware仮想マシンには、VMwareツールがゲストにインストールされたときに追加されるWindowsの2つのパフォーマンスカウンターグループがあります。 VMプロセッサとVMメモリ。これらのパフォーマンスカウンターは、VMがハイパーバイザーから受信しているリソースを確認できるため、VMwareで仮想マシンを使用しているときに最初に確認するものの1つです。 VMプロセッサグループには、次のカウンタがあります。
- ％プロセッサ時間
- 有効なVM速度（MHz）
- ホストプロセッサの速度（MHz）
- MHzでの制限
- MHzでの予約
- 共有
タスクマネージャまたはパフォーマンスで高いプロセッサ\％プロセッサ時間を示しているVMゲストでは、VMプロセッサカウンタをチェックすると、VMゲストが受け取っている実際のリソース割り当ての正確なアカウントが得られます。ホストプロセッサの速度（MHz）が3000で、ゲストに8つの仮想CPUが割り当てられている場合、VMの最大有効速度は24000 MHzであり、有効VM速度（MHz）カウンターは、VMが実際にリソースを取得しているかどうかを反映します。ザ・ホスト。通常、これが当てはまる場合は、問題の根本原因をさらに診断するために、ホストレベルの情報を調べ始める必要があります。しかし、最近のクライアントエンゲージメントでは、これは当てはまらないことが判明しました。
この場合のクライアントVMは、上記の構成と一致し、最大有効速度は24000 MHzでしたが、MHzカウンターでの有効VM速度は平均で約6900 MHzであり、VM Windowsパーセントプロセッサ時間はほぼ100％に固定されていました。 MHz単位の有効VM速度カウンターのすぐ下を見ると、問題の原因が明らかになりました。MHz単位の制限は7000でした。つまり、VMにはESXの7000MHzでCPU使用率の上限が設定されていたため、ハイパーバイザーによって常に抑制されていました。ロード。
これについての説明は、この特定のVMは概念実証のテスト目的で使用されており、元々はビジー状態のVMホストに同じ場所に配置されていたというものでした。 VM管理者は、そのホストでパフォーマンスの問題を引き起こす未知のワークロードを望んでいませんでした。そのため、POC中にホストの実際の本番ワークロードに悪影響を与えないようにするために、ホストで7000MHzのCPUまたは21/3の物理コアに相当するもののみを許可するように制限されていました。最終的に、ESXでVM CPU制限を削除すると、Windows内の高いCPUの問題が解消され、クライアントで発生していたパフォーマンスの問題が解消されました。
VMメモリカウンターグループは、SQLServerの潜在的なパフォーマンスの問題を特定するためのVMプロセッサグループと同じくらい重要です。 VMメモリカウンターグループには、次のカウンターが含まれています。
- MB単位でアクティブなメモリ
- メモリはMB単位で膨らみます
- MB単位のメモリ制限
- MB単位でマップされたメモリ
- MB単位のメモリオーバーヘッド
- MB単位のメモリ予約
- MB単位で共有されるメモリ
- 共有メモリをMB単位で保存
- メモリ共有
- MB単位でスワップされたメモリ
- MBで使用されるメモリ
これらのカウンターのうち、私が具体的に調べているのは、MB単位のメモリバルーンとMB単位のメモリスワップです。どちらもSQLServerワークロードではゼロである必要があります。 [MBでバルーン化されたメモリ]カウンターは、ホストでのメモリのオーバーコミットにより、バルーンドライバーによってゲストVMから再利用されたメモリの量を示します。これにより、SQL Serverは、バルーンドライバーによって引き起こされたWindowsのメモリプレッシャーに対応するためにメモリ使用量を削減します。 VMからメモリを奪うために膨らませます。メモリスワップインMBカウンターは、VMゲストをバルーンドライバーでバルーニングすることによって解決できなかったホスト上のメモリオーバーコミットが原因で、ホストハイパーバイザーによってディスクにページングされたメモリの量を追跡しています。 SQL Serverに関するVMwareのベストプラクティスガイドでは、予約を使用して、パフォーマンス上の理由でSQL Serverが膨らんだりページアウトしたりしないようにすることを推奨していますが、多くのVM管理者は、環境の柔軟性が低下するため、静的予約を設定することを躊躇しています。
SentryOneVSentryなどの監視ツールも役立ちます。あなたがvCenterに直接アクセスできないかもしれないが、誰かがあなたに代わってそれに対して監視を設定できる場合を考えてみてください。これで、ゲストレベルとホストレベルの両方で、CPU、メモリ、さらにはディスクの問題、さらにはそれに伴うすべての履歴について、優れた視覚化と洞察を得ることができます。下のダッシュボードでは、左側にホストメトリック（コストップ時間と準備時間のCPUブレークダウンを含む）、右側にゲストメトリックが表示されます：
SentryOneのこの機能やその他の機能を試すには、無料トライアルをダウンロードできます。
結論
VMware上の仮想化SQLServerのパフォーマンスの問題をトラブルシューティングするときは、限られた情報のみを使用して「ひざまずく」トラブルシューティングを行うのではなく、全体的な観点から問題を確認することが重要です。パフォーマンスモニターのVMware固有のカウンターは、問題のトラブルシューティングをさらに進める前に、VMがホストから基本的なリソース割り当てを取得していることをすばやく確認するための優れた方法です。