Заменить память остановленного процесса на файл обмена

Я хочу переместить резидентные/виртуальные данные процесса, получившего сигнал SIGSTOP, из основной памяти в любое подходящее пространство подкачки. С возможностью восстановить процедуру до сигнала SIGCONT, чтобы продолжить выполнение процесса.

В системе нет выделенного пространства подкачки, потому что обычно я не хочу, чтобы данные подкачивались. Поэтому предпочтительнее решение, которое записывает в выделенный файл в файловой системе по моему выбору. Возможно, “подкачка” здесь не совсем корректное слово, но если ничего не сработает, можно установить временное пространство подкачки.

Контекст: программа, которая требует для запуска и завершения и используется периодически, использует не только значительное количество времени процессора в бездействии, но также занимает 60-80% оперативной памяти системы. Команды STOP/CONT хорошо работают для прекращения простоя, и даже выдерживают приостановку системы без проблем, но во время остановки оперативная память системы фактически сокращается до 20-40%.

Использование обычного поведения подкачки в Linux a) требует наличия пространства подкачки, которое обычно не используется за пределами этого конкретного сценария и, что более важно, b) является ненадежным с точки зрения когда происходит подкачка чего. Неправильный процесс может быть выгружен или в момент, когда это неудобно. Вместо этого у меня есть SSD, который может более чем достаточно вместить резидентный набор процесса, даже виртуальный набор. И я хочу контролировать, когда или будет ли происходить подкачка.

Возможные подходы.

• Этот ответ на serverfault предлагает madvise, но нет четкого способа отменить процедуру, так как нет аналога MADV_PAGEOUT.
• Установка конкретного файла в качестве пространства подкачки для процесса, по всей видимости, возможна согласно Иметь приватный файл подкачки на процесс.

В системе нет выделенного пространства подкачки, потому что обычно я не хочу, чтобы данные подкачивались. Поэтому предпочтительнее решение, которое записывает в выделенный файл в файловой системе по моему выбору. Возможно, “подкачка” здесь не совсем корректное слово, но если ничего не сработает, можно установить временное пространство подкачки.

Да, подкачка — это системная вещь 🙂 И, насколько мне известно, вы не можете заставить виртуальную память одного процесса быть выгруженной; приостановленный процесс, однако, будет довольно высоко в списке вещей для выгрузки, поэтому настройка временного пространства подкачки и повышение значения swappiness (sudo sysctl -w vm.swappiness=100), а затем увеличение давления на память (например, с помощью yes | head -c 1G /tmp/tmpfile, предполагая, что /tmp — это точка монтирования tmpfs) в наверняка выгрузит процесс.

Но, честно говоря, ваш случай использования звучит на 100% как CRIU, “Контрольная точка / Восстановление в пространстве пользователя”. Это зрелая технология, которая позволяет просто взять состояние программы, сохранить его на носителе и восстановить позже.

Естественно, это требует, чтобы ни одно из других объектов, с которыми взаимодействовала эта программа, не изменилось непредсказуемым образом (например, сетевые соединения могут разорваться в любой момент, однако большинство программ будет устойчивыми к этому, но ни одна программа не ожидает, что их файл базы данных изменится, пока они были “закатаны”).

Существует довольно простое и общее решение для этого, которое также предоставляет несколько дополнительных преимуществ в вашей ситуации: контейнеры.

Дополнительные преимущества будут заключаться в том, что вы сможете легко ограничить процент времени использования процессора, который может занимать программа, объем оперативной памяти и скорости ввода-вывода на диск и т.д.; среды выполнения контейнеров обычно помещают свои контейнеры в области cgroup, которые позволяют вам указывать такие ограничения.

Я использую podman для контейнеров; podman имеет встроенные функцию сохранения/восстановления на основе CRIU.

# запуск в фоновом режиме
podman run -d --name resourcehog debian:12 sh -c 'apt update; apt install -y stress -c8'

# сохранить состояние на диск, остановить выполнение
podman container checkpoint --create-image resourcehog-frozen-as-hell resourcehog

# позже, восстановить
podman container restore --name resourcehog-continuation resourcehog-frozen-as-hell

Вместо --create-image вы также можете --export в файл tar.gz (по моему опыту, это будет медленнее при экспорте), а затем --import тот же файл при восстановлении.