It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

Ядро делает The Right Thing™ , веря в это. Зачем ему хранить неиспользуемую ¹ память в ОЗУ и, по сути, тратить ее впустую, вместо того, чтобы использовать ее в качестве кеша или чего-то еще?

Я не думаю, что ядро ​​Linux безвозмездно или упреждающе подкачивает страницы, так что если оно это делает, то должно сохранять что-то еще в ОЗУ, тем самым повышая производительность вашей длительной задачи, или, по крайней мере, с этой целью.

Если вы заранее знаете, когда вам потребуется повторно использовать ноутбук, вы можете использовать команду at(или crontab), чтобы запланировать очистку подкачки(swapoff -a;swapon -a).

Поскольку очистка подкачки может быть излишней и даже вызвать убийцу OOM, если по какой-то причине не все помещается в ОЗУ, вы можете просто «отменить подкачку» ² все, что связано с запущенными приложениями, которые вы хотите удалить. возродить.

Один из способов сделать это — подключить отладчик, подобный gdb, к каждому затронутому процессу и вызвать создание дампа памяти:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

Как вы писали, ваше продолжительное приложение не использует повторно данные, которые оно считывает после начального прохода, поэтому вы находитесь в конкретном случае, когда долгосрочное кэширование бесполезно. Тогда обход кеша с помощью прямого ввода-вывода, как предложил Уилл Кроуфорд, должен быть хорошим обходным путем.

Кроме того, вы можете просто регулярно очищать файловый кеш, выводя 1или 3в /proc/sys/vm/drop_cachesпсевдо--файл, прежде чем ОС сочтет хорошей идеей поменять местами приложения и среду с графическим интерфейсом.

См.Как очистить буферы и кеш в системе Linux?для получения подробной информации.

¹_{Неиспользуемый в смысле :более активно не используемый в течение значительного периода времени, память по-прежнему актуальна для своих владельцев.}
²_{Вернуть в ОЗУ страницы, хранящиеся в области подкачки.}

Вот идея, которую я сам не пробовал (и мне жаль, что у меня сейчас нет времени поэкспериментировать с этим ).

Предположим, вы создаете небольшую виртуальную машину только с 512 МБ памяти для фонового процесса. Я не уверен, что вы хотите, чтобы она имела какой-либо своп, ваш вызов и отключала своп в вашей хост-системе.

Удалите подкачку или уменьшите ее примерно на 20%(может варьироваться в зависимости от системы ), так как в последнее время ОС больше не используют подкачку так же, как в последние несколько лет. Возможно, это ответит на некоторые ваши вопросы:

--> официальный сайт redhat.com

часть информации о Red Hat ниже,

In the past, some application vendors recommended swap of a size equal to the RAM, or even twice the RAM. Now let us imagine the above-mentioned system with 2GB of RAM and 2GB of swap. A database on the system was by mistake configured for a system with 5GB of RAM. Once the physical memory is used up, swap gets used. As the swap disk is much slower than RAM, the performance goes down, and thrashing occurs. At this point, even logins into the system might become impossible. As more and more memory gets written to, eventually both physical- and swap memory are completely exhausted and the OOM killer kicks in, killing one or more processes. In our case, quite a lot of swap is available, so the time of poor performance is long.

и

https://wiki.debian.org/Swap

часть ссылки Debian выше,

Information and considerations related to the amount of swap to use:

"The recommended amount of swap space has traditionally been double the amount of system memory. This has changed over time to one and half times system memory, both answers are decent baselines but are becoming less and less useful answers to the question as time passes. There are many variables about your system and intended use that will determine the available system swap you will want to have."

Вы можете попробовать:

«Лучший способ отключить подкачку в Linux»

Поскольку у меня 6 ГБ ОЗУ и во всех моих последних ОС Linux. Я никогда не видел никаких указаний на использование Swap. Я решил, что долженотключить егоиз-за свободного места (еще на несколько гигабайт )и потому, что иногда это замедляло работу моей системы.

Одно исправление состоит в том, чтобы убедиться, что контроллер контрольной группы памяти включен (Я думаю, что он включен по умолчанию даже в половине -последних ядер, в противном случае вам нужно будет добавить cgroup_enable=memoryв командную строку ядра )]. Затем вы можете запустить задачу с интенсивным вводом-выводом в контрольной группе с ограничением памяти, что также ограничивает объем кеша, который она может потреблять.

Если вы используете systemd, вы можете установить +MemoryAccounting=yesи MemoryHigh/ MemoryMaxилиMemoryLimit(в зависимости от того, используете ли вы cgroup v1 или v2 )в модуле или срезе содержащий его. Если это слайс, вы можете использовать systemd-runдля запуска программы в слайсе.

Полный пример запуска Firefox с ограничением памяти из одной из моих систем. Обратите внимание, что здесь используется cgroups v2, и он настроен как мой пользователь, а не root (. Одним из преимуществ v2 по сравнению с v1 является то, что делегирование этого не -root безопасно, поэтому systemd делает это ).

$ systemctl --user cat mozilla.slice 
# /home/anthony/.config/systemd/user/mozilla.slice
[Unit]
Description=Slice for Mozilla apps
Before=slices.target

[Slice]
MemoryAccounting=yes
MemoryHigh=5G
MemoryMax=6G

$ systemd-run --user --slice mozilla.slice --scope -- /usr/bin/firefox &
$ systemd-run --user --slice mozilla.slice --scope -- /usr/bin/thunderbird &

Я обнаружил, что для того, чтобы заставить пользователя работать, мне пришлось использовать слайс. Первая система работает, просто поместив параметры в файл службы (или используя systemctl set-propertyв службе ).

Вот пример службы (, использующей cgroup v1 ), обратите внимание на две последние строки. Это часть экземпляра системы (pid=1 ).

[Unit]
Description=mount S3QL filesystem
Requires=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=forking
User=s3ql-user
Group=s3ql-user
LimitNOFILE=20000
ExecStartPre=+/bin/sh -c 'printf "S3QL_CACHE_SIZE=%%i\n" $(stat -c "%%a*%%S*.90/1024" -f /srv/s3ql-cache/ | bc) > /run/local-s3ql-env'
ExecStartPre=/usr/bin/fsck.s3ql  --cachedir /srv/s3ql-cache/fs1 --authfile /etc/s3ql-authinfo  --log none «REDACTED»
EnvironmentFile=-/run/local-s3ql-env
ExecStart=/usr/bin/mount.s3ql --keep-cache --cachedir /srv/s3ql-cache/fs1 --authfile /etc/s3ql-authinfo --cachesize ${S3QL_CACHE_SIZE} --threads 4
ExecStop=/usr/bin/umount.s3ql /mnt/S3QL/
TimeoutStopSec=2m
MemoryAccounting=yes
MemoryLimit=1G

Документация находится в systemd.resource-control(5).

Процесс, который вы запускаете, создан вами самостоятельно?

Если это так, возможно, стоит изменить ваш код, чтобы открывать файлы с помощью флага O_DIRECT, который цитируется на странице руководства -

Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user-space buffers. The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT. See NOTES below for further discussion.