サーバーと仮想マシン

共有ホスティングにおけるCPUスロットリング – 隠れたパフォーマンス制限を見抜く方法

CPU 共有ホスティングにおけるスロットリングは、ウェブサイトが過大な計算時間を消費する場合に意図的にその速度を低下させます。まさにこの動作が、突然の読み込み時間の問題の多くの原因となっています。その兆候と制限を理解している方は、 CPUスロットリングホスティング 隠れたボトルネックを早期に認識し、推測に頼ることなくパフォーマンスの低下を防止します。.

中心点

スロットリングをより早く特定し、自信を持って解決できるよう、重要な知見をまとめます。.

識別記号 TTFBの高さ、503エラー、管理ログインの遅さなど
原因プラグイン、データベース、近隣ウェブサイト、オーバーセリングによるもの
限界正しく読む：CPU%、RAM、I/O、プロセス
対策キャッシュから料金プランの変更まで
モニタリング アラートおよびトレンド分析用

共有ホスティングにおけるCPUスロットリングとは？

時点では スロットル ホスティング事業者が、ウェブサイトが許可された割合を超えた時点でCPU時間に厳しい制限を設けることを理解しています。プラットフォームは、アプリケーションがより多くのパワーを必要としているにもかかわらず、利用可能な演算能力を積極的に削減します。これにより、個々のプロジェクトが一時的に負荷が高くなった場合でも、すべてのアカウントに対してサーバーの応答性を維持することができます。これは、負荷のピーク時に自動的に作動するブレーキペダルのようなものです。まさにこの動作が、コードの変更なしに発生し、また消える、不安定なロード時間を説明しています。.

ホスティングプロバイダが帯域制限を行う理由

共有サーバーは分割します リソース 多くのウェブサイトに分散して、価格を抑えてるんだ。あるプロジェクトが予定されたCPU時間を超えたら、他のプロジェクトにも影響して連鎖反応を起こすんだ。そのため、スロットリングは個々のアカウントを遮断するのではなく、サービス全体を保護します。つまり、サイトはオンラインのままですが、負荷が低下するまで応答時間が長くなるということです。したがって、私は、公平な分配には、私の最大パフォーマンスを制限する固定のガイドラインがあるものと常に考えています。.

スロットリングとハードリミット：バーストの挙動を正しく分類する

私は次のように区別している。 永続的な制限 そして バーストウィンドウ. 多くのプラットフォームは、スロットリングを行う前に、一時的に CPU の使用量を増やすことを許可しています。これにより、個々のページアクセスは高速である一方、一連のリクエストは突然速度が低下する理由が説明できます。ダッシュボードでは、CPU% が公称制限をわずかに上回った後、遅くとも数秒後にはスロットリングされたラインに低下することで、この現象を確認できます。実際には、持続的なパフォーマンスの向上を期待するよりも、ピークを平準化することが重要です。.

また、以下の要素との相互作用も重要です。 プロセスおよびエントリープロセスの制限. 同時PHP起動の数が制限されている場合、CPUが必ずしもフル稼働しているとは限りません。リクエストは単に空きワーカーを待機しているだけなのです。そのため、私は常に 同時に CPU%、アクティブなプロセス、および潜在的な誤カウント：これにより、CPUがブレーキをかけているのか、それともキューが実際の原因であるのかを判断できます。.

日常的にCPUスロットリングを認識する方法

私は、明らかに増加した TTFB （Time to First Byte）、特に 600 ミリ秒以上になった場合。トラフィックのピーク時に HTTP-503 または 500 が発生した場合、多くの場合、計算時間が制限されていることを示しています。コンテンツに変更がないにもかかわらず、WordPress バックエンドの反応が遅いと感じられる場合は、明らかな兆候であると言えます。繰り返しアクセスできない場合も、このパターンに当てはまります。同じサーバー上の他のアカウントと相関する、変動する応答時間をよく目にします。.

ホスティングの制限を正しく読み解く

コントロールパネルで監視しています CPU%, 、RAM、I/O、プロセス、エラーカウンタを監視してパターンを確認します。100% CPU の値は多くの場合 1 コアに相当し、複数のピークは繰り返しのスロットリングを示しています。 RAM が不足している場合、システムはより多くスワップを行い、CPU 時間をさらに消費します。I/O レートが制限されていると、CPU は空きがあるように見えても、PHP やデータベースの速度が低下する可能性があります。これらのメトリックを組み合わせて初めて、ボトルネックが実際に発生しているかどうか、あるいは別のボトルネックが支配的であるかどうかがわかります。.

私が注目している典型的なパネル指標

CPU% 対タイムスロット: 100% が数分間持続すると、飽和状態が深刻であることを意味します。短いスパイクは、バースト消費を示しています。.
エントリープロセス / 同時接続: 通常の CPU% で高い値が示される場合は、アプリケーションレベルのキューが存在します。.
NPROC（プロセス数）: 制限に達すると、スタックは新しい PHP ワーカーをブロックし、多くの場合 503/508 エラーが発生します。.
I/O レートおよび IOPS：低い限界値は「隠れた」CPU待機時間を発生させ、CPUが中程度にもかかわらずTTFBが長くなることで確認できます。.
フォルトカウンタ：リソースの競合（CPU、RAM、EP）は、必ず痕跡を残します。私は、フォールトとログ、トラフィックを相互に関連付けています。.

実践から見た典型的な原因

多くのアクティブな プラグイン 追加のデータベースクエリとPHPワークロードを発生させ、CPU時間を消費します。不適切なクエリ、cronジョブ、または全文検索機能は、呼び出しのたびにデータセット全体をフィルタリングします。動的なフィルターとパーソナライズされた価格設定を備えた E コマースカタログは、特に多くの PHP 作業を生み出します。また、攻撃、クローラーのピーク、バイラルコンテンツなど、近隣プロジェクトもサーバーに負荷をかける可能性があります。オーバーセリングは、同じ CPU 時間を競うアカウントが妥当な数よりも多くなるため、この影響を増幅させます。.

私が確認するWordPressおよびCMSの仕様

WP-クーロン: 疑似クリックベースのcronを、固定間隔の実際のcronジョブに置き換えます。これにより、ジョブは訪問者ごとに実行されるのではなく、まとめて実行されます。.
ハートビートとAJAX: バックエンドでハートビートの頻度を減らし、重い admin-ajax エンドポイントを制限します。.
自動ロードオプション: オプションテーブルが大きすぎると、すべてのリクエストの速度が低下します。オートロードデータはスリムに保つようにしています。.
ウーコマース：価格計算、セッション、動的ウィジェットは、きめ細かくキャッシュするか、エッジキャッシュやフラグメントキャッシュを使って移動します。.
検索機能：高価な LIKE クエリの代わりに、CPU 負荷を軽減するために、CMS のインデックスと事前処理済みインデックスを利用しています。.

明確さを与えてくれる迅速検査

を測定する。 TTFB 異なる時間に測定し、その値を簡単なログに記録します。夜間に応答が速くなり、午後になると低下する場合、これは分割された制限に合致します。エラーログを簡単に確認すると、CPU% またはプロセスのピークと同時期に 503 のピークが見られます。テストとして、重いウィジェットをホームページから削除すると、時間がすぐに短縮される場合は、ネットワークが原因であることはほとんどありません。ページキャッシュを有効にした場合にのみこれが成功する場合は、CPU が単に過負荷だったことになります。.

追加の短期間テスト、リスクなし

コンスタンテスト：同じページを20～30回続けて呼び出し、TTFBが上昇するタイミングを観察します。これはバーストの終了を示す良い兆候です。.
静的アセット: /robots.txt または小さな画像をテストします。TTFB が正常であれば、ボトルネックはネットワークではなく PHP/DB にあると考えられます。.
キャッシュヒット率: キャッシュがウォームな状態とコールドスタートの状態でのTTFBを比較します。大きな差がある場合は、CPUのボトルネックが明らかです。.

ブレーキに対する効果的なクイックウィン

まず、1つを有効にします。 キャッシュ ページおよびオブジェクトレベルで、PHP が訪問ごとに再計算を行わないようにします。その後、プラグインを整理し、機能の重複を削除し、重い拡張機能を置き換えます。画像を WebP で圧縮し、サイズを制限して、PHP および I/O の作業負荷を軽減します。データベースから、もはや重要ではないリビジョン、トランジェント、セッションを削除します。静的アセット用の軽量な CDN により、オリジンへの負荷がさらに軽減され、応答時間が短縮されます。.

より深い最適化：PHPワーカー、OPCache、バージョン

その数 PHP-ワーカー 同時PHPリクエストと、それによるスタック内のキューを管理します。ワーカーが多すぎるとCPUが限界に達し、少なすぎるとリソースが空きがあるにもかかわらず遅延が発生します。私は OPCache を一貫して有効にし、PHP のバージョンを確認しています。新しいビルドは、多くの場合、計算速度が大幅に高速化されているからです。リクエスト数の多い CMS については、ワーカーの数を段階的に調整し、TTFB を監視しています。このガイドは、実践的な入門書となっています。 PHPワーカーを正しく設定する, 、それを使ってボトルネックを巧みに解消しています。.

安定性を高める微調整

OPCache パラメータ十分なメモリとまれな再検証により、再コンパイルのコストを削減します。キャッシュが効果を発揮するように、コードベースの一貫性を維持しています。.
ワーカーのステップ：ワーカーは少しずつ増減させて、そのたびにキューの待ち時間を測ってるよ。.
セッションとロッキング: セッションの有効期間が長いと、並行処理されたリクエストがブロックされます。TTL を短く設定し、不要なロックを防止します。.

ルートアクセスなしでデータベースを最適化

共有環境でもデータベースを利用できます。 目立つ イコライゼーション。書き込み/読み取り操作の多いテーブルを特定し、WHERE 句や JOIN 句で使用される列のインデックスをチェックします。クエリを簡略化し、LIMIT を適切に使用し、インデックスによるソートを準備することで、テーブルの完全スキャンを体系的に削減しています。「ORDER BY RAND()」や非選択的な LIKE 検索などのコストのかかるパターンは避けています。繰り返し行われる評価については、事前計算を行い、結果をコンパクトな構造で保存しています。.

トラフィック衛生：ボットとクローラーの制御

負荷のかなりの部分はボットによるものです。リクエスト頻度の高いユーザーエージェントを特定し、検索エンジンを疎外することなく制限します。 SEO 価値を生み出さないフィルター、無限ループ、パラメータのクロール率を低減します。さらに、検索ルート、XML-RPC、特定の AJAX ルートなどの CPU を大量に消費するエンドポイントを、レート制限、キャプチャ、キャッシュによって保護します。これにより、正当なトラフィックは高速なまま維持され、不要な負荷によってスロットリングが発生することはありません。.

HTTP/2/3、TLS、および接続管理

HTTP/2 または HTTP/3 が利用可能な場合は、それらを使用して並列転送の効率を高めています。長寿命の接続とキープアライブにより、CPU を消費する TLS ハンドシェイクを節約します。圧縮（Brotli など）はテキストコンテンツに的を絞って使用し、静的アセットは最適に圧縮して準備します。これにより、機能を制限することなく、リクエストごとの CPU 作業量を削減しています。.

アップグレード戦略と間違った購入をしない料金プランの選択

引っ越す前に、比較してみます。限界, マーケティングスローガンではなく、割り当てられた CPU シェア、RAM、プロセス制限、I/O レート、およびホストあたりの実際の密度が重要です。計算負荷の高いワークロードには、「最大」という表現ではなく、コアが保証された環境の方が適しています。CPU アーキテクチャも重要な要素です。強力なシングルスレッドは、動的なページを大幅に増加させるからです。この概要は、優れた技術的な比較を提供しています。シングルスレッドとマルチコアの比較, 選択ミスを防ぐ。.

典型的なホスティングの制限の比較

次の表は、私が決定を下す際の判断基準となる指標の例であり、事前にボトルネックを回避するためのものです。値はプロバイダによって異なりますが、パフォーマンスと価格に関する確かな指針となります。.

プラン	CPUシェア	RAM	I/Oレート	プロセス	月額料金	適合性
共有基本	0.5～1 vCPU	512 MB～1 GB	5～10 MB/秒	20-40	3～7ユーロ	ブログ、ランディングページ
Shared Plus	1～2 vCPU	1～2 GB	10～30 MB/秒	40～80	8～15ユーロ	小さなショップ、ポータルサイト
ブイピーエス	2～4 専用 vCPU	4～8 GB	50～200 MB/秒	設定後	15～45ユーロ	成長プロジェクト
マネージドクラウド	4+ 専用 vCPU	8～32 GB	200+ MB/秒	プラットフォーム別	50-200 €	トラフィックが多い

モニタリング、警報、キャパシティプランニング

頼りにしているのは モニタリング, 障害が発生してから対応することにならないように、重要な指標を継続的に収集し、トラフィック、デプロイ、キャンペーンと照合しています。TTFB の高値、503 エラーの増加、CPU の長時間の飽和状態など、警告がタイムリーに通知されます。これにより、常に限界まで稼働する代わりに、バッファを含むキャパシティを計画することができます。開始には、コンパクトなガイドを使用しています。パフォーマンス・モニタリング, 私の測定戦略を構造化するものです。.

実績のある警報閾値

TTFB: 600～700 ミリ秒（キャッシュヒット）以上で警告、1 秒以上で重大。.
CPU%：80%以上が5分以上続くと警告、95%以上が2分以上続くと危険。.
故障/分：持続的なシリーズはどれも不便です。私は1時間に数十回程度のパターンを調査しています。.
503レート：ピークで 0.5～1% を超える場合は、飽和状態またはワーカー不足を示しています。.

ホスティング業者とのコミュニケーション：適切な質問

私は早く説明します。, 具体的にどの限度か 利用状況を確認し、負荷の少ないホストへの移行が可能かどうかを確認します。保証されたリソースと「最大」リソース、サーバーあたりの平均アカウント密度、バーストルールについて質問します。自分のログとの相関関係を検証するために、リソースログの閲覧を依頼します。透明性の高いプロバイダーは、このような協力関係を重視しており、それは私にとって誤った投資を防ぐことにつながります。.

スロットル診断のための15分チェックリスト

1. TTFBサンプル：3つの時間帯（午前、午後、夕方）を測定し、記録する。.
2. パネルを確認する：CPU%、エントリープロセス、I/O、同じ期間の障害を確認する。.
3. ログを確認する：503/500 エラーにタイムスタンプを付ける。.
4. キャッシュの切り替え：フルページキャッシュありと無しでページを一度ずつ呼び出し、比較する。.
5. 負荷のピークを制限する：重いウィジェット/モジュールを一時的に無効にして、TTFB を再度測定する。.
6. ボットの割合を確認する：目立つユーザーエージェントとパスを特定する。.

私が避ける神話や誤解

„「労働者が増えれば、スピードも上がる」“追加のワーカーはCPUに過負荷をかけ、スロットリングを引き起こす可能性があります。バランスが重要です。.
„「RAMはCPUの問題を解決する」“：RAMを増やすと、キャッシュやI/Oには効果がありますが、PHPの負荷によるCPUのボトルネックには効果はありません。.
„「CDN がすべてを解決する」“CDN は静的アセットの配信の負荷を軽減しますが、オリジンにおける動的なボトルネックは残ります。.

キャパシティプランニング：季節的な負荷とキャンペーン

私は、バッファ付きのリピートピーク（セール、テレビCM、ニュースレター）を計画しています。そのために、適度な負荷ピークをシミュレーションし、TTFB と 503 レートがどの同時実行数で変化するかを確認します。その後、エントリーページでキャッシュヒット率を高め、キャンペーン期間中はワーカーとリミットの余裕をたっぷり確保します。テスト結果が良くない場合は、アップグレードや短期的なスケーリングを行うタイミングです。.

迅速な意思決定のためのコンパクトな要約

突然の事態が発生した場合、私は確認します。遅さまず、コードをすぐに変更するのではなく、TTFB、ログ、リソース値を確認します。パターンが制限に合致する場合は、キャッシュ、プラグイン監査、データベースメンテナンスによってワークロードを削減します。その後も長いスロットルフェーズが継続する場合は、PHPワーカーとI/Oに敏感な部分を調整します。サイトのトラフィックが安定している場合は、料金プランの変更を延期し、値が再び低下した場合は、アップグレードを計画します。このようにして、予算を無駄にしたり、ユーザーエクスペリエンスを危険にさらしたりすることなく、CPU スロットリングホスティングを積極的に管理しています。.