> 本文の要約：
> 1. `shm_size`はRAMを使用する一時的な領域です。
> 2. `ipc: host`を使用する場合、`shm_size`は無意味となり、ホストリソースの50%が割り当てられて使用されます。
> 3. 多くのAIモデルの例では、`ipc: host`と`shm_size`が同時に設定されているのをよく見かけますが、実際にはどちらか一方のみを設定する方が可読性が高まります。
> 4. AIワークロードでは、少なくとも**8G〜16G**以上を推奨します。ご自身の環境に合わせて選択・設定してください。



## 🐳 AI/データワークロードの必須設定: Docker共有メモリ (shm_sizeとipc) を徹底解説 {#sec-2161daf65756}


AIおよび大容量データ処理ワークロードで`OSError: No space left on device`のような不明なエラーに遭遇した場合、そのほとんどは**[[Docker]]コンテナの共有メモリ(`shm_size`)設定が不足している**ことが原因です。

この記事では、コンテナ環境において共有メモリがなぜ重要なのか、そして`shm_size`と`ipc: host`オプションをどのように正しく設定すべきかについて明確に解説します。

![shm_sizeとipc方式の比較画像](/media/whitedec/blog_img/5c8cd9fb5f93404fb70bc6019e296acf.webp)

---

## 1. shm_sizeの役割と重要性 {#sec-21161777e576}


### 役割: コンテナの共有メモリサイズを決定 {#sec-5e3ff7cb88f8}


**`shm_size`** は、コンテナ内部の**/dev/shm (POSIX shared memory)**ファイルシステムの**最大サイズ**を設定するオプションです。

* [[Docker]]のデフォルト値は**64MB**と非常に小さいです。
* **注意**: `/dev/shm`は**ホストRAM**を使用する**`tmpfs`** (一時ファイルシステム)であり、**VRAM (GPUメモリ) とは無関係**です。


### なぜ重要なのか？ {#sec-8127b7b9aeb4}

AI/データ処理タスクでは、プロセス間で大量のデータをやり取りする際に、この**共有メモリ**を中核的に活用します。

* **PyTorch DataLoader**: `num_workers > 0`設定時、ワーカープロセス間で**テンソル/バッチを共有メモリで転送**します。この領域が不足すると、`OSError: No space left on device`エラーが発生します。
* **TensorRTエンジンビルド/サービング**: 大容量の中間アーティファクトやIPCバッファとして共有メモリを大きく使用し、不足するとエンジンビルドの失敗やセグメンテーション違反が発生する可能性があります。
* **マルチプロセッシングおよびIPC通信**: NCCL、OpenCV、NumPyなどでプロセス間の大容量配列/バッファ共有に不可欠です。

---

## 2. ipc設定: 共有メモリの分離範囲 {#sec-6d4d31fe3ee4}


**IPC (Inter-Process Communication) namespace**は、コンテナのプロセス間通信空間（共有メモリ、セマフォなど）をどの範囲で分離するかを決定するDockerオプションです。

| **ipc設定** | **動作方式** | **/dev/shmサイズ決定** |
| --- | --- | --- |
| **デフォルト (省略)** | コンテナ**自身のIPCネームスペース**を使用 (分離) | `shm_size`で指定されたサイズ (デフォルト値**64MB**) |
| **`ipc: host`** | コンテナが**ホストのIPCネームスペース**を共有 | **ホストの`/dev/shm`サイズ** (一般的にRAMの半分) |
| **`ipc: container:<ID>`** | 指定した他のコンテナとIPCを共有 | 共有対象コンテナの設定に従う |

---

## 3. shm_sizeとipc: hostを同時に使用した場合の動作原理 (例による分析) {#sec-77e6ca4c4b62}


一般的に、AI/LLMタスクでは`shm_size: "16g"`と`ipc: host`を一緒に設定するケースが多く見られます。この際、どの設定が適用されるのかを実際の例を通して見ていきましょう。

### テスト: `ipc: host`使用時の確認結果 {#sec-f473e8607f63}

以下のように`shm_size`と`ipc: host`を一緒に設定しました。

```yaml
shm_size: "16g"
ipc: host
```

そして、コンテナ内部に入り、/dev/shmのサイズを確認しました。

```bash
~$df -h /dev/shm
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            60G  8.3M   60G   1% /dev/shm
```

**観察結果**: shm_sizeに設定した16GBではなく、ホストの/dev/shmサイズである60GBが表示されます。

> **結論: `ipc: host`は`shm_size`を無視します。**

**なぜこのような結果に？**

1.  **`ipc: host`が適用されると:** コンテナは**ホストのIPCネームスペース**をそのまま使用します。
2.  **`shm_size: "16g"`は無視されます:** このオプションは**自身のIPCネームスペース**を使用する場合にのみ意味を持ちます。
3.  **60Gの出所:** ホストのLinuxシステムでは、デフォルトで`/dev/shm`を**全体のRAMの半分程度**に設定していることがよくあります。したがって、上記の例では、コンテナはホストの120Gのうち半分である60Gをそのまま参照していることになります。

**再度強調します**

> **`ipc: host`を設定すると、コンテナはホストの共有メモリ空間をそのまま使用するため、`shm_size`の設定は実際には適用されません。**

---

## 4. 環境と目的に合わせてメモリ運用方法を選択しよう {#sec-d62a63904765}


### 安定性重視 vs コンテナごとの分離 {#sec-870976b9ffe0}

#### 1. 安定性優先: `ipc: host`を維持

最も手軽な方法です。ホストの豊富なRAMリソースをそのまま利用します。複数のコンテナがリソースを共有しても問題ない、単一ユーザー/単一プロジェクト環境に適しています。**ホストの50%使用というのは最大値に過ぎず、実際に使用された量だけがRAMを占有する**ため、メモリの圧迫がないのであれば、このままにしておくのが便利です。

*   **設定**: `ipc: host`のみを維持 (多くの例で`shm_size`が一緒に見られますが、意味がないためshm_sizeは思い切って削除しましょう。)
*   **結果**: ホストの十分な`/dev/shm`サイズを使用します (例: 60G)。

#### 2. コンテナごとの上限を強制: `ipc: host`を削除

マルチテナント環境や、特定のコンテナがRAMを過度に占有するのを防ぐ必要がある場合に使用します。

*   **設定**: `ipc: host`を**削除** + `shm_size: "8g"`または`"16g"`を明示
*   **結果**: コンテナ専用の16GB `/dev/shm`が作成されます。
*   **利点**: 複数のコンテナが稼働する際に、**各コンテナの共有メモリ使用上限**を明確に制限し、ホストRAMの保護と分離が可能。

### 参考: ホスト共有メモリのサイズ調整方法 (ipc:host使用時) {#sec-5e365d4f36e8}


`ipc: host`を使用しながらホストの`/dev/shm`サイズ自体を変更したい場合は、`tmpfs`設定を変更する必要があります。

1.  **一時的にサイズを変更 (再起動時に元に戻る):**

```
sudo mount -o remount,size=16G /dev/shm
```

すべてのプロセス/コンテナに即座に適用されます。


2.  **永続的にサイズを変更 (`/etc/fstab`を修正):**

```
# /etc/fstabファイルに次の行を追加/修正
tmpfs /dev/shm tmpfs defaults,size=16G 0 0
```

保存後に再起動するか、上記の`remount`コマンドで即座に適用します。