Zend MMとFiberの共生：大規模非同期空間におけるメモリフラグメンテーションの極限制御
PHP 8.1で導入された`Fiber`（ファイバー）は、PHPにおける非同期プログラミングのパラダイムを根本から変えた。従来の`ext-async`やGeneratorベースの協調的マルチタスキングとは異なり、Zend VMのコールスタックを独立したヒープ空間へと切り出し、言語コアレベルでコンテキストスイッチを実現するこのプリミティブは、I/Oバウンドなアプリケーションのスループットを劇的に向上させる。
しかし、数万から数十万のFiberが同時に生成・破棄される大規模非同期環境において、PHPの基盤を支える Zend Memory Manager (Zend MM) の挙動を誤れば、システムは深刻なメモリフラグメンテーション（断片化）とパフォーマンスの急降下、果てはリミット未達でのOOM (Out Of Memory) キルへと直結する。
本稿では、Zend MMの内部構造とFiberのコールスタック割り当て戦略の交差点に立ち、巨大な並行処理空間で発生するメモリの病理とその防衛策を、Zend VMの低レイヤの挙動から解き明かす。
—
1. Zend MMの内部構造とChunk/Pageアロケーションの物理
PHPのメモリ管理は、OSから直接`malloc()` / `free()`を頻繁に呼び出すことを避けるため、独自のメモリマネージャー（Zend MM）を介してプール管理を行っている。
Zend MMは、メモリを以下の階層で管理している。
1. Chunk (2MB単位): OSから`mmap()`等で一括確保される巨大なメモリブロック。
2. Page (4KB単位): Chunkを分割した管理単位。
3. Heap / Slot: 小さなデータ構造を割り当てるための微小なスロット。
+——————————————————-+
| Chunk (2MB) |
| +———-+———-+———-+———-+ |
| | Page(4KB)| Page(4KB)| Page(4KB)| Page(4KB)| … |
| +———-+———-+———-+———-+ |
| | Small | Large | Huge | | |
| | Slots | Alloc | Alloc | | |
| +———-+———-+———-+———-+ |
+——————————————————-+
Zend MMは、サイズクラス（Size Class）と呼ばれる固定長のバケットを用意し、高速な割り当てと解放（Free List形式）を実現している。問題は、ライフサイクルの異なるオブジェクトやコールスタックが混在する環境において、このFree Listがどのように断片化していくかにある。
—
2. Fiberスタックの動的割り当てとZend MMの衝突
Fiberが生成されるとき、Zend VMはその実行コンテキストを保持するために独自のコールスタック領域をヒープ上に確保する。従来の関数呼び出し（プレーンなスタックフレーム）は、リクエスト全体のコールスタック（Cのコールスタック、あるいはZend Executorのグローバルスタック）上で線形に積み上げられ、関数がreturnすれば一括で巻き戻されるため、フラグメンテーションは起きにくい。
しかし、Fiberは非同期イベントループのスケジュールに従って、バラバラのタイミングで生成され、サスペンドし、レジュームし、デストラクトされる。
Request Start ──> [HTTP / Event Loop]
│
+————–+————–+
▼ ▼
[Fiber #1] (Alive) [Fiber #2] (Dead/Free)
│ │
(Suspend 200ms) (Freed at Chunk X)
│ │
+————–+————–+
▼
[Zend MM Heap Fragmentation]
この「寿命の非同期性（Asynchronous Lifetimes）」がZend MMに与える影響は深刻である。
数千のFiberがランダムな順序でメモリ（スタックフレームやローカル変数、クロージャ等）を割り当て・解放を繰り返すと、Zend MMのChunk内には「使われているページ」と「空いたページ」が不連続に点在するようになる。
結果として、OSから見れば十分な空きメモリ（2MBのChunk単位）が存在しているにもかかわらず、連続した大きなメモリブロックを要求された際にZend MMが新しいChunkの確保を余儀なくされ、RSS（Resident Set Size）が急膨張する現象――すなわち外部フラグメンテーションを引き起こす。
—
3. 実践：高並行Fiber環境におけるメモリ枯渇シミュレーション
以下のコードは、数千のFiberを非同期イベントループ上で稼働させ、意図的にメモリの断片化とZend MMへの負荷を再現する検証用アーキテクチャの骨子である。
declare(strict_types=1);
namespace Architecture\Core;
use Fiber;
use Revolt\EventLoop;
class FiberMemoryStressTest
{
private array $fibers = [];
private int $concurrency;
public function __construct(int $concurrency = 5000)
{
$this->concurrency = $concurrency;
}
public function run(): void
{
echo “Initial Memory: ” . number_format(memory_get_usage(true)) . ” bytes\n”;
for ($i = 0; $i < $this->concurrency; $i++) {
$this->fibers[$i] = new Fiber(function (int $id): void {
// 意図的に巨大な配列やローカル変数をスタックに保持しサスペンド
$payload = range(1, 1000);
// 非同期I/Oを模したサスペンド
Fiber::suspend();
// レジューム後の処理でメモリを変化させる
unset($payload);
$computed = md5((string)$id . random_bytes(64));
Fiber::suspend();
});
// Fiberの開始
$this->fibers[$i]->start($i);
}
echo “Memory after Fiber creation: ” . number_format(memory_get_usage(true)) . ” bytes\n”;
// 全Fiberを一度レジュームして完了させる
foreach ($this->fibers as $fiber) {
if ($fiber->isSuspended()) {
$fiber->resume();
}
}
// さらにサスペンドを解除してデストラクトへ導く
foreach ($this->fibers as $fiber) {
if ($fiber->isSuspended()) {
$fiber->resume();
}
}
// 強制的なガベージコレクションの実行
gc_collect_cycles();
echo “Memory after cleanup: ” . number_format(memory_get_usage(true)) . ” bytes\n”;
echo “Peak Memory: ” . number_format(memory_get_peak_usage(true)) . ” bytes\n”;
}
}
// 実行エントリーポイント
(new FiberMemoryStressTest(10000))->run();
このコードがZend MMに与える低レイヤの衝撃
1. `range(1, 1000)` はZendのArray（`Bucket`構造体群）としてZend MMのヒープに細切れに割り当てられる。
2. これらが数万個のFiberコンテキスト内部からバラバラのタイミングで`unset()`され、Zend MMのFree Listに戻される。
3. Zend MMはこれら微小な空きスロットを効率よく再利用できず、新しいChunkの割り当て（`mmap`）を頻発させるため、`memory_get_peak_usage(true)`が跳ね上がる。
—
4. 極限のフラグメンテーション対策とアーキテクチャ設計
大規模なFiber駆動型アプリケーション（APIゲートウェイ、リアルタイムメッセージングサーバー等）において、Zend MMのフラグメンテーションを最小限に抑え、パフォーマンスを極限まで引き出すための設計指針を提示する。
A. オブジェクトプール（Object Pooling）パターンの適用
動的なインスタンス生成・破棄はZend MMのFree Listを最も激しく断片化させる。頻繁に使用されるDTOやコンテキストオブジェクトは、静的なプールクラスで管理し、インスタンスを再利用（Recycle）することで、メモリアロケーション自体の回数を劇的に削減する。
namespace Architecture\Optimization;
class RequestContextPool
{
private static array $pool = [];
private static int $maxSize = 1000;
public static function acquire(): array
{
if (!empty(self::$pool)) {
return array_pop(self::$pool);
}
return [‘id’ => 0, ‘data’ => null, ‘timestamp’ => 0.0];
}
public static function release(array $context): void
{
if (count(self::$pool) < self::$maxSize) {
// プロパティをリセットしてプールに戻す
$context['id'] = 0;
$context['data'] = null;
$context['timestamp'] = 0.0;
self::$pool[] = $context;
}
// プールが満杯の場合は参照を切ってZend MMの解放に委ねる
}
}
B. バッチ処理によるFiberライフサイクルのスコープ化
数万のFiberを同時に並行稼働させるのではなく、ワークキュー（Work Queue）パターンを採用し、同時にアクティブになるFiberの数（Concurrency Limit）を厳格に制御する。これにより、Zend MMが同時に抱えるアクティブなスタック領域のフットプリントを常に一定のバウンド内に収めることができる。
C. OPcacheプリローディングの最適構造化
Fiberを多用するシステムでは、ベースとなるフレームワーククラスやイベントループのコンポーネントはすべてOPcacheのプリロード（`opcache.preload`）に乗せるべきである。
これにより、実行時におけるクラス定義のパースや内部シンボルテーブル（`zend_class_entry`）の動的割り当てが排除され、Zend MMのヒープ空間を「純粋なデータとFiberスタック領域」としてクリーンに保つことが可能となる。
—
5. チーフアーキテクトの結語：メモリの呼吸を掌握せよ
PHPはもはや、単なる「リクエストごとにすべてを忘れる短命なスクリプト言語」ではない。Fiberと非同期イベントループの登場により、PHPプロセスは長時間稼働し、膨大なコンテキストを内部で高速にスイッチングする「常駐型エンジン」としての側面を強めている。
その背後で黙々とメモリの生死を管理し続けているのが Zend Memory Manager である。
アロケーションの裏側で何が起きているか、Chunkがどのように断片化し、なぜRSSが落ちないのかを低レイヤの視点から看破できる者だけが、真にスケーラブルで頑健なモダンPHPアーキテクチャを構築することができる。
コードの行数を減らすことだけが最適化ではない。Zend VMとメモリの呼吸を合わせること――それこそが、極限のWebシステムアーキテクチャの真髄である。