CPUのIPCとクロック周波数：ホスティング用プロセッサを正しく比較する

CPU IPC：1クロックあたりの命令数

CPU IPC これは「Instructions per Cycle」、つまり1クロックサイクルあたりの命令数を表します。 特定の測定範囲において、通常は、その範囲内で完了したマシン命令の数を、同じ範囲内でカウントされたCPUサイクルの数で割ります。この文脈において、IPCが2であるということは、カウントされた1サイクルあたり平均2つの命令が完了したことを意味します。

この値は 仕様の特徴、プロセッサのあらゆるタスクに適用される固定の指標というわけではない。同じシステムであっても、データへのアクセスが容易な計算では、メインメモリからのデータを頻繁に待機しなければならないデータベースクエリの場合とは異なるIPCとなる。また、扱うデータセットや対象となるプログラムのセクションによっても、結果は異なる。

キャッシュは、頻繁にアクセスされるデータをCPUの近くに保持します。もしコアが、代わりに処理速度の遅いメモリアクセスを待たなければならない場合、実行ユニットが一時的に遊休状態になってしまうことがあります。同様に、プログラムの実行における命令間の依存関係や分岐も、同時に実行できる処理量に影響を与えます。 したがって、IPCが低いことはさらなる調査のきっかけにはなりますが、それだけでは明確な診断とはなりません。

また、マシン命令は、完了したWebリクエストに対する標準化された単位ではありません。コンパイラ、命令セット、ベクトル化の影響により、同じタスクを実行する異なるプログラム間で、必要な命令数が異なる場合があります。したがって、IPCが高いという事実だけでは、応答時間が短いことや、1秒あたりのリクエスト数が多いことを証明するものではありません。

比較を行う上で重要なのは、その数値の背景にある用途と測定範囲です。これらの情報が欠けたIPC値では、システムがそもそも同じ作業を行っているのかどうかが不明瞭になります。クロック、コア、メモリ階層の相互関係に関するさらなる基礎知識については、以下の記事をご覧ください。 ホスティングにおけるCPUアーキテクチャ.

サーバーのクロック周波数とブーストについて理解する

クロック周波数は、CPUが1秒間に実行するサイクル数を表します。1ギガヘルツ（略してGHz）は、1秒間に10億サイクルに相当します。この数値だけでは、プログラムがこれらのサイクル内でいくつの命令を完了するか、あるいはそれによってどれだけの有用な処理が行われるかは分かりません。

データシートには、しばしば 基本周波数 および最大ブースト。基本周波数は仕様値として用いられ、ブーストは適切な条件下で達成可能なより高い周波数を指します。いずれの数値も、実際の使用時およびそれぞれの負荷条件下で実際に達成されるクロック周波数を観察することに代わるものではありません。

その一例がAMD EPYC 9655です。このモデルについて、AMDは96コア、192スレッド、2.6 GHzのベースクロック、最大4.5 GHzのブーストクロックを公表しています。 これらの数値は、プロセッサの仕様および周波数に関するものです。これらは、測定されたIPCでもなければ、特定のホスティングスループットを保証するものでもありません。

EPYC 9005シリーズについて、AMDは 最大ブースト 通常のサーバー稼働条件下で、単一のコアが到達し得る最高周波数として。したがって、9655の「最大4.5 GHz」という数値は、96コアすべてがこのクロック周波数を継続的に維持できることを保証するものではありません。電力および温度の制限が、負荷時の動作に影響を与えます。

短時間の単一タスクでは、一時的に高いクロック周波数が重要になる場合がありますが、長時間にわたる並列負荷の場合、システムが実行時間全体を通じてどの程度の性能を発揮するかが重要になります。このシリーズの他のモデルは、周波数やコア数が異なります。単に最大のGHz値だけで比較すると、こうした違いや具体的な用途が考慮されなくなってしまいます。

コア、スレッド、仮想CPU

プロセスとは、簡単に言えば、実行中のプログラムインスタンスのことです。その中では、1つまたは複数のスレッドが命令を実行しています。 物理的なCPUコアは、そのような処理を実行するためのハードウェアを備えており、オペレーティングシステムはプロセッサに応じて、コアごとに1つまたは複数の論理CPUスレッドを認識します。同じコアに属する論理スレッドは、そのハードウェアの一部を共有します。

シリアル処理の割合が高いタスクの場合、その部分を任意の数のコアに分散させることはできません。その場合、実行中のスレッドが具体的な処理をどれだけ速く完了できるかが重要になります。一方、独立したWebリクエストは、多くの場合並列処理が可能です。その場合、他のリソースによる制約がない限り、利用可能な追加のコアが全体的なスループットの向上に寄与します。

論理スレッドの数は、独立した物理コアの数と同一視することはできません。 例えば、EPYC 9655は、メーカーによると96個の物理コアと192個のスレッドを備えています。しかし、192個のスレッドがあるからといって、96個のスレッドに比べてパフォーマンスが2倍になるわけでも、Webサーバーにおける特定のスループットが保証されるわけでもありません。

仮想サーバーの場合、プロバイダーはゲストOSに vCPU 注意：vCPUは必ずしも排他的に使用できる物理コアとは限りません。ホストハードウェアへの割り当てはサービスプランによって異なり、処理時間は他のゲストと共有されたり、制限によって制限されたりする場合があります。

具体的なリソースの割り当てを決定する前に確認すべき点：CPU時間は保証されているのか、それとも共有されるのか？ 恒久的なパフォーマンス制限はありますか？また、vCPUはどのように割り当てられますか？vCPUの数が多いことは、実際に十分な計算時間が確保されている場合に限り、並列アプリケーションのパフォーマンス向上に役立ちます。一方、シリアル処理のセクションにおいては、1つのスレッドでの高速実行に代わるものではありません。

IPCとクロックを合わせて計算する

IPCとクロック周波数は、CPUの性能における異なる側面を表しています。適切に定義された測定範囲においては、その影響を近似的に結びつけることができます： 1秒あたりの命令数 これは、IPCに1秒あたりの実CPUサイクル数を乗じた値に相当する。ここで、IPCとは、完了した命令数と、同じ期間内に計測されたサイクル数を指す。

説明用の計算例（実測値ではありません）：1サイクルあたり2.0命令、3.0 GHzと仮定すると、計算上は1秒あたり60億命令となります。 また、4.0 GHzでIPCが1.5の場合でも、60億となります。この例では、クロック周波数が高いことが、IPCの低さを計算上相殺していることになります。

しかし、命令実行数が同じであっても、両システムが同数のWebリクエストを処理するとは限りません。同じタスクであっても、コンパイラ、命令セット、および使用される命令によって、プログラムが必要とする命令数は異なります。したがって、1つの命令は、アプリケーションが実行した作業量の統一的な尺度とはなりません。

また、Webサイトの応答時間も、この数値からは直接読み取ることができません。スレッドは、ストレージからのデータやネットワークからの応答を待機している場合があり、その間、そのスレッドの命令実行レートだけでは経過した時間全体を説明することはできません。仮想マシンの場合、さらに、常にCPU時間を割り当てられるとは限らないという点が加わります。

したがって、比較を行うには、どのコードとどの期間を対象としているかが明確でなければなりません。この計算式は、アクティブな実行状況を把握するのに役立ちます。ホスティングの決定を行うには、さらに、同等のリクエストプロファイルにおける完了したタスクとその応答時間も必要となります。

データシートと主要指標の整理

データシートは、ホスティング用CPUの選定に役立つ指針を提供します。しかし、記載されている情報はそれぞれ異なる点を示しています。IPCは特定の測定範囲における動作特性を表すのに対し、周波数やコア数はプロセッサモデルの仕様を規定するものです。これらがアプリケーションと組み合わさって初めて、実用的な比較基準となります。

EPYC 9655は、こうした仕様がどのように関連しているかを示しています。AMDによると、このモデルは96コアと192スレッドを備え、ベースクロックは2.6 GHz、最大ブーストクロックは4.5 GHzに達します。 なお、この4.5 GHzは、持続的な負荷下における全コアに対する保証クロックではなく、測定されたホスティングスループットでもありません。

最大GHz数に基づくランキングでは、各プロセッサが1サイクルあたり、また1タスクあたりにどれだけの処理を行っているかが隠れてしまいます。一方、コア数に基づくランキングでは、すべてのアプリケーションが処理を同じように効率的に並列化できるわけではないという点が考慮されていません。どちらの指標も出発点に過ぎず、決定的な性能評価ではありません。

そのため、オファーを見る際は、以下の点に注意してください。 モデルバリエーション そして、実際に利用可能なリソースがどれほどあるかという点です。信頼性の高い比較を行うためには、適切な負荷プロファイルに加え、同等のソフトウェアと構成での測定結果も必要です。異なるモデルの仕様を、製品ファミリー全体に適用される最大値と混同してはなりません。

負荷プロファイルに基づいてホスティング用CPUを選択する

ホスティングに適したCPUは、サーバーにどのような処理をさせるかによって異なります。1つのタスクを長時間実行する場合と、多数の独立したWebリクエストを処理する場合では、求められる要件が異なります。この表では、代表的な負荷プロファイルを主要な評価指標に換算し、CPU選定前に明確にしておくべきポイントをまとめています。

単一のタスクにおいて、作業の大部分がシリアルに実行される場合、そのタスクを実行するスレッドのパフォーマンスが特に重要になります。コア数が増えても、この部分の処理時間が自動的に短縮されるわけではありません。また、長時間実行されるタスクの場合、一時的なパフォーマンスの向上が見られたとしても、それだけでは十分な証拠とはなりません。重要なのは、所定の条件下で測定された実行時間です。

一方、多数の独立したリクエストは並行して処理することができます。ここでは、スレッドあたりの処理性能に加え、同時に利用可能なリソースの量や、負荷の増加に伴う応答時間の推移が重要となります。名目上のGHz値の合計だけでは、以下の比較に代わるものではありません。 総処理量 並列度が同じ場合。

大規模な作業データセットを含むデータベースでは、必要なデータがキャッシュから効率的に提供されない場合、メモリアクセスが実行速度を低下させる可能性があります。 IPCが低いことは、さらなる調査のきっかけとなる可能性がありますが、それだけではメモリのボトルネックであることを証明するものではありません。したがって、CPUを交換する前に、クエリ、データセット、およびメモリ構成も確認してください。

VPSの場合、さらに リソースの確約 重要な点：vCPUは必ずしも専用の物理コアとは限りません。割り当て状況、CPUの制限の可能性、および他のゲストとの共有について確認する必要があります。これらの情報を把握して初めて、アプリケーションのテスト結果を専用サーバーのプランと適切に比較することが可能になります。

同様のアプリケーションテストを計画する

有意義な比較は、単体のCPU数値ではなく、実際のアプリケーションから始まります。両方のホスティングプランで、同じソフトウェアバージョン、同じデータセット、同じ設定を指定してください。SPECは、自社のインフラ上で動作する自社アプリケーションこそが、製品選定における理想的な基準であると述べています。

次に、 お問い合わせプロファイル、実際の利用状況を可能な限り正確に反映したものにしてください。例えば、どのページやAPIエンドポイントが呼び出されるか、同時にどれだけのリクエストが到着するかなどです。各実行間の並行処理状況やリソース制限を比較可能な状態に保ってください。サービス側が異なる制限を定めている場合は、その違いを単にCPUのせいにするのではなく、明確に文書化してください。

アプリケーションが起動し、キャッシュが蓄積されるよう、ウォームアップ期間を設けてください。その後、十分な長さの実行を数回繰り返すことで、短期的な変動と繰り返し発生する差異を区別しやすくなります。また、測定中にシステム上で他のタスクが実行されていたかどうかも記録しておいてください。

処理能力に加えて、以下の項目も記録してください。 応答時間の分布 そして、不具合についてもです。1秒あたりの処理完了リクエスト数の平均値が高くても、個々のリクエストの待ち時間が非常に長かったり、失敗が頻繁に発生したりするようでは、あまり意味がありません。そのため、並列処理数が同じ条件下での応答時間の高いパーセンタイル値も比較するようにしてください。

公開されているSPEC CPU 2017の結果も、参考となるでしょう。SPECspeedはタスクの実行時間を測定し、SPECrateはスループットを測定します。これら2つの指標は、そのまま互いに置き換えられるものではありません。同じ指標の結果を比較し、システム構成やソフトウェアにも注意を払ってください。 このCPUスイートは、完全なホスティングサービスのネットワークおよびI/Oを反映したものではありません。

稼働中のIPCおよび周波数を点検する

独自のLinuxテスト環境を構築するには、既存の検証済みプログラムの完了した命令やサイクルをperfで記録することができます。以下の例では、 testprogramm プレースホルダー：これをテストプログラム、および必要に応じてその引数に置き換えてください。このコマンドは測定の提案であり、すでに実行されたテストではありません。

perf stat -e '{instructions,cycles}' -- testprogramm

波括弧は、一連の出来事をまとめて メーターグループ をまとめて。これらは同時に計測されるべきであり、これにより、時間差多重化によるエラーを減らすことができます。計測された命令数を計測されたサイクル数で割ることで、この測定範囲におけるIPCを算出できます。perfコマンドはこの値を直接出力することも可能です。

イベントが利用可能であり、読み取りが可能かどうかは、ハードウェア、カーネル、権限、および場合によっては仮想化環境によって異なります。利用できない、あるいは集計できないイベントグループでは、信頼性の高い比較を行うことはできません。この例のためだけにセキュリティ設定を変更しないでください。

周波数表示にも文脈が必要です： scaling_cur_freq カーネルのドキュメントによると、多くの場合、これはドライバが最後に要求した状態に相当し、必ずしも実際に達成されたハードウェアクロックとは一致しない。この値は、すべての環境で利用可能とは限らない。 cpuinfo_cur_freq これに対し、ハードウェア側で検出された現在の周波数を表示する。詳細については ホスティングサーバーにおけるCPUガバナー 周波数スケーリングの制御について解説します。

IPCが低いことは、さらなる調査の指針にはなりますが、確定診断ではありません。メモリアクセスは実行速度を低下させる可能性があります。また、どのプログラム部分が測定対象となったか、その他の要因がないかについても確認する必要があります。したがって、カウンタの値をアプリケーションの動作やデータアクセス状況と照らし合わせて確認してください。

ボトルネックを特定し、アップグレードを決定する

具体的な症状から検討を始めましょう。負荷がかかるとリクエストの処理が遅くなったり、エラー率が高くなったり、あるいは単一のタスクに時間がかかりすぎたりしていませんか？問題がいつ発生するか、その際にどのような処理が同時に実行されているかを記録しておきましょう。そうして初めて、CPU性能を向上させることで、その遅延を実際に短縮できるかどうかを検証できるのです。

まず、利用可能容量と使用済み容量を確認してください CPU時間. 継続的に計算負荷の高いタスクは、実行速度の向上や並列処理の有効活用によって恩恵を受ける可能性があります。しかし、高い負荷率だけでは、どのコードがそれを引き起こしているのか、また応答時間が主にそこで発生しているのかは説明できません。したがって、この調査結果を、同じ負荷フェーズにおけるスループットや応答時間と併せて検討してください。

続いて、メモリ使用量とデータアクセスを調査する。データベースがCPUキャッシュ外のデータに頻繁にアクセスする必要がある場合、メモリ待ちが発生する可能性がある。IPCが低いことはその兆候となり得るが、原因を証明するものではない。 また、メモリ不足、ストレージへのアクセス、あるいは外部サービスの処理速度の遅さも、観測された遅延の原因となっている可能性があります。

VPSの場合、 リソースの確約 診断について：vCPUの割り当て、CPUリミットの設定可能性、および他のゲストとの共有について確認してください。専用サーバーでは物理リソースの割り当てが異なりますが、そこでも結果を決めるのはアプリケーション、構成、および負荷プロファイルです。可能であれば、同じアプリケーションテストを用いて両方のプランを比較してください。

測定結果からCPUがボトルネックとなっていることが判明し、かつ新しい料金プランで実際に必要な計算時間が確保できる場合は、CPUのアップグレードを検討してください。遅延の原因が主にメモリ、ストレージ、または外部サービスにある場合は、そちらについてさらに調査を行う方が理にかなっています。 変更後の状況を比較評価できるよう、変更前の状態を記録しておいてください。

最大ブースト値は、すべてのコアにおける保証された持続クロックとして解釈すべきではなく、IPC値もCPUの普遍的な特性として捉えるべきではありません。同様に、単一の負荷率の数値だけでは、ボトルネックの完全な診断には不十分です。 判断は、個別のピーク指標ではなく、具体的なタスクと実際に利用可能なリソースに基づいて行われるべきです。