# Закончился /dev/shm: как задать IPC-бюджет GPU-контейнера

Диагностика: Закончился /dev/shm: как задать IPC-бюджет GPU-контейнера. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/container-dev-shm-ipc-budget/
Language: ru

Переполнение /dev/shm означает проблему конкретного shared-memory mount, а не автоматически нехватку VRAM. Размер IPC-пространства и общий лимит системной памяти проверяют отдельно: увеличение tmpfs может перенести отказ на уровень memory cgroup, если не учесть суммарный бюджет.

## Найдите используемое IPC-пространство

Сохраните настройки --ipc и --shm-size фактически запущенного контейнера. Посмотрите mount /dev/shm из его пространства имён, доступную ёмкость и владельцев файлов. У разных режимов IPC различаются границы совместного использования, поэтому сравнение с /dev/shm хоста может вводить в заблуждение. Зафиксируйте также, передаёт ли приложение shared-memory объекты между дочерними процессами, и какие из них переживают ошибку worker. Не удаляйте чужие активные объекты во время расследования.


[Официальный источник 1](https://docs.docker.com/reference/cli/docker/container/run/).

## Проверьте два бюджета памяти

Docker позволяет задать размер /dev/shm при создании контейнера. В Kubernetes часто используют memory-backed emptyDir для нужного mount. Его страницы учитываются как память, поэтому sizeLimit такого тома не заменяет memory limit приложения. Сопоставьте размер временных данных, память процессов и действующие cgroup границы. Свободная VRAM не компенсирует системные страницы shared memory. Фактическое заполнение mount следует наблюдать во время передачи данных, а не только после аварийного завершения.


[Официальный источник 2](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).

## Соберите пример с повторным использованием

Представим два worker, передающих порции данных через shared memory. После нескольких неудачных запусков объекты остаются, свободное пространство уменьшается, следующая попытка завершается ошибкой. В отдельной тестовой среде сравните успешный цикл и цикл с принудительным завершением дочернего процесса. Важен порядок закрытия и удаления объектов, а не только максимальная ёмкость mount. Этот сценарий иллюстрирует проверку cleanup и не утверждает наличие утечки в конкретной библиотеке.

| Артефакт | Зачем сохранять |
| --- | --- |
| Mount options | Восстановить фактическую IPC-конфигурацию |
| Пик заполнения | Рассчитать временный объём данных |
| Память cgroup | Увидеть суммарный бюджет RAM |
| Объекты после завершения | Проверить корректность очистки |

## Исправьте жизненный цикл и размер

Если обнаружены оставшиеся объекты, сначала исправьте их владельца и cleanup. Затем подберите размер mount по измеренному пику с запасом, сохраняя ограничение общего потребления памяти. Изменение --shm-size требует соответствующего пересоздания контейнера; команда в интерактивной сессии не меняет декларативный запуск. Общий IPC namespace расширяет область взаимодействия процессов, поэтому его применение должно быть осознанным решением, а не универсальным обходом ошибки ёмкости.

## Проверьте повторяемость

Выполните несколько полных циклов запуска, обработки и завершения на одном тестовом наборе. После каждого проверяйте освобождённое пространство и остаточные объекты. Успешный результат включает отсутствие роста остатка и приемлемый пик memory.current. Сохраните описание mount, число worker, размер порции и проверенный cleanup. Если после увеличения mount появились OOMKilled или memory pressure, исследуйте новый предел отдельно: прежняя ошибка IPC могла исчезнуть, а общий бюджет RAM остаться недостаточным.

Связанные разборы: [ram for data preprocessing](/ru/journal/ram-for-data-preprocessing/); [gpu containers vs vms](/ru/journal/gpu-containers-vs-vms/).