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

WordPress での CPU 負荷の不均一 – Cron ジョブがパフォーマンスを損なう可能性

WordPress で CPU 負荷が不均一になる原因は、多くの場合、設定が不適切であることにあります。 ワードプレス cronjobs, ページがアクセスされるたびにバックグラウンドプロセスとして起動し、ピークを引き起こすものです。これらのトリガーが TTFB を延長し、PHP ワーカーを拘束し、レイテンシを発生させる仕組み、そしてシステムクロン、間隔、優先順位付けを使用してこれを回避する方法を説明します。 より均一に 最後に。.

中心点

以下の概要では、具体的な手順について詳しく説明する前に、最も重要な点をまとめています。焦点を絞るために、このリストは簡潔にまとめています。 アクション その効果があります。.

  • WP-クーロン ページアクセス時にトリガーされ、予測不可能な負荷を発生させます。.
  • PHPプロセス トラフィックで渋滞し、TTFBを遅くします。.
  • システムクーロン 訪問者の流れからタスクを切り離す。.
  • インターバル 優先順位を平準化することで、CPUのピークを平準化します。.
  • モニタリング ボトルネックや誤ったイベントを発見します。.

WordPress の cron ジョブが実際に実行すること、および負荷の発生源

WordPress は疑似 cron システムを採用しています。呼び出し時に wp-cron.php が POST によって起動され、予定されているイベントを確認し、公開、更新チェック、Heartbeat による下書きの保存、データベースのクリーンアップなどのタスクを開始します。各イベントには CPU時間. このアプローチは便利に聞こえますが、訪問が実行を決定し、計画可能なタイマーではないため、制御不可能なトリガーが発生します。複数の呼び出しが同時に発生すると、ワーカーを競合する並列 PHP プロセスが開始されます。 マルチサイト設定では、各サブサイトが独自のイベントスタックを管理するため、チェックの回数が増加し、この影響がさらに大きくなります [1]。この関連性について詳しく知りたい方は、以下の情報で基礎知識を深めることができます。 WP-Cron を理解する, しかし、核心的なメッセージは変わりません。訪問者の誘導は、信頼性の高い手段としては適していません。 クロック.

実際のブレーキ：wp-cron.php による並列 PHP プロセス

各 Cron トリガーは、ワーカーをバインドする個別の PHP プロセスを起動し、それによって利用可能な 計算時間 実際のページレンダリングのために削減されます。トリガーが集中すると、空きワーカーを待つ時間が長くなり、TTFB が長くなり、最初のバイトがブラウザに届くのが遅くなります [2]。測定では、最大 800 ミリ秒の遅延が確認されており、これは Core Web Vitals に悪影響を及ぼし、オーガニックの可視性を低下させます [3]。 共有ホスティングや、厳しく設定された PHP-FPM 設定は、max_children にすぐに到達し、プロセスがキューに入るため、この影響をさらに悪化させます。特にショップのピーク時やキャンペーン時には、これは悪循環に陥る可能性があります。トラフィックの増加は、より多くの cron チェックを生み出し、それがレンダリングをブロックし、その結果 ロード時間 伸ばす [1][2]。.

キャッシュ、CDN、ループバックのトラップを正しく扱う

WP-Cron はデフォルトで内部 ループバックリクエスト 自身のドメインに。その前に、攻撃的なページキャッシュ、CDN、または基本認証ブロックがある場合、呼び出しが失敗したり、待機したりすることがあります。Cronの実行が停滞し、繰り返され、CPUのバインドが延長されます。そのため、私は次のことを確実に実行しています。 /wp-cron.php キャッシュされず、レート制限もかけられず、内部からアクセス可能である。システムクロンは、この脆弱性を緩和します。 なし HTTPループバックが直接PHPを実行します。プロキシが上流にある場合、リクエストが 127.0.0.1 クリーンに渡され、WAF ルールによってエンドポイントがブロックされないようにしてください。メンテナンスフェーズでは、Cron を意図的に一時停止するか、エンドポイントを明示的に通過させて、期限が到来したタスクがパッケージとして「後追い」されないようにすることが重要です。.

不均一なCPU負荷を検知して分類する

典型的なのは、訪問者数だけでは説明できない、ラッシュアワーの負荷のピークです。これは、期限切れのイベントが積み重なって同時に発生することで生じる、cron の波によるものです。マルチサイトインストールでは、各サブサイトが cron リストを管理し、訪問時にチェックを行うため、負荷が倍増します。その結果、短いが激しいピークが発生し、ログファイルには wp-cron.php-POST のカスケードとして表示されます [1]。多くの場合、プラグインは間隔が短すぎる（5 分ごと、あるいはそれ以上の頻度）独自のイベントを登録しており、10 個のプラグインでは、1 回の呼び出しごとに数十回のチェックがすぐに積み重なってしまいます。さらに、以下の点にも注意してください。 PHPワーカーの制限, なぜなら、ワーカーが満杯になると、ユーザーが直接感じる待ち時間が発生するためです。このパターンを読むと、不均一な曲線はトリガーの結果であり、避けられないものではないことが理解できます。 気分 トラフィックの

システムクロンが負荷を平準化する理由

真のシステムクロンは、タスクを訪問者フローから切り離し、5分ごと、1時間ごと、1日ごとなど、明確な周期を設定します。これにより、実行を計画的に行い、負荷を均等に分散することができます[1][6]。 これにより、訪問者はクロンジョブをトリガーしなくなるため、TTFB の負荷が軽減され、レンダリングが優先されます。トラフィックが少ない場合でも、誰もページを訪問していなくてもサーバーがタスクを実行するため、タスクは確実に実行されます。これにより、更新、メール、インデックスの ping が時間通りに実行され、イベントが「滞留」して後で一括で実行されるのを防ぐことができます。このようにして、予測可能な システム負荷, トラフィックの状況によって変動しないもの。.

ステップバイステップ：WP-Cron を無効にし、システム Cron を設定する

wp-config.php で内部トリガーを無効にして、ページアクセスによって Cron ジョブが起動されないようにします。以下の行を追加してファイルを保存すると、WordPress はレンダリング時に Cron チェックを実行しなくなります。 その後、不要な出力を生成することなく、wp-cron.php を周期的に起動するクリーンな crontab ルールを設定します。これにより、ジョブは時間指定で実行され、ページアクセスに一貫して負荷がかかりません。結果：レンダリングが優先され、cron ジョブは独自の クロック.

// wp-config.php define('DISABLE_WP_CRON', true);

# Crontab の例（5 分ごと） */5 * * * * php -q /var/www/html/wp-cron.php > /dev/null 2>&1

直接 PHP を呼び出す代わりに WP-CLI を使用

より良い管理のために、私はcronの実行を WP-CLI これにより、「期限が到来した」イベントのみを実行し、より詳細にログを記録し、マルチサイトを的を絞って処理することができます。さらに、ロック機能により、複数の実行が同時に開始されるのを防ぎます。.

# WP-CLI: 期限が到来したイベントのみを処理 */5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet

# flock による簡単なロック（推奨） */5 * * * * flock -n /tmp/wp-cron.lock /usr/local/bin/wp cron event run --due-now --path=/var/www/html --quiet

マルチサイト環境では、次のようにして --url= サイトごとに確認するか、小さなシェルループを使用してサイトを順番に表示します。これにより、100 のサブサイトが同時に同じタイミングにアクセスして負荷のピークが発生するのを防ぐことができます。.

間隔と優先順位：どのタスクをいつ実行すべきか

すべてのタスクが毎分実行する必要があるわけではありません。私は関連性とコストに応じて優先順位をつけ、SEO に重要なジョブを優先し、コストのかかる作業はオフピーク時に実行するようにしています [1]。サイトマップの作成、インデックスピング、キャッシュウォーミングに重点を置き、その後にデータベースのメンテナンスとトランジェントの削除を行います。 バックアップは夜間に行うように計画し、I/O のピークを避けるために増分方式を選択しています。ニュースレターキューやインポーターはまとめて、ページがアクセスされるたびにチェックするのではなく、固定のスロットで実行しています。この順序により、優先順位が明確になり、短いポーリング間隔によって CPU 詰まる。.

タスク 推奨間隔 CPUへの影響 ヒント
サイトマップ/インデックスピング 1時間ごと～1日1回 ロー SEOに関連あり；キャッシュウォーミング前 優先する
キャッシュウォーミング 1～2回/日 ミディアム URLを段階的に処理し、ピーク時にはフルスキャンを行わない
バックアップ 夜 高い インクリメンタル、帯域幅制限付きリモートターゲット
データベースのクリーンアップ 毎日または毎週 ミディアム ブロック内のリビジョン/トランジェント 抹消
Eメール通知 1時間ごと/1日1回 ロー バッチを作成し、キューを利用する

シングルランメカニズムとクリーンロック

Cronの実行が重複しないように、私は 群れ WordPress独自の制限も導入しています。. WP_CRON_LOCK_TIMEOUT 実行が排他的に維持される時間を定義します。ページの動作が遅い場合や、実行時間が長いジョブがある場合は、2つ目のプロセスが早期に開始されないよう、この値を適度に増やします。逆に、ジョブが短く、ハングアップによってカスケードが発生しない場合は、この値を減らします。.

// wp-config.php – ロック時間（秒単位）（デフォルト 60） define('WP_CRON_LOCK_TIMEOUT', 120);

さらに、プラグインでは意図的に並行処理（バッチサイズ、ステップ長、リクエスト間のスリープ時間）を制限しています。これにより、cronの実行自体が再び数十のPHPプロセスを生成し、負荷曲線を上昇させることを防ぎます。.

モニタリングと分析：ボトルネックを可視化する

アクセスログから始めて、POSTリクエストをwp-cron.phpでフィルタリングして、頻度と時間枠を確認します。間隔が短い場合は、間隔が狭い、またはブロックイベントがあることを示しています。同時に、タイムアウト、ロック、データベースの待機時間など、cronジョブに影響を与えるエラーログもチェックします。 バックエンドでは、WP Crontrol を使用して、登録されたイベント、そのフック、および予定実行時間を確認します。そこで、古いエントリやハングしたエントリを削除します。トランザクション、クエリ時間、PHP-FPM キューについてより深く理解するために、私は WordPress用APMツール ホットスポットを特定するために。そうすることで、症状を抑えるだけでなく原因を見つけ出し、的を絞って対処することができます。 対策 優先順位をつける。.

測定可能な目標と10分間のクイックテスト

明確な目標値を定義します。キャッシュされたページの場合、TTFB p95 は 200～300 ミリ秒未満、キャッシュされていないページの場合は 800 ミリ秒未満。PHP-FPM キューは常に 0 に近く、CPU は飽和状態になるような急激なピークがないこと。 簡単なテスト：WP-Cron を無効にし、システム Cron を設定し、WP-CLI を使用して期限切れのイベントを 1 回処理し、ログを確認します。 10 分で、TTFB が低下し、PHP キューが縮小し、顕著なフック（更新チェック、インポーターなど）が主な原因であるかどうかがわかります。その後、曲線が安定するまで、間隔、バッチサイズ、およびクロックを調整します。.

Heartbeat API とプラグインイベントをうまく活用する

ハートビートメカニズムはセッションや下書きを更新しますが、フロントエンドでは不要なリクエストを頻繁に生成します。私はこれを管理エリアに制限するか、適切な間隔を設定しています。多くのプラグインは、間隔が短すぎるデフォルト値でクロンジョブを登録します。私は間隔を長く設定し、タスクをオフピーク時に移動しています。 ショップの設定では、在庫フィードと価格同期を 1 分ごとにポーリングするのではなく、固定スロットに制限しています。フィードとキャッシュウォーミングには、すべての URL が一度に実行されないように、バッチリストを使用しています。これらの介入により、リクエストの頻度が低下し、 カーブ はっきりと。

スケーリング：Cronジョブからキューとワーカーへ

トラフィックが多い場合は、WP-Cron をできるだけ小さく保ち、計算負荷の高いタスクは専用のワーカーによるキューに移します。ジョブキューは負荷を複数のプロセスに分散し、水平方向に拡張できるため、フロントエンドの待機時間を回避できます。コンテナまたはオーケストレーションのセットアップでは、PHP-FPM とは独立してワーカーをスケーリングするため、レンダリングとバックグラウンド作業に別々のリソースを割り当てることができます。 インポート、画像処理、ニュースレターバッチ、API 同期では、キューが特に効果を発揮します。これにより、フロントエンドの応答性を維持しながら、バックグラウンドジョブを制御し、 計画的 走る。

WooCommerce、アクションスケジューラ、および大規模なキュー

WooCommerce は、 アクションスケジューラ 注文メール、Webhook、サブスクリプション、同期を処理する独自のキューを用意しています。特にここでは、何千ものアクションが「due」になると、CPU のピークが発生する恐れがあります。ページアクセス時にランナーを実行させるのではなく、システムクロンまたは WP-CLI を使用して、固定のウィンドウでランナーをトリガーしています。 バッチサイズと並行性は、1回の実行でデータベースがブロックされたり、PHP-FPMワーカーが占有されたりしないよう設定しています。インポーター、画像再生成、ウェブフックのピークは、複数の小さな実行に分散しています。I/Oのブロックが発生して1時間以上かかるよりも、10回に分けて短時間で実行したほうがいいからです。.

マルチサイト固有の仕様：サイトごとのクロックをバランスさせる

マルチサイト設定では、各サイトが独自のイベントリストを持っているため、負荷が合計されます。5 分ごとにすべてをチェックする代わりに、サイトをローテーションしています。サイトグループは、すべての cron リストが同時に実行されないように、わずかにオフセットされたクロックで動作します。非常にアクティブなサイトは、キューに頻繁にスロットが割り当てられ、静かなサイトはより少ない頻度でスロットが割り当てられます。 その結果、CPU カーブがより均一になり、ワーカーの競合が減少します。総作業量は変わりません。.

実践チェック：障害のない設定

まず、DISABLE_WP_CRON が正しく設定されているかどうかを確認します。これは、重複したトリガー（内部 + 外部）が負荷のピークを悪化させるためです。次に、crontab をチェックします。正しいパス、不要な出力がないこと、適切な間隔、バックアップウィンドウとの重複がないことを確認します。 WP Crontrol で、古いフックを整理し、短い間隔を現実的なサイクルに変更します。PHP-FPM 設定を訪問者プロファイルに合わせて調整し、PHP ワーカーが常に上限に達しないようにします。最後に、TTFB、応答時間、CPU を追跡して、変更の効果を正確に把握します。 レート.

PHP-FPM、OPCache、および時間制限を適切に調整する

PHP-FPM が小さすぎる、またはクロック設定が間違っていると、最高の Cron 戦略も無駄になります。私は pm=dynamic 或いは pm=オンデマンド トラフィックプロファイルに応じて、 pm.max_children 実際の RAM 予算から：経験則として、RAM_für_PHP / 平均スクリプト消費量。例：2 GB の予算と、プロセスあたり約 128 MB で、約 16 ワーカーになります。. pm.max_requests リークをカットするために、控えめな設定（500～1000）にします。. リクエスト終了タイムアウト 限定的な異常値ジョブ、クリーンな スローログ クエリループや外部待機時間を検出します。健全な OPCache (十分な max_accelerated_files, メモリ消費, interned_strings_buffer) はコールドスタートを防ぎ、リクエストごとに CPU を節約します。Cron 実行も同様です。.

オブジェクトキャッシュとオプションの整理

永続的なオブジェクトキャッシュ（Redis/Memcached など）は、Cron チェックのデータベース負荷を大幅に軽減します。ここで重要なのは、 衛生 の中で wp_options-テーブル：オプション cron 数メガバイト以上に増えないようにしないと、チェックがすごく高くつくよ。古くなったイベントやハングしたイベントは削除して、オートロードのガラクタは減らして、大きくてめったに使わないオプションは autoload = no. これにより、クエリ時間が短縮され、cronリストの評価がより迅速に行えるようになります。.

微調整：タイミング、順序、リソースの制限

午前中にアクセスが集中するウェブサイトの場合、キャッシュウォーミングを深夜に設定し、営業時間直前にサイトマップを実行して、クローラーが最新のデータを認識できるようにしています。高価なデータベースのクリーンアップは、ロック時間を短縮し、クエリのピークを回避するために、小さなブロックに分割しています。 大規模なエクスポートは、インタラクションが少ない週末の時間帯に設定しています。 必要に応じて、複数の cron-php プロセスが同時に I/O を争うことがないように、並行ジョブを制限しています。 このような微調整により、安定したスループットとパフォーマンスの向上を実現しています。 応答時間.

セキュリティ：wp-cron.php を外部アクセスから保護する

Cron は内部で起動されるため、外部からの直接アクセスをブロックします。 /wp-cron.php. これにより、不正使用、DDoS、および誤った外部呼び出しを防止できます。ローカル呼び出し（ループバックまたは CLI）のみを許可し、その他はすべてブロックしてください。これにより、ログのノイズが低減され、PHP ワーカーが保護されます。.

# Nginx の例 location = /wp-cron.php { allow 127.0.0.1; deny all; include fastcgi_params; fastcgi_pass php-fpm; }

# Apache の例  Require ip 127.0.0.1

Cronによる「ゴースト」負荷の一般的な原因

重要度の低いタスクの非常に短い間隔（1～5 分）は、特に多くのプラグインと組み合わせた場合、最大の負荷要因のひとつです。失敗した実行によって繰り返し再スケジュールされるハングアップイベントは、ログを溢れさせるループを生成します。 データベースのロックの問題により、Cronジョブの実行時間が長くなり、重複が増えます。さらに、HTTPのブロック（DNSやリモートAPIなど）により、Cronの実行が人為的に長くなり、ワーカーが拘束されることもあります。このパターンを知っている人は、原因の調査に費やす時間を大幅に節約でき、 ピーク 速い。

簡単にまとめると

WordPress の CPU 負荷の不均一は、多くの場合、ページアクセス時にトリガーとして機能し、PHP ワーカーをバインドする WP-Cron が原因です。私は、内部トリガーをオフにし、システム Cron を設定し、間隔を最適化し、SEO 関連のタスクを優先して、レンダリングが優先されるようにしています。 ログ、WP Crontrol、APM 分析によるモニタリングにより、エラーのあるイベント、狭いサイクル、ブロックするプロセスを確認しています。大規模なプロジェクトでは、フロントエンドとバックグラウンドのジョブを明確に分離するために、計算負荷の高い作業をキューに移しています。この方法により、負荷が均一になり、TTFB が短縮され、顕著な改善が見られます。 より速い 配送 – 予期せぬピークなし。.

現在の記事