# 6. メモリ管理

> メモリ割り当て、制限、プール、バッファ、プロセスのサイジング

---

LLMSインデックス: [llms.txt](/ja/llms.txt)

---

<!-- Generated by scripts/generate-haproxy-docs.py from pinned upstream text. -->

HAProxy は、シンプルかつ高速なプールベースのメモリ管理を使用します。少数の異なるオブジェクト タイプに依存するため、異なるサイズごとに malloc() を呼び出すよりも、適切なサイズのオブジェクトが既に含まれているプールから新しいオブジェクトを選択する方がはるかに効率的です。プールはスタックまたは LIFO として編成されるため、新しく割り当てられたオブジェクトは、CPU キャッシュ内でまだホットな最近リリースされたオブジェクトから取得されます。メモリの断片化を制限するために、同様のサイズのプールがマージされます。

デフォルトでは、パフォーマンスに重点が置かれているため、解放された各オブジェクトは元のプールに戻され、割り当てられたオブジェクトはすぐに再利用されることが予想されるため、解放されることはありません。

CLI では、「show pools」コマンドを使用して、プールでメモリがどのように使用されているかを確認できます。

```shell
> show pools
Dumping pools usage. Use SIGQUIT to flush them.
  - Pool cache_st (16 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9ccc40=03 [SHARED]
  - Pool pipe (32 bytes): 5 allocated (160 bytes), 5 used, 0 failures, 2 users, @0x9ccac0=00 [SHARED]
  - Pool comp_state (48 bytes): 3 allocated (144 bytes), 3 used, 0 failures, 5 users, @0x9cccc0=04 [SHARED]
  - Pool filter (64 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 3 users, @0x9ccbc0=02 [SHARED]
  - Pool vars (80 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 2 users, @0x9ccb40=01 [SHARED]
  - Pool uniqueid (128 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 2 users, @0x9cd240=15 [SHARED]
  - Pool task (144 bytes): 55 allocated (7920 bytes), 55 used, 0 failures, 1 users, @0x9cd040=11 [SHARED]
  - Pool session (160 bytes): 1 allocated (160 bytes), 1 used, 0 failures, 1 users, @0x9cd140=13 [SHARED]
  - Pool h2s (208 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 2 users, @0x9ccec0=08 [SHARED]
  - Pool h2c (288 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9cce40=07 [SHARED]
  - Pool spoe_ctx (304 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 2 users, @0x9ccf40=09 [SHARED]
  - Pool connection (400 bytes): 2 allocated (800 bytes), 2 used, 0 failures, 1 users, @0x9cd1c0=14 [SHARED]
  - Pool hdr_idx (416 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9cd340=17 [SHARED]
  - Pool dns_resolut (480 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9ccdc0=06 [SHARED]
  - Pool dns_answer_ (576 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9ccd40=05 [SHARED]
  - Pool stream (960 bytes): 1 allocated (960 bytes), 1 used, 0 failures, 1 users, @0x9cd0c0=12 [SHARED]
  - Pool requri (1024 bytes): 0 allocated (0 bytes), 0 used, 0 failures, 1 users, @0x9cd2c0=16 [SHARED]
  - Pool buffer (8030 bytes): 3 allocated (24090 bytes), 2 used, 0 failures, 1 users, @0x9cd3c0=18 [SHARED]
  - Pool trash (8062 bytes): 1 allocated (8062 bytes), 1 used, 0 failures, 1 users, @0x9cd440=19
Total: 19 pools, 42296 bytes allocated, 34266 used.
```

プール名は単なる例示であり、このプールを使用する最初のオブジェクト タイプの名前です。括弧内のサイズは、このプール内のオブジェクトのオブジェクト サイズです。オブジェクトのサイズは常に 16 バイトの最も近い倍数に切り上げられます。現在割り当てられているオブジェクトの数とそれに相当するバイト数がレポートされるため、どのプールが最も多くのメモリ使用量を発生させているかを簡単に知ることができます。現在使用中のオブジェクトの数も「used」フィールドにレポートされます。 "allocated" と "used" の差は、オブジェクトが解放され、すぐに使用できるかどうかに対応します。行の末尾のアドレスはプールのアドレスで、次の数字はプール インデックス (存在する場合) であり、インデックスが割り当てられていない場合は -1 として報告されます。

「-m」コマンド ライン オプションに続いてメガバイト数を使用すると、プロセスごとに割り当てられるメモリの量を制限できます。これは、プロセスのアドレス指定可能な空間すべてをカバーするため、スタックだけでなく一部のライブラリで使用されるメモリも含まれますが、リソースに制約のあるシステムを構築する場合には信頼できる制限となります。これがあるシステムでは「ulimit -v」、他のシステムでは「ulimit -d」と同じように機能します。

メモリ制限に達したため、またはシステムに十分なメモリがないためにメモリ割り当てが失敗した場合、HAProxy は、メモリの再割り当てを試みる前に、まずすべてのプールから利用可能なすべてのオブジェクトの解放を開始します。未使用のメモリを解放するこのメカニズムは、HAProxy プロセスに SIGQUIT シグナルを送信することでトリガーできます。

リロード操作中に、グレースフルシャットダウンの状態に切り替わったプロセスは、接続を解放した後に自動的にいくつかのフラッシュを実行するため、すべての可能なメモリが解放されて新しいプロセス用に保存されます。