我遇到了一个奇怪的问题，即在mesos从属服务器（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\u延迟调整为零并重新启动mesos slave）？
1条答案
按热度按时间lztngnrs1#
你在用什么框架？也许你需要设置
-gc_non_executor_container_sandboxes一个新的--gc_non_executor_container_sandboxes代理标志已添加到垃圾收集嵌套容器的沙盒中，其中包括由默认执行器启动的任务组。如果您的框架在同一个默认executor示例上启动多个任务组，建议启用该标志。