【実務・中級編】Zend MM（メモリマネージャ）の『Bucket』管理とアロケーションの断片化：大規模常駐プロセスにおけるメモリ枯渇の真因 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Zend MMとSwooleの交点：なぜ「枯渇」ではなく「断片化」でプロセスは死ぬのか

PHPアプリケーションのライフサイクルは、伝統的なCGI/FPMモデルにおいては「リクエストの終端とともにすべてのメモリがOSへ返却される」という圧倒的な安全神話の上に成り立っていた。グローバルスコープでのメモリリークさえ起こさなければ、OSのカーネルがプロセスごとメモリを回収してくれるため、動的言語でありながらガベージコレクション（GC）の深淵をそこまで意識せずともシステムは稼働し続けた。

しかし、SwooleやRoadRunnerに代表される「常駐型PHP（Long-running process）」の世界に足を踏み入れた瞬間、その甘美な安全神話は音を立てて崩壊する。

Zend Engineのメモリマネージャ（Zend MM）は、OSへのシステムコール（`malloc` / `free`）の頻度を極限まで減らし、実行速度を最大化するために独自ヒープ領域を抱えて管理している。このZend MMの内部構造、特にアロケーションの断片化（Fragmentation）のメカニズムを理解していない場合、数百万リクエストを捌いた先で、プロセスは「メモリリークしていないにもかかわらず、新たなメモリを確保できずにOOM Killerの餌食になる」という不可解な死を迎えることになる。

本稿では、Zend MMがヒープをどのように管理しているかという低レイヤの仕様を紐解き、常駐環境における真のメモリ枯渇の因果関係と、その対策をテクニカルリードの視点からシャープに伝授する。

—

1. Zend MMの内部構造：Heap、Chunk、そしてBucket（Page）の階層

Zend MM（PHP 7以降の `zend_alloc.c` を基盤とする実装）は、OSから直接メモリを細切れに取得するような愚行は犯さない。起動時に巨大なメモリブロック（通常はメガバイト単位の Chunk）をOSから一括確保し、それを自前のコンテキスト内で細分化して管理する。

Zend MMのメモリ管理階層は概ね以下のようになっている。

1. Chunk（チャンク）: OSから `mmap` 等で確保される巨大なメモリブロック（標準では 2MB 単位）。
2. Page / Bucket（ページ／バケット）: Chunkをさらに細分化した単位（1ページ = 4KB）。小さなアロケーション要求（Small Allocation）に対して、このページ単位でスロットが割り当てられる。
3. Huge Allocation: あまりに巨大なメモリ要求（通常は数KB以上）の場合、ChunkをバイパスしてOSから直接 `malloc` される。

Small AllocationとBucketの罠

PHPのコード中で生成される小さな配列、オブジェクト、文字列（`zend_string` や `zval`）の大部分は、数バイトから数百バイトの「Small Allocation」に該当する。Zend MMはこれらを高速に処理するため、サイズクラス（Size Class）と呼ばれる固定長のバケット群を用意し、そこに隙間なくパッキングしていく。

ここで発生するのが、「動的なアロケーションと解放の交錯による、バケットの歯抜け現象（断片化）」である。

長期間稼働するSwooleサーバーにおいて、無数の異なるサイズのリクエストが並行処理され、オブジェクトが生成・破棄され続けると、Chunk内のメモリ空間は「使用中」と「解放済み（Free）」の微小なパッチワーク状態になる。

Zend MMは空き領域を結合（Coalescing）するアルゴリズムを持っているが、完全にフラグメント化されたChunk群の中では、「新しく大きな連続したメモリ領域を要求された際、個々の空き容量の総計は足りているのに、連続したサイズ（Contiguous Block）が存在しないため、新しいChunkをOSに追加せざるを得ない」という事態が頻発する。これが常駐プロセスにおける真のメモリ肥大化（Inflated RSS）のメカニズムである。

—

2. 実務の現場で起きる事故：常駐プロセスでのメモリ肥大化コード例

以下のコードは、Swoole等の常駐環境において、一見正しく書かれているように見えても、Zend MMの断片化を加速させる典型的なアンチパターンである。

【危険な設計例】Swoole常駐サーバーにおけるリクエスト処理の断片化加速モデル

このコードの問題点：

毎回異なるサイズ、異なるライフサイクルの動的文字列や配列を大量に生成・破棄するため、

Zend MMのヒープ空間に無数のデッドスペース（断片）を生み出す。

/
use Swoole\Http\Server;
use Swoole\Http\Request;
use Swoole\Http\Response;

$server = new Server(“0.0.0.0”, 9501);

$server->on(“request”, function (Request $request, Response $response) {
// リクエストごとにランダムなサイズ・構造のデータを作成・破棄
$payloadSize = mt_rand(100, 5000);
$data = [];

for ($i = 0; $i < $payloadSize; $i++) { // キーも値も動的に生成され、Zend MMの様々なサイズクラスのバケットを消費する $data["key_" . $i] = str_repeat("A", mt_rand(10, 200)); } // 重い処理のシミュレーション $json = json_encode($data); // 変数の明示的な解放（unset）を行っても、Zend MMの断片化は防げない場合がある unset($data); $response->header(“Content-Type”, “application/json”);
$response->end($json);
});

echo “Swoole server is running…\n”;
$server->start();

なぜ `unset($data)` をしてもメモリが下がらないのか？

ジュニア・ミドルクラスのエンジニアによれば、「使い終わったら `unset()` を呼んでいるからメモリリークは起きないはずだ」という反論が飛んでくる。しかし、ここでZend MMの低レイヤの挙動が牙をむく。

`unset($data)` は確実にZend MMへメモリを返却している。しかし、返却されたメモリは「Chunk内の特定のバケット（例: 64バイトスロット）」に戻るだけであり、そのChunk全体がOSに返却されるわけではない。
隣接するバケットがまだ他のアクティブなリクエスト（別タスクや非同期コルーチン）によって占有されている限り、ChunkそのものをOSのメモリマップから切り離す（`munmap`）ことはできないのだ。結果として、プロセスのRSS（Resident Set Size：物理メモリ使用量）は高止まりしたまま落ちなくなる。

—

3. 堅牢な設計ルール：Zend MMの断片化と戦うためのプラクティス

常駐型PHPアプリケーションで数週間の連続稼働を実現するためには、Zend MMの挙動をコントロールする、あるいは断片化の影響を受け流すアーキテクチャ設計が不可欠である。

ルール1: リクエスト・コルーチン境界での「メモリの使い捨て」を均質化する

Swoole / Coroutine環境では、リクエストごとに確保するデータ構造のサイズクラスを可能な限り均質化・予測可能にする。極端に巨大な配列や、深すぎる多次元配列の動的生成を避け、データ構造のテンプレート（DTO）を固定化することで、Zend MMが特定のサイズクラスのバケットを効率的に再利用できるようにする。

ルール2: 定期的なプロセス再起動（Worker Max Requests）の強制

どれほど洗練されたコードであっても、数百万回の動的アロケーションを経ればZend MMの断片化は不可避に進行する。Swooleの `max_request` 設定を適切に利用し、一定リクエスト数に達したワーカープロセスを安全にgraceful shutdownし、マスタープロセスに新規ワーカーをフォークさせよ。これにより、プロセスが保持していた断片化ヒープはOSへ一括返却される。

$server->set([
‘worker_num’ => 4,
‘max_request’ => 10000, // 1万リクエストごとにワーカーをリフレッシュし、断片化をリセット
]);

ルール3: 頻繁に利用するオブジェクトや文字列のプール（Pre-allocation / Pooling）

頻繁に確保・破棄される構造体がある場合、アプリケーション層でプールを実装し、動的な `malloc`/`free`（Zend MMにおけるバケット確保・解放）の頻度そのものを劇的に減らす。

—

4. 実務で使える堅牢なリファレンスコード：メモリプールとプロセス防衛パターン

以下に、Swoole環境等の常駐プロセスにおいて、Zend MMの断片化を抑制しつつ、安全にリクエストを処理するための洗練された構造を示す。ここでは、「オブジェクトの再利用（プーリング）」と「定期的なメモリ安全弁」の思想をコードに落とし込んでいる。

Class RequestContextPool

【テクニカルリード設計】

Zend MMの動的アロケーションによる断片化を緩和するため、

リクエスト間で使い回せるバッファやオブジェクトを静的に保持・再利用するプール機構。

/
final class RequestContextPool
{
private static ?self $instance = null;

/ @var array 事前確保された文字列バッファプール /
private array $stringBufferPool = [];

private int $requestCounter = 0;
private const MAX_REQUESTS_BEFORE_CLEANUP = 5000;

private function __construct() {
// 初期化時に一定のメモリ構造を固定化し、Zend MMの初期Chunkレイアウトを安定させる
$this->initializePool();
}

public static function getInstance(): self
{
if (self::$instance === null) {
self::$instance = new self();
}
return self::$instance;
}

private function initializePool(): void
{
// 固定長のプレースホルダーを事前割り当て
for ($i = 0; $i < 100; $i++) { $this->stringBufferPool[“buf_{$i}”] = str_repeat(‘ ‘, 1024); // 1KB固定バッファ
}
}

プールからバッファを取得することで、動的なメモリ確保と断片化を抑制する

/
public function getBuffer(int $index): string
{
$key = ‘buf_’ . ($index % 100);
return $this->stringBufferPool[$key];
}

リクエスト処理カウンターを進め、限界値に達した場合は安全のためのシグナルを送る

/
public function inspectMemorySafety(): bool
{
$this->requestCounter++;

if ($this->requestCounter >= self::MAX_REQUESTS_BEFORE_CLEANUP) {
// 閾値到達。アプリケーション層からワーカーの軟着陸（Graceful Exit）を促す
return false;
}

return true;
}

public function reset(): void
{
$this->requestCounter = 0;
// 必要に応じた内部キャッシュのパージ
}
}

// ==========================================
// Swooleサーバー内での実用ディスパッチ例
// ==========================================
/
use Swoole\Http\Server;
use Swoole\Http\Request;
use Swoole\Http\Response;

$server = new Server(“0.0.0.0”, 9501);

$server->on(“request”, function (Request $request, Response $response) {
$pool = RequestContextPool::getInstance();

// メモリ安全性のチェック（Zend MMの断片化・肥大化を防ぐ防衛ライン）
if (!$pool->inspectMemorySafety()) {
$response->status(503);
$response->end(“Service Refreshing. Please retry.”);

// 現在のワーカーを安全に終了させ、マスタープロセスに新プロセスを起動させる
Swoole\Event::defer(function() use ($server) {
$server->shutdown();
});
return;
}

// プールされたリソースの利用
$buffer = $pool->getBuffer(mt_rand(0, 99));

$response->header(“Content-Type”, “text/plain”);
$response->end(“Processed with stable memory footprint. Buffer size: ” . strlen($buffer));
});

$server->start();
/

—

5. アーキテクトからの最終提言

PHPはもはや「リクエストごとにすべてを忘れるお気楽なスクリプト言語」ではない。Swoole、RoadRunner、そしてFrankenPHPといったモダンな常駐型ランタイムの普及により、私たちはZend Engineの内部構造、とりわけZend MMの挙動と向き合う宿命を背負った。

「メモリリークがない」という言葉を鵜呑みにしてはならない。「断片化（Fragmentation）」という名の静かなる侵略は、リークチェッカーの検知をすり抜け、本番環境の深夜に静かにプロセスを屠る。

コードを書くとき、あなたは常に脳内でZend MMのChunkとBucketがどのように構築され、破棄された後にどのような隙間を残すかをトレースできなければならない。この低レイヤの解像度こそが、真に堅牢でスケールするPHPシステムを組み上げる唯一にして最大の武器である。