【実務・中級編】PHPのメモリマネージャ（Zend MM）のチャンク管理とアロケーションの断片化対策 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

2026.08.03

Zend MMの深淵：大規模配列とメモリ断片化を防ぐアロケーションの極意

コードレビュー中、私はジュニアやミドルクラスの開発者が書いた次のようなコードに対して、即座に修正を要求する。

// 10万件の外部APIレスポンス（巨大なJSON）をループで処理し、蓄積していく
$data = [];
foreach ($apiStream as $chunk) {
$data[] = json_decode($chunk, true);
}

「動くからいいじゃないですか」という反論が返ってくることが多い。しかし、Webシステムの裏側――Zend VMとZend Memory Manager（Zend MM）の挙動を知るエンジニアであれば、このコードが本番環境のヒープ領域で何を引き起こすか、冷汗をかかずにいられないはずだ。

本稿では、PHPの根幹を支えるメモリマネージャ（Zend MM）のチャンク管理メカニズムを紐解き、大規模配列の操作がなぜ「メモリ断片化」を誘発するのか、そしてそれを回避するための堅牢な設計ルールをコード例とともに提示する。

—

1. Zend MMの内部構造：OSヒープとチャンク管理の真実

PHPスクリプトが実行されるとき、メモリはOSから直接アロケートされるわけではない。Zend MMは、OSから「チャンク（Chunk）」と呼ばれる巨大なメモリブロック（通常は2MB単位）をまとまった形で一括取得し、それを独自のヒープ領域として抱え込む。

Zend MMの内部では、このチャンクをさらに細かく分割して管理している。アロケーションのサイズに応じて、以下のように戦略が分かれる。

  • Small/Medium Allocation: 特定サイズごとのバケット（Fixed-size allocator）を用いて高速に割当・解放を行う。
  • Large Allocation: 2MBを超えるような巨大なメモリ要求に対しては、専用のチャンクを直接割り当てる。

ここで問題になるのが、PHPの「動的かつ柔軟すぎる変数管理」だ。

PHPの配列（`array`）は、実体としてはハッシュテーブル（`HashTable`）であり、数値添字であっても内部的にはキーと値のペアがポインタを介して複雑に絡み合ってヒープ上に展開される。この配列に対して要素の追加・削除・再インデックス（`array_values()`など）を高速に繰り返すと、Zend MMの管理するメモリ空間に「穴（空き領域）」が無数に空く。これがメモリ断片化（Fragmentation）の正体である。

断片化が進行すると、「総空きメモリ容量は十分にあるにもかかわらず、連続した十分なサイズの空きブロックが見つからないため、Zend MMがOSから新規にチャンクを追加要求せざるを得なくなる現象（Memory Peakの跳ね上がり）」が発生する。これが、プロセスあたりのメモリ消費量を不当に膨らませ、OOM（Out of Memory） Killerの餌食になるメカニズムだ。

—

2. 大規模配列操作における「やってはいけない」アンチパターン

実務で最も危険なのは、数万〜数百万件のレコードを一度のプロセスでハンドリングするバッチ処理や、巨大なペイロードを扱うAPIエンドポイントである。

危険な設計：GCとZend MMを疲弊させるインプレースな巨大配列生成

  • 【アンチパターン】
  • 巨大なCSVやデータベースの全レコードを単一の配列にロードし、加工する

    • /
    function processLargeDatasetUnsafe(PDO $pdo): void
    {
    // 数十万件をフェッチしてメモリ上に一気に展開
    $stmt = $pdo->query(“SELECT id, payload, created_at FROM massive_table”);
    $records = $stmt->fetchAll(PDO::FETCH_ASSOC);

    $processed = [];
    foreach ($records as $record) {
    // 複雑な配列変形を行うたびに、HashTableの内部バケツが再割り当て・コピーされる
    $record[‘transformed’] = json_decode($record[‘payload’], true);
    unset($record[‘payload’]);

    $processed[] = $record;
    }

    // ここで膨大なメモリが消費され、スクリプト終了まで解放されない
    // （厳密にはリクエスト終了時にZend MMごとOSに返還されるが、FPMのプロセスプール内では重荷になる）
    ApiSender::sendBatch($processed);
    }

    このコードの問題点は、データのライフサイクルが長すぎることに加え、ループ内で配列の構造を変更し続けることでZend MMのヒープ上に微小な解放領域の断片を大量に残す点にある。結果として、プロセスのRSS（Resident Set Size）が肥大化し、コンカレントなリクエスト処理能力が著しく低下する。

    —

    3. 堅牢な設計ルール：メモリ断片化を最小化する極意

    では、数百万件のデータを安全に処理するにはどうすればよいのか。アーキテクトとして遵守すべき3つの設計ルールを提示する。

    1. ジェネレータ（Generator）によるストリーミング処理の徹底
    配列全体をメモリに保持せず、イテレータを流すことで、Zend MMが一度に抱えるアクティブなヒープサイズを常に一定の低水準に抑える。
    2. 不要になった変数の即時スコープアウトと`unset()`の適切な利用
    `unset()`を呼ぶことで、Zend MMは該当するZvalの参照カウンタをデクリメントし、即座にビンの再利用リスト（Free List）へ戻す。
    3. チャンク単位の処理（Chunking / Batching）
    データベースやAPIからの取得を一定のチャンクサイズに制限し、メモリ空間の「呼吸」を安定させる。

    —

    4. 実装リファレンス：ジェネレータとバッチ処理を組み合わせた安全なパイプライン

    以下のコードは、実務の現場で数百万件のレコード処理や巨大ログ解析を行う際に適用すべき、メモリ効率を極限まで高めた堅牢な実装例である。

  • Class StreamProcessor
  • Zend MMの断片化を防ぎつつ、大規模データを安全にストリーミング処理するアーキテクチャ。

    • /
    final class StreamProcessor
    {
    private const CHUNK_SIZE = 500; // メモリフットプリントを予測可能な範囲に固定するバッチサイズ

    public function __construct(
    private readonly PDO $pdo
    ) {}

    /

    • データベースからメモリ効率良くデータをジェネレータで引き抜く

    /
    private function fetchGenerator(string $sql): Generator
    {
    $stmt = $this->pdo->query($sql);

    while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
    // 1行ごとのデータをYieldすることで、全件ロードを回避
    yield $row;
    }
    }

    /

    • メモリ断片化を抑制した安全なバッチ処理パイプラインの実行

    /
    public function executePipeline(): void
    {
    $sql = “SELECT id, payload, created_at FROM massive_table WHERE processed = 0”;
    $batch = [];
    $counter = 0;

    foreach ($this->fetchGenerator($sql) as $row) {
    // 内部処理：ペイロードのデコードと不要キーの破棄
    // 配列の肥大化を防ぐため、必要なデータのみをスリムに構築する
    $row[‘meta’] = $this->extractMeta($row[‘payload’]);
    unset($row[‘payload’]); // 生の巨大JSON文字列は即座にメモリから解放

    $batch[] = $row;
    $counter++;

    // 規定のチャンクサイズに達したら外部へフラッシュし、配列を完全クリア
    if ($counter >= self::CHUNK_SIZE) {
    $this->flushBatch($batch);

    // 【重要】配列変数を空にし、Zend MMのFree Listへ確実に領域を返す
    $batch = [];
    $counter = 0;

    // 任意でGCを明示的に動作させる（循環参照の即時回収）
    if (gc_enabled()) {
    gc_collect_cycles();
    }
    }
    }

    // 最後に端数があればフラッシュ
    if (!empty($batch)) {
    $this->flushBatch($batch);
    unset($batch);
    }
    }

    private function extractMeta(string $payload): array
    {
    // デコードして必要な最小限の連想配列だけを返す
    $decoded = json_decode($payload, true);
    return [
    ‘status’ => $decoded[‘status’] ?? ‘unknown’,
    ‘code’ => $decoded[‘code’] ?? 0,
    ];
    }

    private function flushBatch(array &$batch): void
    {
    // 外部APIへのバルク送信やDBへの一括書き込みを想定
    // ここではシミュレーションとして処理を記述
    // printf(“Flushing batch of %d items. Current Memory: %s MB\n”, count($batch), round(memory_get_usage(true) / 1024 / 1024, 2));

    // 処理のシミュレーション
    usleep(10000);
    }
    }

    / ==========================================

    • 実行エントリポイントの模範例
    • ========================================== /

    try {
    $pdo = new PDO(‘mysql:host=localhost;dbname=production_db;charset=utf8mb4’, ‘user’, ‘pass’, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
    ]);

    $processor = new StreamProcessor($pdo);
    $processor->executePipeline();

    } catch (\Throwable $e) {
    // ログ出力と適切なエラーハンドリング
    error_log(“Critical Memory/Process Error: ” . $e->getMessage());
    exit(1);
    }

    —

    5. チーフアーキテクトからの最終インスペクション

    PHPは「動的言語だからメモリ管理を気にしなくてよい」という神話は、モダンな高トラフィックWebアプリケーションやマイクロサービス全盛の時代においては完全に破綻している。

    FPMプロセスがリクエストごとに肥大化し、プロセス再利用（`pm.max_requests`）の閾値に達する前にメモリを食いつぶすシステムの多くは、決まって「Zend MMの挙動を無視した巨大な配列操作と、断片化の放置」に原因がある。

    コードを書くとき、あなたの脳内には常に「この変数がZend VMのヒープ領域でどの程度のHashTableスロットを占有し、どのタイミングでZend MMによってFree Listへ回収されるか」のライフサイクルマップが描かれていなければならない。

    メモリを制する者が、PHPのパフォーマンスを制す。この知見を次のコードレビューから直ちに適用せよ。

    スポンサーリンク
    " "
    タイトルとURLをコピーしました