У меня есть ноутбук Debian (Buster) с 8 ГБ оперативной памяти и 16 ГБ подкачки. Я выполняю очень долгое задание. Это означает, что мой ноутбук оставался включенным последние шесть дней, пока он работает.

При этом мне периодически нужно использовать свой ноутбук как ноутбук. Это не должно быть проблемой; долгосрочное задание связано с вводом / выводом, работает через что-то на жестком диске USB и не занимает много ОЗУ (<200 МБ) или ЦП (<4%).

Проблема в том, что когда я вернусь к своему ноутбуку через несколько часов, он будет очень вялым и может занять 30 минут, чтобы вернуться в нормальное состояние. Это настолько плохо, что краш-мониторы помечают свои приложения как замороженные (особенно окна браузера), и все начинает некорректно падать.

Если посмотреть на системный монитор, то из 2,5 ГБ, используемых примерно наполовину, происходит свопинг. Я подтвердил, что это проблема, удалив пространство подкачки ( swapoff /dev/sda8). Если я оставлю это без пространства подкачки, оно вернется к жизни почти мгновенно, даже через 24 часа. Со свопом это практически кирпич за первые пять минут, оставленный всего на шесть часов. Я подтвердил, что использование памяти никогда не превышает 3 ГБ, даже когда я в отъезде.

Я попытался уменьшить swappiness ( см. Также: Википедия ) до значений 10и 0, но проблема все еще сохраняется. Похоже, что после дня бездействия ядро ​​считает, что весь графический интерфейс больше не нужен, и стирает его из оперативной памяти (подменяет его на диск). Долгосрочная задача - чтение огромного файлового дерева и чтение каждого файла. Так что ядро ​​может запутаться, думая, что кеширование поможет. Но на одном жестком диске объемом 2 ТБ USB HD с ~ 1 млрд. Имен файлов дополнительная ГБ ОЗУ не сильно повысит производительность. Это дешевый ноутбук с вялым жестким диском. Он просто не может загрузить данные обратно в оперативную память достаточно быстро.

Как я могу сказать Linux использовать пространство подкачки только в чрезвычайной ситуации? Я не хочу бежать без свопа. Если происходит что-то неожиданное, и ОС внезапно требуется несколько дополнительных ГБ, тогда я не хочу, чтобы задачи убивались, и предпочел бы начать использовать swap. Но в данный момент, если я оставлю swap включенным, мой ноутбук просто не сможет быть использован, когда мне это нужно.

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

Что такое чрезвычайная ситуация? - Тебе правда нужно спросить? ... Надеюсь, ты никогда не окажешься в горящем здании!

Я не могу определить все, что может представлять собой чрезвычайную ситуацию в этом вопросе. Но, например, чрезвычайной ситуацией может быть ситуация, когда ядро ​​настолько загружено для памяти, что оно начинает уничтожать процессы с помощью OOM Killer . Чрезвычайная ситуация НЕ возникает, когда ядро ​​считает, что оно может улучшить производительность с помощью свопинга.

Окончательное редактирование: я принял ответ, который делает именно то, что я просил на уровне операционной системы. Будущие читатели также должны принять к сведению ответы, предлагающие решения на уровне приложений.

В наше время такой огромный обмен часто является плохой идеей. К тому времени, когда ОС поменяла местами всего несколько ГБ памяти, ваша система уже ползла до смерти (как вы видели)

Лучше использовать zramс небольшим резервным разделом подкачки . Многие операционные системы, такие как ChromeOS, Android и различные дистрибутивы Linux, позволяют zram по умолчанию годами, особенно для систем с меньшим объемом оперативной памяти. Это гораздо быстрее, чем подкачка на жестком диске, и в этом случае вы четко чувствуете реакцию системы. Меньше так на SSD, но в соответствии с результатами тестов здесь все еще кажется быстрее даже с алгоритмом lzo по умолчанию. Вы можете перейти на lz4 для еще лучшей производительности с немного меньшей степенью сжатия. Скорость декодирования почти в 5 раз выше, чем у lzo, согласно официальному тесту

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

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

дальнейшее чтение

• https://wiki.debian.org/ZRam
• https://wiki.archlinux.org/index.php/improving_performance#RAM_and_swap
• zram vs zswap vs zcache Конечное руководство: когда использовать какой
• Linux, SSD и своп
• Разница между ZRAM и ZSWAP
• https://www.kernel.org/doc/Documentation/blockdev/zram.txt
• https://wiki.gentoo.org/wiki/Zram

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

Если вы используете 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).

Похоже, что после дня бездействия ядро ​​считает, что весь графический интерфейс больше не нужен, и стирает его из оперативной памяти (подменяет его на диск).

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

Я не думаю, что ядро ​​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псевдо-файла до того , как операционная система считает , что это идея хорошая , чтобы выгрузить ваши GUI приложений и окружающей среды.

Посмотрите, как вы очищаете буферы и кеш в системе Linux? для деталей.

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

Является ли процесс, которым вы управляете, чем-то, что вы создали сами?

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

Постарайтесь минимизировать эффекты кэширования ввода-вывода в этот файл и из него. В целом, это снижает производительность, но полезно в особых ситуациях, например, когда приложения выполняют свое собственное кэширование. Файловый ввод / вывод осуществляется непосредственно в / из буферов пространства пользователя. Флаг O_DIRECT сам по себе пытается передавать данные синхронно, но не дает гарантии флага O_SYNC, что данные и необходимые метаданные передаются. Чтобы гарантировать синхронный ввод-вывод, в дополнение к O_DIRECT необходимо использовать O_SYNC. Смотрите примечания ниже для дальнейшего обсуждения.

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

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

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

-> Официальный redhat.com

некоторая информация о Red Hat ниже,

В прошлом некоторые поставщики приложений рекомендовали подкачку размером, равным ОЗУ, или даже вдвое больше ОЗУ. Теперь давайте представим вышеупомянутую систему с 2 ГБ оперативной памяти и 2 ГБ подкачки. База данных в системе была по ошибке настроена для системы с 5 ГБ ОЗУ. Как только физическая память израсходована, своп используется. Поскольку диск подкачки намного медленнее, чем ОЗУ, производительность снижается, и происходит перегрузка. На этом этапе даже вход в систему может стать невозможным. По мере того, как в память записывается все больше и больше памяти, в конечном итоге физическая память и память подкачки полностью истощаются, и запускается OOM-убийца, убивая один или несколько процессов. В нашем случае доступно довольно много свопов, поэтому время плохой работы очень велико.

а также

https://wiki.debian.org/Swap

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

Информация и соображения, связанные с объемом свопа:

«Рекомендованный объем пространства подкачки традиционно был вдвое больше объема системной памяти. Со временем он изменился в полтора раза, системная память, оба ответа являются приличными базовыми показателями, но с течением времени становятся все менее и менее полезными ответами на вопрос. Существует много переменных в вашей системе и предполагаемом использовании, которые будут определять доступный системный своп, который вы захотите получить ».

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

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

Личная заметка:

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