仮想サーバーにコアを追加する時期はいつですか？
Java 7およびTomcat7を備えたLinux（RHEL 5.8）サーバーがあります。
パフォーマンスは低く、遅いのはDBクエリだと確信しています。
現在2つのコアがあり、負荷平均が1.5を超えることはなく、2番目のコアの使用率は多くの場合0％です。彼らは、コアを追加して、それが役立つかどうかを確認したいと考えています。そうはならないと思います。通常、すべてのコアが少なくともしばらくの間最大になっていることがわかった場合にのみ、別のコアを追加します。
これについてどう思いますか？コアを追加する時期はいつですか？
詳細 DBは、DBAが管理する別のボックスにあります。私はLinuxのシステム管理者です。
CPU：Intel（R）Xeon（R）CPUの2コアX5675 @ 3.07GHz 16 GB RAM 2GBスワップ8GBがヒープに割り当てられている場合、ヒープの使用量は通常4 GB未満の場合、スパイクは約120％で約6GBのCPU使用率のスパイクです。
あなたのパフォーマンスはコアカウントとは何の関係もないかもしれません。 Yoは、I/Oに制約があるか、システムに十分なRAMがない可能性があります。
基盤となるシステムハードウェアの仕様は何ですか？例えば。 CPUモデル、クロック速度、RAM量。
別のメトリックと比較してパフォーマンスが低下していますか？あなたの期待？パフォーマンスはいつも悪いですか？
一般に、コア数が十分かどうかを判断する方法として、システム負荷を検討します。それはあなたの状況で適切なレベルにあるように聞こえます。
パフォーマンスは低く、遅いのはDBクエリだと確信しています。
それが問題であると確信している場合は、MySQLまたはMSSQLのインストールを最適化しましたか？パフォーマンスチューニングなしでソフトウェアをインストールするだけでは、より多くのリソースを投入するだけでは解決できません。
ここにあるMySQL Tuning Primer Script を使用することをお勧めします。非常に使いやすく、推奨事項は非常に的確です。
セットアップによっては、手動でパフォーマンスを調整する方法を学ぶ必要がある場合があります。つまり、MySQL出力を自分で解釈して操作する方法を学ぶ必要がありますが、このスクリプトは、これまでに使用したセットアップの95％で非常にうまく機能します。他の5％は、より多くのカスタムケアを必要とするデータベース固有のセットアップです。 MySQLパフォーマンスブログのこれ のようなチュートリアルを強くお勧めします。
コアを追加する前に、実際に使用されているリソースを確認することをお勧めします。たとえば、システムがIOバインドされている場合、コアを追加するとお金が無駄になりますが、アップグレードします。ディスクまたはRAMで問題が解決する可能性があります。vmstat（「vmstat2」など）を実行し、io、メモリ、CPUを監視して、何が起こっているのかを少し感じてみてください。
I/O制約が最も可能性があります。
SSD？
仮想化環境にいるので、CPUとメモリの追加/削除は非常に簡単で、基本的には何もしません。だからそれをするだけです。次に、パフォーマンスの向上が見られない場合は、アプリケーションプロファイリングレポートをポイントして、「そう言った」と言います。
VMにコアを追加するタイミングを決定するときに使用する複数のメトリックがあります。おっしゃるように、コア使用量は最も明白な指標の1つです。その他には、アプリケーションの実際のコアパフォーマンスとマルチスレッド機能が含まれます。
CPUは、使用率が10％を超えることなく、パフォーマンスのボトルネックになる可能性があります。通常、これはCPUが非常に遅い場合（1ghz対2.5ghz）であり、基盤となるホストハードウェアをアップグレードする必要があります。 （私の1.5GHzタブレットは、CPU使用率が10％を超えることはありませんが、痛々しいほど遅いです。CPUが遅いだけです！）
マルチスレッドではないアプリケーションはまだたくさんあるので、それらにいくつのCPU（コア）を投入しても、それらが複数を使用することはありません。通常、この場合、VMにさらに追加する前に、複数のCPUを利用するようにアプリケーションをアップグレードすることを検討する必要があります。また、一部のオペレーティングシステムにも制限があります（通常はライセンスに基づいています）。たとえば、Windows Server 2003 Standardは4つの物理CPUのみをサポートしますが、CPUあたりのコア数は考慮しません。これは、仮想CPUを追加するかvCPUあたりのコアをVMに追加するかに影響する可能性があります。
ホストリソースの使用量が最小限であると仮定すると、パフォーマンスメトリックが通常の営業時間中に50％を超える平均（平均）CPU使用率を示している場合、コアをVM）に追加します。これは任意の数です。 、およびアプリケーションと使用パターンに応じて、平均CPU使用率が25％または75％になるようにコアを増やす必要がある場合がありますが、平均が75％に達するまでには、変更を加えるのはおそらく過去のことです。注意が必要です。 CPUが通常5％であるが、数分ごとに100％に急上昇する場合、急上昇の原因を特定するまでコアを追加したくないでしょう。参考までに、vSphereにはこれらのパフォーマンスメトリックがあります。組み込み。
編集上の注意：これは、Webサーバーなど、負荷がかなり一定しているアプリケーションにおそらく最も適しています。 4時間ごとに20分間コードをコンパイルする開発サーバーなど、ヒットアンドミスの負荷がかかるアプリケーションは大きく異なります。その場合、アプリケーション（コンパイラー）のパフォーマンスと、そのアプリケーションの実行中（コンパイル）でのピークCPU使用率を確認します。コンパイラがマルチスレッドである限り、コンパイル操作全体で100％CPUを使用すると、CPUを増やすことでメリットが得られる可能性があります。しかし、その後、開発者が 再生時間 を半分に減らしたことであなたに腹を立てることを心配する必要があります。
MS SQLServerやMSExchangeなどの一部のアプリケーションは、意図的にリソースを占有します（メモリが最も目立ちます）。これは仕様によるものであるため、アプリケーションの動作に注意する必要があります。実際のアプリケーションのパフォーマンスとリソース使用量を比較検討する必要があります。SQLサーバーが100％CPUを使用していて応答が速い場合は、100％CPUを使用して応答が遅いSQLサーバーとは異なります。
アプリケーションのパフォーマンスが遅いが、メトリックとベンチマークでCPUがボトルネックではないことが明らかになった場合は、コアの追加について心配する必要はありません。ただし、ダウンタイムとホストリソースが問題にならない場合は、コアを一時的に追加して、ポイントを証明します。ユーザーは10分に相当する時間しかかかりません。
また、VMWare ESXiのような優れたハイパーバイザーでは、オーバープロビジョニングが可能であることに注意してください。つまり、ホストに8コアしかない場合でも、それぞれ4コア（合計16コア）の4つのVMをプロビジョニングできます。ハイパーバイザーは、ホストリソースを最も必要とするVMに動的に割り当てます。したがって、アイドル状態のVMが3つある場合、4番目のVMはホストをできるだけ多く噛むことができます。一部のアプリケーションはコアごとにまたはCPUごとにライセンスされているため、注意が必要なのはライセンスですであり、マシンまたはOSのインストールごとではありません。