こんにちは。普段から大規模なPHPアプリケーションのパフォーマンスチューニングや、Zend Engineの挙動に頭を悩ませていることと思います。
他のモダンな言語（JavaやGo、Node.jsなど）からPHPの世界にやってくると、その独特な「1リクエストですべてを破棄する」というライフサイクルに心地よさを覚える一方で、巨大なバッチ処理やAPIミドルウェアを書き始めた途端、謎のメモリリークや突然のパフォーマンス低下に直面して戸惑うことがよくありますよね。
今回は、PHPのパフォーマンスチューニングにおいて最も見落とされがちであり、かつ極めて重要なテーマである「`memory_limit`設定とガベージコレクション（GC）の相互作用」について、Zend Engineの内部構造に深く潜り込みながら、私と一緒に紐解いていきましょう。
ここを綺麗に理解できるようになると、「なぜこのバッチ処理は途中で急に重くなるのか」「なぜ`memory_limit`をむやみに上げると危険なのか」の理由が、裏側のメモリ空間の動きとともにクリアに見えるようになりますよ。
—
1. Zend Engineにおけるメモリ管理の基本原理
まず、大前提としてPHPのメモリ管理がどう行われているかを確認しておきましょう。
PHPの変数やオブジェクトは、C言語レベルの構造体である `zval`（Zend Value）として表現され、Zendメモリマネージャー（ZMM）によって効率的に管理されています。各`zval`は「参照カウント（refcount）」という仕組みを持っており、その変数が指し示されている回数を数えています。
/ 概念的なイメージ（Zend Engine内部のzval構造の簡略化） /
typedef struct _zval_struct {
zend_value value;
union {
uint32_type type_info;
} u1;
union {
uint32_t refcount; // 参照カウント
} u2;
} zval;
通常のコードであれば、変数がスコープを抜ける、あるいはスクリプトが終了すると、参照カウントは即座にデクリメントされ、`0`になった瞬間にメモリは解放されます。C言語のように手動で `free()` を呼ばなくても安全なのは、この参照カウントがリアルタイムに働いているからですね。
循環参照という「例外」
しかし、オブジェクト同士が互いにプロパティとして参照し合うような「循環参照（Circular Reference）」が発生すると話が変わります。
例えば、親オブジェクトが子オブジェクトを持ち、子オブジェクトも親への参照（プロパティやバックリンク）を持っている場合、外部からの参照を断ち切っても、お互いの参照カウントが`1`残ったままになってしまいます。
これがいわゆる「メモリリーク」の正体です。この放置されたメモリを回収するために存在する掃除屋が、PHPのガベージコレクタ（GC）なのです。
—
2. PHPのGCは「どうやって」実行されるのか？
他の言語（Javaなど）のGCは、ヒープ領域全体の容量や世代別管理に基づいて自律的にバックグラウンドで動くことが多いですよね。しかし、PHPのGCは少しアプローチが異なります。
PHPのGCは、「ルートバッファ（Root Buffer）」という固定長（デフォルトでは10,000エントリ）のリングバッファをベースに動いています。
1. 参照カウントが減少したものの、`0`にはならなかった`zval`（可能性のあるもの）が、自動的に「ルートバッファ」にバッファリングされます。
2. バッファが一杯になる（あるいは明示的に `gc_collect_cycles()` が呼ばれる）と、GCアルゴリズムが発動します。
3. バッファ内の候補をスキャンし、実際に循環参照によって孤立しているかを判定してメモリを解放します。
ここで重要なのは、「バッファが溢れるまでGCは自動実行されない」という事実です。
—
3. `memory_limit` が GC の挙動とパフォーマンスに与える影響
さて、本題の `memory_limit` との相互作用についてです。多くの開発者は「`memory_limit` はプロセスの暴走を防ぐための安全弁（リミッター）」程度に捉えているかもしれませんが、実は Zend Engineのメモリ割り当て戦略とGCの実行タイミングを裏で支配する極めて重要なパラメータなのです。
ZMMのチャンク管理とメモリの断片化
PHPはOSから直接小さなメモリを何度も要求せず、最初に大きな塊（チャンク、通常2MB単位など）をOSから確保し、その内部で細かくメモリを割り当てていきます。
`memory_limit` を極端に大きく設定している場合（あるいは `-1` 無制限にしている場合）、Zendメモリマネージャーはメモリ不足を恐れる必要がないため、新しいメモリ要求に対して次々とキャッシュや既存のチャンクを流用し続けます。
ここで何が起きるでしょうか？
1. GCが発動する機会の喪失: ルートバッファが一杯になる前にプロセスが終了するか、あるいはメモリが潤沢にあるためバッファの閾値に達せず、循環参照の回収が先送りされます。
2. メモリフットプリントの肥大化: 回収されない循環参照オブジェクトがメモリ上に居座り続け、RSS（Resident Set Size：物理メモリ使用量）が右肩上がりに膨れ上がります。
3. コンテキストスイッチとCPUキャッシュヒット率の低下: 巨大なメモリ空間をCPUが頻繁に行き来するようになるため、L1/L2キャッシュのヒット率が下がり、パフォーマンスがジワジワと低下していきます。
逆に、`memory_limit` を適切に、あるいは必要最小限にタイトに設定している環境では、メモリ管理のしきい値が厳しくなるため、ZMMはよりアグレッシブにメモリ再利用のプレッシャーを受けます。
—
4. 実践：巨大なデータ処理における挙動の違いを体感する
例えば、数万件のレコードを処理するコンソールコマンド（バッチ処理）を書いてみましょう。
child = $child;
$child->parent = $parent; // ここで循環参照が発生
// 通常の処理が終わっても、$parent と $child はスコープを抜ければ
// 参照カウントが1残るため、GCが回収するまでメモリに残る
if ($i % 10000 === 0) {
// 現在のメモリ使用量とGCの状態を確認
$mem = memory_get_usage(true) / 1024 / 1024;
echo “Iteration {$i}: Memory usage: ” . round($mem, 2) . ” MB\n”;
// GCの状態を表示
$gcStatus = gc_status();
// echo “Root buffer size: {$gcStatus[‘buffer_size’]}\n”;
}
}
}
// 実行
run_heavy_process();
このようなコードを `memory_limit = -1`（無制限）で実行すると、OSのメモリを食い潰すまでGCが本気を出さず、プロセスが重くなっていきます。一方で、適切な `memory_limit` の下で、必要に応じてこまめに `gc_collect_cycles()` を挟む、あるいはメモリのライフサイクルを意識した設計にすることで、メモリ使用量を一定の平坦なラインに抑えることができます。
—
5. アーキテクトが実践すべきチューニングの極意
現場でパフォーマンスの壁にぶつかったとき、私たちが取るべきアプローチは以下の通りです。
1. `memory_limit` を「保険」として適切に小さく絞る
WebフックやAPIのエンドポイントであれば、意図せぬメモリリークや無限ループの暴走を防ぐために、アプリケーションの規模に応じた最小限の値を設定します（例: `256M` や `512M`）。大きくしすぎると、リークに気づくのが遅れます。
2. 長寿命プロセス（ReactPHPやSwoole、長期バッチ）ではGCを自らコントロールする
PHP-FPMのように1リクエストで破棄される世界ではなく、プロセスが永続化する環境では、メモリリークは致命傷になります。定期的なタイミングや、大きな処理のブロックの抜け際に明示的に `gc_collect_cycles()` を呼び出し、ルートバッファをクリアする設計を取り入れましょう。
3. そもそも「循環参照を作らない」設計を意識する
オブジェクト指向設計において、親と子が相互に参照し合う双方向リンクは便利ですが、リソース管理の観点からは諸刃の剣です。ID（スカラー値）だけで参照を保持するように設計を改めるなど、`zval` の参照カウントの負担を減らすアプローチが最も効果的です。
—
おわりに
PHPは「シンプルに動く言語」であるからこそ、内部のエンジン（Zend VM、メモリマネージャー、GC）がどのように動いているかを知っているかどうかで、書くコードの質とシステムの安定性が劇的に変わります。
「なぜこの設定値になっているのか」「このメモリは今どこで保持されているのか」。
そんな視点を少しだけ低レイヤに向けてみることで、あなたの作るWebシステムは、より堅牢で、予測可能で、美しいパフォーマンスを発揮するようになりますよ。
日々のアーキテクチャ設計の参考にしていただければ幸いです。一緒にPHPの奥深い世界を極めていきましょう。