私たちは約 300 人の同時ユーザーを持つアプリケーションを使用しています。現在、すべてが仮想化されています。1 つの VM はロード バランサーとして、2 つの VM は Web サーバーとして (この ESXi ホストにはさらに 25 台の VM があります)、1 つのサーバー (ベア メタル) は SQL Server として使用されています。パフォーマンスに問題があるため、物理ハードウェアを購入してパフォーマンスを向上させることにしました。
どうすればパフォーマンスを向上できるかわかりません。
1ラックのサーバーハードウェアを購入し、上記の3つのVMだけでESXiを実行します。
Web サーバー用に 1-1 ラック サーバー ハードウェアを購入し、アプリケーションのみを含む Windows サーバーをインストールします (ロード バランサーは以前の VM のままにします)
- ロードバランサー用と 2 つの Web サーバー用に 3 台のラック サーバーを購入します。
ユーザーは Web インターフェイス / デスクトップ アプリを使用してサーバーに接続します。
助けてくれてありがとう、drewo
答え1
今後の進路を決める前に、答えを見つけておくべき情報がいくつかあります。
影響を受けるVMのCPU使用率
- ゲスト オペレーティング システムの観点から、CPU 使用率が頻繁に 80% を超えたり、使用率が急上昇するのではなく横ばいになったりしていませんか? VM の CPU が不足している可能性があります。vCPU を追加してください (ただし、ライセンスの問題が発生する可能性を考慮してください)。
- サーバー内の一部の vCPU の負荷が他の vCPU よりも大幅に低いですか? アプリケーションにスケーリングの問題がある可能性があり、1 つの VM (または物理マシン) に vCPU を追加するだけでは問題は解決しません。
- 時間は、ホストがオーバーコミットされていることを示していますか
CPU ready? 時々見かける経験則では、平均準備時間は 5% 未満に抑えることが望ましいとされていますが、私の経験では、実際に作業するシステムではそれでも長すぎます。vCenter を使用する場合、表示される準備時間は、最後のグラフ更新以降の集計ミリ秒単位であることに注意してください。「リアルタイム」ビューでは、グラフは 20 秒 (=20000 ミリ秒) ごとに更新されるため、VM の CPU あたりの平均パーセンテージは、次の式を使用して計算できます(indicated_ready_time * 100 / 20000) / number_of_vcpu。
RAM使用量
(ゲスト オペレーティング システム内から常にチェックする必要があります)
- 通常は 80% 以上ですか? メモリを追加してください。
- メモリ リークの兆候がありますか? アプリケーションを修正するか、より頻繁に再起動する準備をしてください。
- スワッピングが頻繁に発生している兆候がありますか? 構成の問題がないか確認してください。メモリを追加してください。
- 不可解なことに 4 GB 未満のメモリしか使用しない主要なアプリケーションやプロセスはありますか? 64 ビット アドレスを使用するには、それらを再構築または再構成する必要がある可能性があります。
また、ディスクとネットワークのパフォーマンスをチェックして、遅延の問題がないか確認してください。
アプリケーションの拡張方法によっては、既存の Web サーバーに計算能力やメモリを追加するのではなく、Web サーバーをさらに追加することが適切な場合があります。
ボトルネックがどこにあるのか、ハードウェアを最も効果的に活用するにはどうすればよいのかがわかったら、何を購入するかについてのビジネスケースの作成を開始できます。
仮想マシンの主な利点は、管理やバックアップが容易で、システム障害が発生した場合の移行が容易なことです。仮想マシンは、実際に投入できるすべてのリソースを必要としない限り、ハードウェアをより有効に活用できます。また、準仮想化ネットワーク インターフェイスを使用する場合、同じホスト上のマシン間の通信は、物理ネットワーク インターフェイスの速度に制限されるのではなく、CPU が管理できる速度で行われます。
物理マシン上で直接実行されるシステムでは、もちろん、リソース共有によるオーバーヘッドは発生しませんが、これは利用可能な電力を使用できる場合にのみメリットとなります。
答え2
パフォーマンスの問題の原因を調査し、アプリケーションに関する知識がなければ、最も簡単かつ最適な修復方法が何であるかを判断することはできません。
問題が実際にハードウェア リソースの不足である場合、監視によって、現在どこで限界に達しているか、何を購入すればよいか (CPU コアまたは CPU 速度、RAM メモリの増加、ディスクの高速化)、そしてそれをどこに割り当てるかがかなり明確になるはずです。
私の経験では、パフォーマンスの問題の半分以上は、ハードウェア リソースを追加で投入するのではなく、適切なチューニングを行うことで簡単に解決できます。ほとんどの開発者とベンダーの多くは、実稼働環境で発生するのと同じ量のデータと負荷の両方でアプリケーションとデータベース バックエンドをテストする能力やリソースがなく、実際にはあまりうまく拡張できない仮定と設計の選択を行っています。
注意深く監視することで、ボトルネックが何であるか、アプリケーション、データベース、またはハードウェア レベルで何に対処する必要があるかを把握できます。
パフォーマンス分析とチューニングは、科学であると同時に黒魔術でもあることに注意してください。
簡単に解決でき、多くの場合大きなメリットをもたらす非常に一般的なアプリケーションの問題は、
- データベースのインデックスが欠落している
- 接続プールとクエリキャッシュ
- メモリ制限、接続数、ソケット、アプリケーションの同時スレッドの調整
アプリケーション設計における、対処がより難しい欠陥としては、アプリケーションのフロントエンドにデータ処理ロジックが多すぎる場合や、データベース クエリが単純かつ非バインドで、返されるデータが多すぎる場合 ( などSELECT * from GrowingDataSet) などがあります。監視すると、このような欠陥の症状は、データベース サーバーでのディスク IO 負荷が高い、アプリケーション サーバーでのメモリ消費量が多い、ネットワーク リンクが飽和しているなど多岐にわたります。これらのそれぞれは、さまざまなハードウェア購入の決定 (データベース サーバーでの SSD へのアップグレード、アプリケーション サーバーの RAM の増加、ネットワークのアップグレード) をサポートするために使用できますが、アプリケーションがクエリでより適切なロジックとページネーションを適用し始めると、おそらくこれらのいずれも不要になります。