Я столкнулся со странной проблемой с потенциально сломанной сборкой мусора устаревших фреймворков на mesos slaves ( 1.9.0-2.0.1.debian8 ).
В соответствии с документацией устаревшие платформы должны автоматически удаляться, если к ним не обращались в течение предопределенного периода времени, однако, хотя в журнале ведомого устройства я мог видеть, что ведомому серверу не хватает памяти, все еще существуют папки инфраструктуры, датированные более чем недельной давностью.
У меня установлены следующие значения для сборки мусора:
--disk_watch_interval="1mins"
--gc_delay="2days"
--gc_disk_headroom="0.2"
$ date
Thu Nov 7 13:32:50 UTC 2019
$ tail -20 /srv/mesos/agent/logs/mesos-slave.INFO |grep 'Max allowed'
I1107 13:32:33.576203 27465 slave.cpp:7406] Current disk usage 71.83%. Max allowed age: 3.923527125292778hrs
$ ls -l --time=atime /srv/mesos/agent/slaves/bcb34071-9fd8-481a-8d0c-767ef0628216-S2/frameworks/ |grep Oct|tail -5
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0004
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0005
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0007
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0008
drwxr-xr-x 3 root root 4096 Oct 28 12:23 fbf26a3e-bb25-4f8f-b9fa-d089c46f7ebd-0009
Любая идея по причине, которая может возникнуть, и способ принудительного сбора мусора (кроме настройки нуля gc_delay и перезапускамесос раб)?