...
ウェブホスティングのロゴ

ホスティングにおいてCPUキャッシュ（L1-L3）がRAMより重要な理由

なぜなら、L1-L3は遅いRAMアクセスをバイパスして、ナノ秒単位でコアに直接データを提供するからだ。キャッシュのサイズと階層が計算時間を支配するときと、強力なキャッシュなしでRAMを増やしてもほとんど効果がない理由を明確に示します。.

中心点

  • L1-L3 ホットデータをコアの近くでバッファリングし、レイテンシーを大幅に削減する。.
  • キャッシュ階層 ダイナミックなリクエストと高い並列性でRAMを凌駕する。.
  • コアあたりのキャッシュ VPS/DEDIでは、純粋なRAMの量よりもカウントされます。.
  • ワークロード WordPress、DBクエリ、PHPなどが直接恩恵を受ける。.
  • 料金表の選択 CPUフォーカスを使用することで、レスポンスが格段に速くなる。.

CPUキャッシュがL1-L3ホスティングを著しく高速化する理由

A キャッシュ はプロセッサー上に直接配置され、メインボードを経由することなく命令とデータを送出する。L1は小さいが非常に高速であり、L2はバッファを拡張し、L3は全コアのために多くのコール素材を保持する。こうすることで、プロセッサは以下のアクセス時に発生する待ち時間を回避できる。 RAM が発生する。ウェブサーバーでは、各リクエストが複数のデータベースやファイルシステムへのアクセスを引き起こすため、これらの待ち時間が加算されます。短いキャッシュ・ヒットが長いRAMアクセスに取って代わり、TTFBとCPUの使用率を下げていることをログで見続けています。.

L1、L2、L3の連携について

L1キャッシュは、わずか数クロックサイクルで命令とデータを送出する。 レイテンシー を最小値にする。L1がミスった場合、L2が少し多めの所要時間で要求を満たす。L2がミスした場合、L3が入るが、これは比較的大きく、ヒット率は高く保たれる。L3がミスした場合のみ、CPUはRAMで終わり、サイクルが遅くなる。したがって、私は、各コアが十分な時間を持つようにホスティングを計画している。 L3 なぜなら、多くの並列ウェブ・プロセスが共有データ・レコードにアクセスする場所だからだ。.

キャッシュとRAMの比較：一目でわかる数字

典型的なサイズと相対的なスピードについてまとめてみた。 分類 の方が簡単である。CPUの世代によって値は異なるが、比率は似ている。L1は非常に小さく非常に高速、L2はその中間、L3は大きく、コア間で共有されることが多い。RAMは容量をもたらすが アクセス時間 であり、ランダムアクセスでは弱くなる。ウェブ・サーバー、PHP、データベースで構成されるウェブ・サーバー・スタックでは、まさにこうしたランダム・アクセスが支配的である。.

保管レベル 標準サイズ レイテンシー（相対） ファクターとRAMの比較 共有？
L1（命令／データ） コアあたり32～64KB 極めて低い 最大170倍高速化 いいえ
L2 コアあたり256KB～1MB 非常に低い 格段に速い いいえ
L3 40MB以上、共有 ロー 最大15倍高速 よくある
RAM (DDR) GBエリア 高い ベースライン システム全体

キャッシュ・アーキテクチャの詳細：インクルーシブ、エクスクルーシブ、チップレット

すべてのL3が同じというわけではない。 包括的 L3（L1/L2ラインのコピーを保持）、その他は 排他的／ほとんど排他的 (L3はL1/L2にない追加行を含む）。インクルーシブはコヒーレンスのシンプルさを高めるが、有効スペースが犠牲になる。エクスクルーシブは容量を有効活用できますが、スマートな犠牲者管理が必要です。チップレットベースの設計では、L3はしばしば につき 異なるダイに着地するリクエストは、余分なレイテンシーを支払うことになる。ホスティングの場合、これは次のことを意味する、, ダイごとのワークロードとそのホットセット これにより、アクセスの大半がローカルL3に留まる。これにより分散が減り、95/99パーセンタイルが安定する。.

実際のワークロードWordPress、データベース、API

動的なページは、多くの小さなことから始まる。 アクセスPHPはテンプレートをフェッチし、MySQLは行を配信し、ウェブサーバーはファイルを読み込む。これらのパターンがキャッシュの中で出会うと、TTFBは直接低下する。WordPressは、特にCPUに負荷のかかるテーマや多くのプラグインで、これをはっきりと示している。さらに深く掘り下げると、次のような典型的なボトルネックが見つかるだろう。 CPUに依存する WordPress を記述した。私が計画しているコアは L3 コアあたり、クエリのホットセットとバイトコードのフラグメントがより頻繁にバッファに残るからだ。.

実用的な値：中規模のWordPressサイトのホットセットは、一桁メガバイトの範囲にあることが多い（opcacheバイトコード、オートローダーマップ、頻繁なDBインデックス）。Eコマースショップでは、セッションデータだけでなく、価格や株価指数も使用されます。このバンドルがL3に収まれば、アプリケーションやRAMサイズを変更しなくても、レスポンスタイムのアップダウンは大幅に減少する。.

コア、スレッド、コアあたりのキャッシュ

コア数が多いのは、各コアが十分な性能を持っている場合に限られる。 キャッシュ そうでなければ、スレッドはより強く競合する。ハイパースレッディングは計算能力を2倍にするのではなく、キャッシュ構造を共有する。コアあたりのL3が増えることで、利用率は安定し、応答時間のばらつきも小さくなります。マルチテナントVPSでは、複数のサイトのホットセットが共有L3に保持されるため、特にメリットがあります。そのため、私はコアとキャッシュの比率に注目しています。 L3容量, 純粋なコアカウンターだけでなく。.

よくある誤解：“スレッド数が多い＝スループットが高い”。実際にはコンフリクトミスやコンテキストスイッチが増える。私はワーカーをきっちり制限して 国際刑事裁判所 (サイクルあたりの命令数）は高いままであり、ミス率が暴走することはない。このため、負荷テストでは「最大並列度」アプローチよりも優れたパーセンタイルが得られることが多い。.

NUMA、メモリアクセス、レイテンシトラップ

最近のサーバーは、しばしば複数の NUMA-ノード間でプロセスを分散させると、レイテンシが増加し、キャッシュヒットが減少する。ノード間でプロセスを分散させると、レイテンシが増加し、キャッシュヒットが減少する。私は、ホットセットがローカルに留まるようにサービスをバインドすることを好む。簡単な概要 NUMAアーキテクチャ は、コア、キャッシュ、RAMバンク間の近接性がいかに重要かを示している。うまく配置すれば、リクエストはより多くの キャッシュ・ヒット また、遠くの店へ行くのにかかる費用も少なくて済む。.

重要だ： クロスNUMAトラフィック はRAMだけの問題ではない。ノード間のL3コヒーレンスもレイテンシを増加させます。そのため私は、アクティブなデータベースとPHP FPMプールがどのNUMAノードにあるかを負荷下でテストし、可能であればWebプロセスとDBプロセスを同じトポロジーに保つようにしています。これにより、セッション、クエリプラン、バイトコードが常に「通りを越えて」プッシュされるのを防ぐことができます。.

CPUを待つI/O：RAMがボトルネックになることが少ない理由

RAMの容量はファイルシステムのキャッシュに役立つが、ほとんどの場合、RAMの容量はファイルシステムのキャッシュに役立つが、ほとんどの場合、RAMの容量はファイルシステムのキャッシュに役立つ。 待ち時間 はアプリケーションのコードパスに作成される。これらのパスは、高速な命令キャッシュやデータキャッシュから恩恵を受けるのであって、ギガバイトを増やすことから恩恵を受けるわけではない。ランダムアクセスでは、RAM帯域幅はすぐに消えてしまうが、大きなL3がジャンプを緩和する。私はプロファイラで、キャッシュ・ミス・レートがTTFBや95パーセンタイルと密接に相関していることを測定している。これが、CPUキャッシュを純粋なキャッシュよりも重視する理由だ。 RAMサイズ, ミス率が下がるまで。.

また、CPUの待ち時間が少なければ、SSDはより速く「動作」する。コンテキスト・スイッチの回数が減り、コード・パスが短くなるため、I/O完了の処理が速くなる。キャッシュはこの触媒であり、ホットな命令パスを温かく保ち、ストールを最小限に抑える。.

キャッシュ・ミス・タイプの理解と削減

実際には、私は4つの原因を区別している：

  • コンパルソリー・ミス (コールド）：新しいデータへの最初のアクセス。ウォームアップ戦略（最も頻度の高い経路のプリロード、オペキャッシュのウォームアップ）によって減らすことができる。.
  • キャパシティ・ミスHotsetはLxに完全に収まるわけではない。私は、より小さなコードパス、より少ないプラグイン、最適化されたインデックスを使うことでサイズを小さくしている。.
  • コンフリクト・ミス同じ集合にマッピングされる行が多すぎる。データのローカリティを高め、散乱を減らすことが、「より滑らかな」データ構造と同様に役立つ。.
  • コヒーレンス・ミス共有データは頻繁に書き込まれる。私は、書き込みトラフィックを軽減するために、グローバルなミュータブルを最小限に抑え、ローカルキャッシュ（APCu）を使っている。.

アプリケーションレベルでは、ランダムアクセスを減らし（例：PHPではスキャッターギャザーを減らす）、クエリーを要約し、オブジェクトキャッシュの一貫性を保ち、ホットコードが常にリコンパイルやリロードされないようにする。.

ホスティング料金の実際的な購入基準

VPSと専用サーバーの場合は、まず CPU-世代、そしてコアあたりのキャッシュサイズです。RAMが少なくてもコアあたりのL3が強力なモデルは、RAMが多くてもキャッシュが弱いモデルに勝ることが多い。また、負荷時のクロックレート、ターボの動作、プロバイダーによるコアの割り当て方法も重要だ。同時リクエストの多いショップでは、L3容量が不釣り合いに利益をもたらす。また、アプリ、DB、CDNですでにキャッシュを使用している場合にも、L3容量が役立ちます。 キャッシュ・ストロング CPUは、ホットセットがより頻繁にヒットするからだ。.

私は明確に尋ねているのだ：何人 物理コアあたりのvCPU プロバイダは共有していますか？vCPUはNUMA境界を越えて混在していますか？vCPUが同じダイ内にあることが保証されているか？これらのような詳細によって、L3がアクセラレータとして機能するか、あるいはノイズの多い隣人によって打ち消されるかが決まる。 水割り の意思表示をします。

チューニング：ソフトウェアがキャッシュを有効活用

PHPのopcache、JIT設定、DBバッファは、ホットパスが L3 再コンパイルはまれである。スレッドのピン留めが難しすぎると、スケジューラの最適化が阻害される。 CPUピン止め. .その代わり、ワーカーがキャッシュを置き換えないように制限している。コードパスが短く、分岐が少なく、バイトコード・キャッシュが暖かい。これによってミス率が減り、プロセッサはより多くの時間を 役に立つ仕事 待つのではなく.

PHPスタックでの配信 OPcacheメモリー そして 内部文字列 顕著に向上したローカリティ。さらに、私は地元の APCu 読み込みの多いデータには 永続オブジェクトキャッシュ (ホットキーがL3に残るように、管理可能な数のキーで（Redisなど）。データベースでは、セカンダリー・インデックスを必要なものだけに減らし、ジャンプ・パターンではなくシーケンスが作成されるようにソート順を最適化する。.

測定変数：私がモニターしているもの

私は常に観察している。 ミス・レート (L1/L2/L3）、IPC（Instructions per Cycle）、そして負荷時のクロックです。また、負荷変化時のTTFB、95/99パーセンタイル、エラーログもチェックする。これらの重要な数値は、コードパスがキャッシュに収まるのか、それとも抜け落ちるのかを示している。私はミスのピークをデプロイ、トラフィックのピーク、新しいプラグインと相関させている。これによって、より多くのコードパスがキャッシュされる場所を素早く見つけることができる。 キャッシュ・ヒット 最大の利益をもたらす。.

アドホックな分析については、“"でのライブ中継を見る。“パースタット”「サイクル、命令、分岐、分岐ミス、LLCミスなどのメトリクスを使用する。私は常時、記録、負荷時の頻度(ターボスタット)と1秒あたりのコンテキスト・スイッチ数である。IPCが低下し、同時にLLCミスが増加する場合、ボトルネックはほとんどの場合、キャッシュ容量またはデータの局所性であり、RAMのスループットではない。.

ベンチマークとテストの設定：現実的な反応を測定する

でテストしている。 代表ルート 静的ファイルだけでなくスタートページ、商品詳細ページ、検索ページ、チェックアウトページが混在し、さまざまなコードパスをカバーしています。負荷レベル（コールド、ウォーム、ホット）を段階的に設定することで、キャッシュがどの程度でいっぱいになり、どこでオーバーするかを認識することができる。重要なのは 定常段階, 周波数、IPC、ミスレートが安定している。ここで初めて、関税とCPUの世代を公平に比較することになる。.

測定可能な信号：

  • TTFBの中央値はウォームアップ後に著しく低下し、低いままである。.
  • 95パーセンタイル/99パーセンタイルは、ピーク負荷でわずかにドリフトするだけである。.
  • IPCは作業者が少ないほど向上する→コンフリクトとミスが減少する。.
  • LLCのミスは、新しいプラグイン/機能と相関している → ホットセットの拡大。.

各テストについて、アクティブCPUの周波数、ワーカー数、ルートミックス、NUMA配置（該当する場合）を記録しています。これにより、最適化を明確に割り当て、再現することができます。.

仮想化とマルチテナント：キャッシュを失うことなく共有する

VPS環境では、クライアントは同じ物理L3を共有する。ゲストのvCPUがマシン全体に広く分散している場合、, 負け マンローカリティ。優れたプロバイダーは、ゲストのvCPUを同じCCX/CCD/Tileにバンドルします。その方がパーセンタイルが安定し、ばらつきが小さくなります。加えて、私は自分のスタックがL3に殺到して隣のスタックと競合しないようにワーカーを制限している。.

同じホスト上のコンテナも同様に競合する。予熱されたオペキャッシュを持つ無駄のないベースコンテナで、動的なオートローディングをできるだけ少なくすることで、L3をクリーンに保つ。同じノード上で、高い命令領域を生成するようなアグレッシブなサイドカーは避ける（例えば、“あらゆる場所であらゆるログを取る”）。これは別のノードか、ホットパスCPUの外側に属する。.

プリフェッチャ、TLB、ページサイズ：隠れたレバー

最近のCPUは プリフェッチャー, 直線的なパターンを好む人。コードやデータがより順次に配置されていればいるほど助けになる。したがって私は、ハッシュを多用したり高度に分岐したレイアウトよりも、構造化された配列やよりコンパクトな構造を好む。また、私は アドレスへんかんバッファ (翻訳ルックサイドバッファ）：多くのページウォークは高価であり、L1/L2を持っていく。大きなページサイズ（巨大ページ）は、より少ないTLBエントリでバイトコードとDBホットセットをカバーするのに役立ちます。InnoDBとJITのコンフィギュレーションでは、大きなページが測定可能な利点をもたらすかどうかをチェックする。.

実用的なチェックリスト：10のステップで高速キャッシュホスティング

  • CPUの生成と コアあたりL3 コア数やRAMだけではない。.
  • vCPUの割り当てを要求する： バンドル 分散ではなく、1ダイ/NUMAあたり。.
  • 労働者をIPCスイートスポットに限定し、パーセンタイルのばらつきを最小化する。.
  • PHP-Opcacheを寛大に、しかし意図的に拡張し、再コンパイルを避ける。.
  • 永続的なオブジェクト・キャッシュを使用し、キー・スペースをスリムに保つ。.
  • DBインデックスをホットクエリに合わせ、ランダムアクセスを減らす。.
  • NUMAローカリティの確保：Web、PHP、DBを可能な限り同じノードに。.
  • プリフェッチャーに優しいデータパス：よりシーケンシャルに、より少ないジャンプ。.
  • トラフィックがピークに達する前にコールドミスを阻止する。.
  • モニタリング：IPC、L1/L2/L3ミス率、サイクル、95/99パーセンタイル連続相関。.

簡単にまとめると

ホスティングでは、強力な CPUキャッシュ L1-L3は全てのダイナミックリクエストを優先し、追加のRAMは主に容量を提供する。そのため、コアあたりのキャッシュサイズ、クリーンなプロセス配置、適切なワーカー数を優先しています。ツールでは、ミス数が少ないほど、レスポンスタイムが明らかに向上し、パーセンタイルも安定します。タリフを選択する際には、GBのスペックだけでなく、キャッシュのスペックやCPUの世代にも注意を払うべきです。これが、同じソフトウェアからより多くのものを引き出す方法です。 パフォーマンス 高価なハードウェアをアップグレードすることなく。.

現在の記事