2026年5月28日

ApacheのWorker/Prefork/Eventの違いと選び方｜WordPress向けMPMの決め方

Webサーバー・Apache

Apache の MPM（マルチプロセッシングモジュール）は、リクエストを「プロセス」で処理するか「スレッド」で処理するかを決める部品です。結論から言うと、これから WordPress 用のサーバーを組むなら、多くの場合 event MPM と PHP-FPM の組み合わせが第一候補になります。この記事では、prefork・worker・event の仕組みの違い、今の MPM の確認方法、切り替え手順、主な設定値の考え方を説明します。

3つの MPM の仕組みの違い

MPM は同時に1つしか有効にできません。どれを選ぶかで、同時接続をさばく力とメモリの使い方が変わります。

prefork：1接続を1プロセスで処理する

prefork はスレッドを使わず、子プロセスを複数立ち上げておき、1つの接続を1つのプロセスが担当します。プロセス同士が独立しているため、スレッドに対応していないモジュールでも安全に動くのが特徴です。Apache に PHP を直接組み込む mod_php は、この prefork と組み合わせて使うのが一般的でした。

弱点はメモリです。mod_php を組み込んだプロセスは1つあたり数十MB以上になることがあり、同時接続数ぶんのプロセスが必要になるため、アクセスが増えるとメモリが先に尽きます。また、後述する KeepAlive で待機している接続にもプロセスが1つ占有されます。

worker：プロセスの中で複数のスレッドが処理する

worker は、1つの子プロセスの中に複数のスレッドを持ち、1接続を1スレッドで処理します。スレッドはプロセスより軽いため、同じメモリでより多くの接続をさばけます。その代わり、組み込むモジュールはスレッドセーフである必要があります。

event：待機中の接続を専用スレッドに任せる

event は worker を土台にした MPM で、Apache 2.4 で正式な選択肢になりました。KeepAlive で次のリクエストを待っているだけの接続を、リスナー用のスレッドがまとめて見張ります。処理用のスレッドは実際にリクエストが来たときだけ割り当てられるので、待機中の接続がスレッドを無駄に占有しません。

Debian/Ubuntu や RHEL 系の比較的新しいバージョンでは、パッケージで入れた Apache の既定の MPM が event になっていることが多いです（2026年10月現在）。ただし、mod_php のパッケージを入れると prefork に切り替わる構成もあるため、実際の状態は次の方法で確認します。

いま使っている MPM を確認する

# Debian/Ubuntu系
sudo apache2ctl -V | grep -i mpm
sudo apache2ctl -M | grep mpm

# RHEL/AlmaLinux系
sudo httpd -V | grep -i mpm

Server MPM: event のように表示されます。あわせて、PHP がどの方式で動いているかも確認しておきます。WordPress の「ツール → サイトヘルス → 情報」の「サーバー」欄にある「サーバー API」で、FPM/FastCGI なら PHP-FPM、Apache 2.0 Handler なら mod_php です（表記はバージョンによって多少違うことがあります）。

WordPress ではどれを選ぶか

判断の軸は「PHP をどう動かすか」です。

新しく構築する VPS・専用サーバー：event と PHP-FPM の組み合わせが第一候補です。Apache は静的ファイルの配信と接続の管理に専念し、PHP の実行は PHP-FPM のプロセスが担当します。Apache 側が軽くなり、PHP の同時実行数も PHP-FPM 側で独立して調整できます。
mod_php を使い続ける必要がある：prefork のままにします。mod_php とスレッド型の MPM は組み合わせない前提で考えてください。移行できる場合は、PHP-FPM への切り替えを検討する価値があります。
worker を選ぶ場面：event が使えるなら、新規に worker を選ぶ理由はあまりありません。event でうまく動かない特殊なモジュールがある場合の代替と考えるとよいでしょう。
レンタルサーバー：MPM は利用者が選べないのが普通です。サーバー会社の仕様に従います。

HTTP/2 を使いたい場合も event が有利です。mod_http2 は prefork とは相性が悪く、Apache 2.4 の比較的新しいバージョンでは prefork 環境で HTTP/2 が無効になります。

prefork + mod_php から event + PHP-FPM へ切り替える

以下は Debian/Ubuntu 系の例です。8.3 の部分はインストールされている PHP のバージョンに合わせて読み替えてください。作業前に /etc/apache2/ 以下をバックアップし、できればステージング環境で先に試します。

# 1. PHP-FPM を入れる
sudo apt install php8.3-fpm

# 2. mod_php と prefork を無効にし、event と FastCGI 連携を有効にする
sudo a2dismod php8.3 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.3-fpm

# 3. 構文確認をしてから再起動
sudo apachectl configtest
sudo systemctl restart apache2

MPM の変更は、設定の再読み込み（reload）ではなく再起動が必要です。再起動の瞬間は接続が切れるため、アクセスの少ない時間帯に行います。

切り替え後に確認したいことは3つあります。1つ目は、PHP のページが表示され、サイトヘルスのサーバー API が FPM になっていること。2つ目は、php.ini の設定です。mod_php と PHP-FPM では読み込む php.ini が別（Debian 系なら /etc/php/8.3/apache2/ と /etc/php/8.3/fpm/）なので、upload_max_filesize や memory_limit を変えていた場合は FPM 側にも反映します。3つ目は、.htaccess に書いた php_value などの PHP 設定です。これは mod_php 専用の書式で、PHP-FPM 環境では500エラーの原因になるため、FPM 側の設定（.user.ini やプールの設定）に移します。

RHEL 系では /etc/httpd/conf.modules.d/00-mpm.conf で、使う MPM の LoadModule 行だけを有効にし、ほかの行をコメントにします。

主な設定値の考え方

MPM の設定は、Debian 系なら /etc/apache2/mods-available/mpm_event.conf などにあります。event と worker で使う主な項目は次のとおりです。

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads         25
    MaxSpareThreads         75
    ThreadLimit             64
    ThreadsPerChild         25
    MaxRequestWorkers      150
    MaxConnectionsPerChild   0
</IfModule>

ThreadsPerChild：1つの子プロセスが持つスレッド数です。
MaxRequestWorkers：同時に処理できるリクエストの上限です。以前の MaxClients にあたります。
ServerLimit：子プロセス数の上限です。MaxRequestWorkers は ServerLimit × ThreadsPerChild を超えられないので、上限を大きくするときは両方を見直します。
MaxConnectionsPerChild：子プロセスが何接続を処理したら入れ替わるかです。0 は入れ替えなしを意味します。メモリが少しずつ増えるモジュールがある場合に値を設定します。

prefork では、スレッドの代わりに MinSpareServers・MaxSpareServers と MaxRequestWorkers でプロセス数を管理します。

数値の決め方は MPM によって違います。prefork + mod_php では、Apache のプロセス1つあたりのメモリ使用量を測り、「Apache に割けるメモリ ÷ 1プロセスのメモリ」を MaxRequestWorkers の上限の目安にします。

# Apache の子プロセスのメモリ使用量（RSS、KB単位）を大きい順に表示
ps -ylC apache2 --sort=-rss | head

event + PHP-FPM では、Apache のスレッドは軽いため、実際の上限は PHP-FPM 側の pm.max_children で決まることがほとんどです。Apache の MaxRequestWorkers を増やしても、PHP-FPM の子プロセスが足りなければ PHP のリクエストは待たされます。PHP-FPM のプロセス1つあたりのメモリを測り、同じ考え方で pm.max_children を決めます。

設定が足りているかを見分ける

上限に達すると、エラーログに server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting のようなメッセージが出ます。これが頻繁に出る場合は上限が足りていませんが、同時にメモリに余裕があるかも確認してください。メモリが足りないまま上限を上げると、スワップが発生してかえって遅くなります。

mod_status を有効にすると、各スレッドが処理中なのか、KeepAlive で待機中なのか、空いているのかを一覧で見られます。数値を変えたら、アクセスの多い時間帯にこの画面とメモリ使用量（free -h）を見比べ、少しずつ調整するのが無理のない進め方です。

まとめ

prefork は1接続1プロセスでメモリを多く使い、mod_php と組み合わせる方式
worker はスレッドで処理し、event はさらに待機中の接続を専用スレッドに任せる
新規の WordPress サーバーは event + PHP-FPM が第一候補。mod_php が必要なら prefork のまま
MPM の変更は再起動が必要。php.ini の場所と .htaccess の php_value の扱いが変わる点に注意する
event + PHP-FPM では、実際の同時実行数の上限は PHP-FPM 側の設定で決まることが多い