32 МБ свободной памяти, а утилите нужно 64 МБ. Разбираемся

Утилита может и запуститься, и успешно отработать. Но по этим двум числам однозначного ответа нет.

На собеседовании надо начать с уточнений:
— 32 МБ — это значение free или available?
— 64 МБ утилита запрашивает у ОС или действительно использует для своих данных?
— Есть ли swap и сколько в нём свободного места?
— Есть ли ограничения памяти у процесса или контейнера?

Допустим, открываем free -m, а там: free — 32 МиБ, available — 300 МиБ.

Linux использует оперативку в том числе под файловый кэш. Часть этой памяти ядро может освободить для приложения. Поэтому маленькое значение free само по себе ещё не говорит о нехватке памяти.

Для первой оценки смотрим на available: сколько памяти предположительно доступно приложениям без подкачки.

1. Запуститься утилита может, даже если доступной памяти меньше 64 МБ.

Ей необязательно занимать все 64 МБ RAM сразу после старта.

Например, программа запросила через malloc буфер на 64 МБ, но записала данные только в небольшую его часть. Физические страницы под остальную часть могут выделяться позже, по мере записи.

Или есть overcommit: политика, при которой Linux может разрешать запросы памяти, даже если обеспечить все такие запросы одновременно не получится.

Это разные механизмы. Ленивое выделение позволяет предоставлять физические страницы по мере необходимости. Политика overcommit определяет, какие обязательства по памяти ядро разрешает принимать.

Но запуск сам по себе не гарантирован, потому что память нужна уже при старте, а её выделение могут ограничивать настройки системы и лимиты процесса.

Отказать могут и при запросе буфера: например, malloc вернёт NULL с ошибкой ENOMEM. Дальше всё зависит от программы: она может обработать отказ, сократить объём работы или завершиться.

2. Успешный запуск и успешный запрос памяти ещё не гарантируют дальнейшую работу.

Предположим, запрос прошёл, утилита начала заполнять буфер. Теперь для данных нужны реальные физические страницы.

Если ядро сможет освободить достаточно памяти, например за счёт кэша, утилита продолжит работу.

Если есть доступный и разрешённый для процесса swap, часть страниц можно вытеснить туда и освободить RAM. Причём вытесняться могут страницы других процессов.

Дальше важен характер нагрузки. Если вытеснили редко используемые данные, влияние на скорость может быть небольшим. Если приходится постоянно возвращать страницы из swap и вытеснять другие, производительность может сильно упасть.

Если получить достаточно памяти не удаётся, возможен OOM. Ядро может завершить процесс, чтобы освободить память. При общесистемном OOM жертвой необязательно станет наша утилита.

Уже завершившийся успешный вызов malloc задним числом ошибку не вернёт, так как нехватка памяти при заполнении буфера — это уже другой этап.

Отдельно проверяем лимиты контейнера или сервиса. Процесс может упереться в ограничение своей cgroup, даже когда на хосте ещё есть свободная RAM.

Если же условие строгое, то утилите нужны дополнительные 64 МБ одновременно в RAM, предоставить можно только 32 МБ и освободить больше нечего, значит выполнить это требование она не сможет. Overcommit дополнительную оперативку не создаёт.

Что проверить командами:

— free -m — значения free, available и состояние swap. Вывод здесь в МиБ.
— swapon --show — какие области swap подключены и насколько заняты.
— sysctl vm.overcommit_memory — политику overcommit.
— ps -o pid,vsz,rss,comm -p PID — виртуальную память процесса и объём, находящийся в RAM. VSZ и RSS здесь выводятся в КиБ.
— vmstat -y 1 — текущую активность подкачки в колонках si и so.
— journalctl -k -b — сообщения ядра, в том числе об OOM.

Для процесса дополнительно смотрим /proc/PID/limits, для контейнера или сервиса — ограничения его cgroup.