Revision Ver-2

本文の要約：
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) を徹底解説

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

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

shm_sizeとipc方式の比較画像

1. shm_sizeの役割と重要性

役割: コンテナの共有メモリサイズを決定

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

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

なぜ重要なのか？

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

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

2. ipc設定: 共有メモリの分離範囲

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を同時に使用した場合の動作原理 (例による分析)

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

テスト: `ipc: host`使用時の確認結果

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

shm_size: "16g"
ipc: host

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

~$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を無視します。

なぜこのような結果に？

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

再度強調します

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

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

安定性重視 vs コンテナごとの分離

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使用時)

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

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

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

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

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

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

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