【Apacheチューニング 第2回】パフォーマンス編 – 1ミリ秒を削り出す。MPM Eventの限界チューニングとベンチマーク計測術

「勘」で設定するエンジニアは三流である

こんにちは！「リナックス先生」です。
前回はWAFやヘッダー制御による「防御」を固めましたが、今回はWebサーバーの至上命題である「パフォーマンス」について、深く、深く切り込んでいきます。

▼前回の記事はこちら（セキュリティ設定は万全ですか？）
【第1回】セキュリティ編 – WAF導入とTLS強化で実現する、国家標準レベルの「要塞化Apache」

コウ君

先生、大変です！
アクセスが増えてサイトが重くなったので、ネットでおすすめされていた通り MaxRequestWorkers をデフォルトの150から 1000 に増やしてみたんです。
そうしたら、夜中にサーバーがフリーズして、再起動するまでsshも繋がらなくなりました…。
やっぱり、メモリを増設するしか解決策はないんでしょうか？

リナックス先生

コウ君、それは典型的な「設定ミスによる自爆」ね。
メモリの容量を考えずに接続数だけ増やせば、OSはメモリ不足に陥り、重要なプロセスを強制終了（OOM Killer）させてしまうわ。
パフォーマンス・チューニングとは、闇雲に数値を増やすことじゃない。「物理メモリという予算の中で、いかに効率よく客をさばくか」を計算することなの。
今からその計算式を教えるから、電卓を用意しなさい。

1. 敵を知る：Prefork vs Event MPM

計算の前に、前提条件を確認します。
もしあなたのApacheがまだデフォルトの「Prefork」モードで動いているなら、今回のチューニングの前に必ず「Event MPM + PHP-FPM」へ移行してください。

  • Prefork（旧世代）： 1アクセスごとに「重たいプロセス」を複製する。メモリ効率が最悪。
  • Event（新世代）： 「スレッド」を使って軽量に多数のアクセスを処理し、重たいPHP処理だけをPHP-FPMに投げる。メモリ効率が良い。

※以下の解説は、Event MPM環境であることを前提に進めます。

2. 精密計測：1プロセスの体重測定

「Apacheがどれくらいメモリを使うか」は、サーバーの環境（導入しているモジュール数など）によって異なります。
まずは現状の「1プロセスあたりの平均消費メモリ」を実測しましょう。

計測コマンド

SSHでサーバーにログインし、以下のコマンドを実行してください。

# httpdプロセスのメモリ使用量(RSS)を表示し、平均値を出す
ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Avg: " sum/n/1024 " MB"}'

※Ubuntuの場合は httpd を apache2 に変更。
※PHP-FPMを使っている場合は、php-fpm プロセスも同様に計測して考慮する必要があります。

【計測結果の例】
ここでは仮に、ApacheとPHP-FPMを合わせて、1リクエスト処理するのに平均 50MB 必要だと仮定します。

3. 黄金の計算式：MaxRequestWorkersの算出

ここが今回のハイライトです。
サーバーの物理メモリから、OSやデータベースが使う分を差し引き、残りをApacheに割り当てます。

Step A: サーバーのスペック確認

free -m
  • 物理メモリ総量： 4GB (4096MB) とします。

Step B: 必須確保メモリ（聖域）

Apache以外に必要なメモリを見積もります。

  • OSカーネル・基本プロセス： 約500MB
  • MySQL (InnoDB Buffer Pool等)： 約1GB (1024MB) ※設定によりますが最低これくらいは確保
  • その他（Cron, Postfix, sshd等）： 約200MB

聖域の合計： 約1.7GB (1724MB)

Step C: Apacheへの割当可能量

4096MB – 1724MB = 2372MB

この「2372MB」こそが、Apache（とPHP-FPM）が使える予算の上限です。

Step D: 限界接続数の算出

割当可能メモリ (2372MB) ÷ 1プロセスのサイズ (50MB) ≒ 47

結論が出ました。
このサーバーにおける MaxRequestWorkers の適正値は「47」です。
これを「150」や「1000」に設定していたら、アクセスが集中した瞬間にメモリが溢れ（スワップ発生）、サーバーの反応速度は100倍遅くなり、最終的にダウンします。

4. mpm_event.conf の完全チューニング

計算値に基づき、設定ファイルを編集します。
単に上限を決めるだけでなく、アイドル（待機）プロセスの制御も重要です。

ファイルパス： /etc/httpd/conf.modules.d/00-mpm.conf (RHEL系) または /etc/apache2/mods-available/mpm_event.conf (Ubuntu)

<IfModule mpm_event_module>
    # 【上限設定】
    # 計算した「47」を設定。ServerLimitも合わせる。
    ServerLimit              47
    MaxRequestWorkers        47

    # 【起動・待機設定】
    # 起動直後に用意するプロセス数
    StartServers              2
    
    # 待機スレッド数の下限・上限
    # 少なすぎると急なアクセス増で待たされ、多すぎるとメモリの無駄遣いになる
    MinSpareThreads          25
    MaxSpareThreads          50

    # 【スレッド設定】
    # 1プロセスあたりのスレッド数（25〜64程度が一般的）
    ThreadsPerChild          25

    # 【メモリリーク対策（最重要）】
    # 1つのプロセスが1000回リクエストを処理したら、一度終了させてメモリを開放する。
    # これを0（無制限）にすると、微量なメモリリークが蓄積していつかダウンする。
    MaxConnectionsPerChild 1000
</IfModule>

PHP-FPMの設定も連動させる：
Apache側で制限しても、PHP側が無制限なら意味がありません。/etc/php-fpm.d/www.conf の pm.max_children も「47」に近い値（または少し少なめ）に調整してください。

5. 「待ち時間」を削れ！KeepAliveと圧縮の最適化

同時接続数の上限が決まっている以上、「1人あたりの滞在時間を短くする」ことが、より多くのユーザーをさばく鍵になります。

KeepAliveTimeout の短縮

KeepAlive（接続維持）は、1人のユーザーが画像などを連続して取得するのに役立ちますが、維持時間が長いと「何もしていないのに居座るユーザー」で席が埋まってしまいます。

デフォルトの「5秒」は長すぎます。現代の高速な回線事情なら「2〜3秒」で十分です。

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 3

Brotli圧縮の導入

転送するデータ量自体を減らせば、通信は早く終わります。
Gzipよりも圧縮率の高い「Brotli」を有効化しましょう。

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript application/json
    BrotliCompressionQuality 4
</IfModule>

※圧縮レベル（Quality）を上げすぎるとCPU負荷が高まるため、4〜5程度がバランスの取れた推奨値です。

6. 結果を証明する：Apache Bench (ab)

設定変更後は、必ず再起動し、ベンチマークテストを行って効果を確認します。

テスト実行

# -n 1000 (合計1000リクエスト)
# -c 10 (同時に10人がアクセス)
ab -n 1000 -c 10 https://your-domain.com/

見るべきポイント

  1. Requests per second: 1秒間にさばけた数。これが多いほど高性能。
  2. Failed requests: これが0であること。「設定を絞りすぎてエラーが出ていないか」を確認。
  3. TOPコマンド: テスト中に top コマンドを見て、スワップ（Swap）が発生していないか確認。

まとめ：安定こそが最大のパフォーマンス

お疲れ様でした。
今回のチューニングで、あなたのサーバーは「無謀な設定」から脱却し、「ハードウェアの性能を使い切る、計算された設定」に生まれ変わりました。

コウ君

「設定値を大きくすれば速くなる」なんて、とんだ勘違いでした…。
計算通り「47」に設定して、KeepAliveを短くしたら、アクセス集中時でもサーバーが落ちなくなりました！
サクサク動いていて、ログを見てもエラーがありません！

リナックス先生

素晴らしいわ。
「落ちない」ということは、ユーザーを逃がさないということ。
もし計算結果で「接続数が足りない（もっと多くの人をさばきたい）」となったら、それは設定を変えるのではなく、物理メモリを増やす（プランを上げる）タイミングよ。
無理な設定で誤魔化そうとしないのがプロの判断ね。

▼計算結果でメモリ不足を感じたら

チューニングで効率化しても、物理的なメモリ容量の限界は超えられません。アクセス増に合わせてスケールアップが容易な、プロ推奨のハイスペックVPSはこちらです。

【2026年最新】Linuxサーバー構築におすすめのVPS比較3選！現役エンジニアが速度とコスパで厳選
Linuxの勉強、まだ「自分のPC」でやって消耗していませんか？「Linuxを覚えたいけど、環境構築でエラーが出て先に進めない…」「VirtualBoxを入れたらパソコンが重くなった…」これは、Linux学習を始める9割の人がぶつかる壁です...
www.linuxkoubou.com
2026.01.05

さて、次回の最終回は、Apacheを単なるWebサーバーとしてだけでなく、Node.jsやPythonなどのアプリと連携させる「リバースプロキシ」と「ロードバランシング」の世界へ案内するわ。インフラ構築の楽しさはここからよ！

コメント