背景：ローカルマシンにデプロイされたWindows版の業務システムで、CPU使用率が約5％です。VMwareにインストールしたCentOS8上にLinux版の業務システムをデプロイし、リソース使用量に異常が見られます。
問題の記述
- 宿主机：win10 企业版
- VMware：17.5
- 仮想マシン：centos8
仮想マシンのリソース配分は
4C8GBで、ビジネスシステムを起動します。ビジネスシステムが仮想マシンLinuxシステムにデプロイされており、仮想マシン内部のtopコマンドでシステムのリソース使用率を確認すると、CPU使用率は高くありません。しかし、外側のWindowsシステムでタスクマネージャーを見ると、CPUリソース使用率は非常に高くなっています。プロセスを確認すると、VMware プロセスがCPUリソースを大量に使用しています。 +—————————+ | Windows | | | | +——————–+ | | | VMware | | | | Program | | | +——————–+ | | | +—————————+
知識点
この問題のトラブルシューティングは、スムーズに進まず、原因はビジネスシステム自体ではなく、仮想マシンの問題にある。通常のビジネスコードからの思考を、システム負荷に転換し、さらに負荷データの異常から、スワップ中断へと追跡し、最終的に重要なポイントにたどり着くには、VMwareのスワップ中断のパフォーマンスに影響を与えるものは何か？ 本稿ではまず各知識点を解説し、最後に解決策を示す。
Hyper-V
Windowsオペレーティングシステムの仮想化技術において、大きな変革がありました。Microsoftが最初にWSL（Windows Subsystem for Linux）をリリースした際、Hyper-Vサービスを有効にすると、VMware仮想マシンの同時使用ができなくなっていました。その後、バージョンアップにより、VMwareはHyper-Vサービスと互換性を持つようになりました。
システム負荷
Linuxシステムにおいて、「負荷」（load）とは、実行中または実行を待っているプロセスの数です。負荷は通常、1分間、5分間、および15分間の実行キュー内の平均プロセス数を表す3つの数字で示されます。これらの数字は、「uptime」コマンドまたは「top」コマンドを実行することで確認できます。
具体的には、この3つの数字はそれぞれ以下の意味を持ちます。
- 1分負荷: システムが過去1分間に実行キュー内に存在していた平均プロセス数です。
- 5分負荷: システムが過去5分間に実行キュー内に存在していた平均プロセス数です。
- 15分負荷: システムが過去15分間に実行キュー内に存在していた平均プロセス数です。
負荷の概念は、システム内で待っているプロセスの数です。この数値が高い場合、システムに多くのプロセスがCPUリソースを待機していることを意味し、システムが遅くなるか応答しなくなる可能性があります（ただし、負荷の高さとシステムの構成およびパフォーマンスによって異なります）。
理想的には、負荷はシステムの論理CPU数の範囲内に保つことが望ましく、これによりシステムのパフォーマンスを最適化できます。負荷が継続的にCPU数を超過する場合、システム内のプロセスを分析して負荷の原因を特定し、適切な対策を講じることで、リソース割り当てを調整したり、プロセスの実行方法を最適化したりすることができます。
負荷の分析 - mpstat
mpstatコマンドは、個々のプロセッサまたは複数のプロセッサに関するさまざまな情報を報告するために使用されます。これには、平均負荷、CPU利用率、割り込み、コンテキストスイッチングなどが含まれます。sysstatパッケージの一部として、mpstatはシステムの負荷状況を分析するための非常に便利なツールです。以下に、mpstatを使用して負荷を分析する手順を示します。
- sysstatのインストール:
システムに
sysstatがインストールされていない場合は、使用しているシステムに適したパッケージマネージャを使用してインストールしてください。 - mpstatの実行:
mpstatコマンドを実行して、CPUの使用状況と負荷を確認します。デフォルトでは、mpstatは1秒ごとにCPU利用率の平均値を表示します。出力頻度を調整するには、時間間隔を指定できます。たとえば、mpstat -P ALL 2を使用して、毎秒1回mpstatを実行し、irqで割り込みの使用状況を確認します。 - 出力の分析:
mpstatの出力には、各プロセッサの利用率とシステムの平均負荷が含まれています。平均負荷と各プロセッサの利用率に特に注意してください。これにより、システムの負荷状況を理解できます。負荷が高い場合は、どのプロセスが原因であるかをさらに分析し、パフォーマンスボトルネックがないか確認します。 - 他のツールの併用:
mpstatに加えて、sar、pidstat、iostatなどのツールを使用して、システム全体のパフォーマンスを総合的に分析できます。複数のツールの出力を組み合わせることで、システムの負荷状況をより包括的に理解し、パフォーマンスの問題の根本原因を特定することができます。
割り込み
本内容は詳細に説明しないため、過度な解説は省略します。 推奨: アプリケーション開発者向けシステムガイド CPU編 - ソフトウェア割り込み 頻繁にソフトウェア割り込みをトリガーすると、システム負荷にも反映されます。
問題のトラブルシューティング
CPUのみから分析するだけでは問題の原因を特定できないため、システムに異常が発生しているのではないかと疑うべきでしょうか。おそらくLinuxオペレーティングシステムの負荷が高くなり、VMwareが過剰なCPUリソースを使用している可能性があります。mpstatを使用してローカル仮想マシンを分析したところ、irqの使用量が異常で、単一コアあたり25%近く占めており、正常時にはビジネスプロセス起動時に空転する場合、irqの割合は約5%程度であるはずでした。
グループ内の同僚の開発環境では、CentOS 7がVMware上でデプロイされており、リソース使用量は正常でした。一方、上海の開発環境では、VMware上にデプロイされていましたが、ホストマシンのCPUリソース状況を直接観察することはできませんでした。この時、当社は複数の変数に直面していました：VMware仮想マシン、Linuxオペレーティングシステム、GCCバージョン。
そこでテスト環境を分析することにしました。深圳のテスト環境は物理マシン上にデプロイされており、低バージョンのGCCでコンパイルされたサービスを実行し、CentOS 8上で動作していました。興味深いことに、深圳環境ではirqの使用量は正常でした。
GCCバージョンに関連する問題が原因である可能性を調査するために、高バージョンのGCCでコンパイルしたプログラムを深圳環境にデプロイしてテストしましたが、結果も正常でした。
問題は徐々に明確になってきました。オペレーティングシステムに問題があるのではないかと疑い始めました。毕竟、CentOS 8はすでに公式サポートを受けていないためです。しかし、純粋なCentOS 7とCentOS 8を再デプロイしても問題は解決しませんでした。
この時、当社は唯一の不確実要素、つまりVMware仮想マシンソフトウェアに疑念を抱くようになりました。突然、閃きが起こり、Hyper-V技術が以前有効になっていたものの、完全にシャットダウンされなかったのではないかと考えました。毕竟、ソフトウェア中断も仮想マシンソフトウェアを通じて実現されるためです。異なる仮想マシン仮想化技術にはバグが存在する可能性があります。これらの問題は深く考える価値があります。
結論
マイクロソフト公式のマニュアルに従い、本機のHyper-Vサービスを完全に停止した後、VMwareがホストマシン上で正常に動作することが確認されました。これで問題はついに解決に至りました。当初述べたように、この経験は曲折で困難なものであり、包括的な分析と判断が必要でした。また、今回初めて問題を調査し、仮想マシンというレベルまで特定することができました。
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
bcdedit /set hypervisorlaunchtype off