Регистрация всех выходных данных crontab с помощью MAILTO
«Синхронизация» не уменьшит бафф/кэш, она просто запрашивает передачу данных на блочные устройства. Суть кеша в том, что данные остаются в кешах оперативной памяти. Отправка 3 для сброса кэшей _также не требует отбрасывания кэшей. Не могли бы вы добавить «сон 60» перед «бесплатно»? Это может дать некоторое время для очистки памяти перед сообщением о свободе.
Оставление «watch -n60 cat /proc/meminfo» может помочь показать растущую область памяти, но кеш и бафф — это не только утечки, потребляя память, они выполняют свою задачу и делают все возможное. использование доступных ресурсов вашей системы.
Если процесс выгружается на диск, это не означает автоматически, что произошло что-то плохое. Ядро поступает правильно, если этот процесс не использует все свои страницы и простаивает, есть реальная вероятность того, что на веб-сервере содержимое в корне www понадобится до того, как копия mutt останется запущенной в Например, экран GNU, когда пользователь вышел из системы.
Если вы по-прежнему считаете, что ядро потребляет оперативную память через модули, вы можете проверить это еще немного, используя:
awk '{ print $2" "$1 }' /proc/modules | sort -n
Вы используете ZFS? Это довольно прожорливо для ОЗУ, но, как и кеш, он пытается сохранить дисковый ввод-вывод в ОЗУ на тот случай, если это необходимо.
Вместо попытки использовать MAILTO(, который всегда будет интерпретироваться как адрес электронной почты ), используйте SHELL.
Задайте SHELLпуть к небольшому исполняемому сценарию оболочки, который запускает данную команду с выводом, направленным в файл:
#!/bin/sh
now=$(date)
/bin/sh "$@" 2>&1 | awk -v now="$now" '{ printf("[%s]\t%s\n", now, $0) }' >/tmp/cronjob.log
Здесь "$@"будет расширен до -c, за которым следует спецификация задания из файла crontab. Важно писать "$@"в двойных кавычках.
В crontab используйте
SHELL=/path/to/cronrun
# rest of crontab below...
(при условии, что /path/to/cronrun— правильный путь к этому короткому скрипту)