> 본문요약 :   
>  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**는 컨테이너의 프로세스 간 통신 공간(공유 메모리, 세마포어 등)을 어떤 범위로 격리할지 정하는 도커 옵션입니다.

| **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의 출처:** 호스트 리눅스 시스템은 기본적으로 `/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` 명령어로 즉시 적용합니다.