Вы можете найти некоторую помощь на вики-странице ArchLinux , на которой обсуждается настройка среды для пользовательских модулей. В частности,
systemctl --user import-environment
экспортирует все текущие переменные среды в пользовательскую среду systemd. Вместо этого вы можете предоставить явный список переменных. Вы можете проверить, запустив
systemctl --user show-environment
до и после. Также есть
systemctl --user set-environment MYVAR=myvalue...
systemctl --user unset-environment MYVAR...
См. справочную страницу systemctl
. В вики также упоминается специфическая альтернатива dbus, с которой я не добился большего успеха :
.
dbus-update-activation-environment --systemd --all
Committed_AS
больше, чем MemTotal
, так что вы в конечном итоге выгрузите страницу. Когда пороговое значение достигнуто, восстановление памяти приведет к удалению некоторых кешей, выгрузке некоторых из них на диск и аналогичным действиям.
Если вам не нравится такое поведение восстановления, добавьте больше оперативной памяти.
«Утечка памяти» в программе или ядре, которое фактически теряет след выделенной памяти, является серьезным заявлением. Пожалуйста, не путайте поведение восстановления с утечками, обнаруженными с помощью таких инструментов, как Valgrind или LeakSanitizer.
Имейте в виду, что я в основном работаю с системами, основанными на BSD. Но, как я вижу, ваша ситуация очень похожа. Мне кажется, ваши данные работают «как задумано». Память предпочтительнее подкачки, потому что она бесконечно быстрее. Таким образом, ваша система делает все возможное, чтобы управлять этой памятью, и только разрешать приложениям использовать ее, как система считает нужным --, а не приложение.IOW ваша система потребляет память, поэтому она может выступать посредником в этом ресурсе так, как она считает нужным. Не наоборот.
Теперь я могу добавить. Это если вы не одобряете этого. У вас действительно есть возможность «настроить» ваше ядро, чтобы изменить его поведение по своему вкусу. Но, честно говоря; это выглядит хорошо для меня.
ХТХ