Hi Benjamin,
Apologies for the delay. GC seem be working fine. Folders older than 2 hours
are being deleted. After change of config and restart, Mesos agent took some
time to delete the old folder that are around before the restart. I may have
jumped the gun.
Thanks,
Venkat
> On Oct 30,
Hi Venkat,
You're seeing that files with a modification time greater than your gc
delay of 2 hours are *not* getting deleted? Can you show a full
listing of /var/lib/mesos/slave/slaves/?
Is there more than 1 entry there?
On Fri, Oct 27, 2017 at 8:43 AM, Venkat Morampudi
Hi Tomek,
After changing GC delay to 2hrs, the existing sandbox folders that are older
than the “Max allowed age” are not deleted. Here are the logs
Logs entire before and after the change:
I1027 15:00:48.055465 12861 slave.cpp:4615] Current disk usage 21.63%. Max
allowed age:
Low GC delay menas files will be deleted more often. I don't' think there
will be any performance problem but low GC means you will lose your
sandboxes earlier and they are useful for debugging purposes.
pt., 27 paź 2017 o 04:40 użytkownik Venkat Morampudi <
venkatmoramp...@gmail.com> napisał:
>
Hi Tomek,
Thanks for the quick reply. After digging a bit into Mesos code we were able
understand that age actually mean threshold age. Anything older than the “age"
would be GCed. We are going to try different setting starting with
"--gc_disk_headroom=.2 --gc_delay=2hrs”. Is there any
> gc_delay * max(0.0, (1.0 - gc_disk_headroom - disk usage))
*Example:*
gc_delay = 7days
gc_disk_headroom = 0.1
disk_usage = 0.8
7 * max(0.0, 1 - 0.1 - 0.8) = 7 * max(0.0, 0.1) = 0.7 days = 16 h 48 min
Can you show some logs containging information about GC?
pt., 27 paź 2017 o 00:43 użytkownik
Hello,
In our production env, we noticed that our disk filled up because one framework
had a lot of failed/completed executors folders laying around.
The folders eventually filled up the disk.
228M
