В этом материале
Наличие swap на хосте не означает, что контейнеру разрешено его использовать. Проверьте настройки памяти runtime и memory.swap.max действующей cgroup. Swap относится к системным страницам памяти; он не превращается в дополнительную VRAM и не заменяет модельный offload.
Наличие swap на хосте не означает, что контейнеру разрешено его использовать. Проверьте настройки памяти runtime и memory.swap.max действующей cgroup. Swap относится к системным страницам памяти; он не превращается в дополнительную VRAM и не заменяет модельный offload.
Сопоставьте два представления
Сохраните host swap capacity и текущий расход, затем отдельно изучите memory.current, memory.swap.current, memory.max и memory.swap.max контейнера. Убедитесь, что используется cgroup v2: имена и семантика файлов зависят от версии иерархии. Команда внутри контейнера может показывать характеристики хоста без его фактических разрешений для workload. Поэтому один вывод free не доказывает доступность swap конкретному процессу. Проверьте также границы родительской cgroup.
Прочитайте параметры Docker буквально
Docker memory и memory-swap имеют документированную взаимосвязь: memory-swap описывает общий разрешённый объём RAM и swap при заданном memory limit. Нулевое, отсутствующее и специальное отрицательное значение нельзя считать взаимозаменяемыми без проверки документации runtime. В cgroup v2 memory.swap.max отдельно ограничивает использование swap. Сопоставляйте эти уровни по фактическим файлам после запуска, а не только по имени опции в интерфейсе облачного сервиса.
Разберите ограниченный пример
В учебном запуске memory равен 4 GiB, а memory-swap — 4 GiB. В таком сочетании дополнительный swap бюджет не предоставлен. Изменение второго значения до 6 GiB задаёт иной общий предел при наличии swap на хосте и поддержке runtime. Эти числа объясняют семантику параметров и не рекомендуют переносить рабочую нагрузку модели в swap. Реальная задержка зависит от доступа к страницам и окружающей среды.
| Поле отчёта | Что оно подтверждает |
|---|---|
| Host swap | Ресурс существует на узле |
| Runtime settings | Запрошенная политика запуска |
| memory.swap.max | Применённая граница cgroup |
| memory.swap.current | Фактический расход в момент наблюдения |
Выберите поведение при давлении
Сначала оцените нормальный рабочий набор RAM и допустимость задержек. Использование swap может позволить пережить отдельные всплески, но не гарантирует устойчивую обработку при постоянном дефиците. Memory pressure и reclaim способны ухудшить время ответа раньше OOM. Согласуйте бюджет на общем узле: расход одного контейнера конкурирует с другими процессами. Не меняйте глобальную swap policy только ради одного симптома без оценки влияния на всю систему.
Проверьте повторный запуск и задержки
После изменения декларативной конфигурации пересоздайте тестовый контейнер и перечитайте эффективные границы. Повторите тот же входной набор, сохранив memory pressure, swap usage, длительность и события OOM. Успех определяется пригодным поведением приложения, а не ненулевым расходом swap. Сохраните в артефакте версии runtime/kernel и ограничения предков. Если GPU по-прежнему сообщает нехватку памяти устройства, вернитесь к VRAM и параметрам модели: системный swap не является исправлением этой отдельной ошибки.
Показатели swap следует сохранять вместе со scope наблюдения. Общая активность узла может расти из-за другого workload, поэтому совпадение во времени ещё не подтверждает использование swap именно исследуемым контейнером.
Связанные разборы: memory optimized hosting; ram vs vram.