We have over 400,000 files in our C:\Octopus\TaskLogs directory going back to task that our instance performed 3 or 4 years go.
Is there a setting to adjust the retention policy on this data?
Thx
Hi Casey,
Retention Policies on your lifecycles will clean up these tasklogs when the associated release is cleaned up. Depending on your current version, we did add some additional cleanup for system task logs, as noted in in the following:
I hope this helps, and please don’t hesitate to reach out if you have any further questions.
We are running 2020.1.15 and I am seeing task logs back to 2016 like some of the other commenters.
It looks like these task aren’t getting cleaned up like mentioned in Old tasks not being cleaned up · Issue #6065 · OctopusDeploy/Issues · GitHub.
We are running a fairly old license and are limited to only one, default, space. I don’t know what table to look at in the DB to see if there is a null value in the column for the task.
Edit: Looking at
SELECT *
FROM [OctopusDeploy].[dbo].[ServerTask]
WHERE SpaceId is null
I see 818 rows where I have a null value for my spaceid.
If I look at the entirety of the table,
SELECT count(*)
FROM [OctopusDeploy].[dbo].[ServerTask]
I get roughly the 400k files that I see in this directory. While we do a lot of deployments I think something isn’t right the retention policy and our lifecycles which are all set to only keep 10 builds worth of information.
Interesting, apologies in advance for the somewhat newbie-level question - but I just wanted to confirm that the following setting is set on all of your lifecycles:
It also may pay to scroll down further to the Phase setting see if there are any phase-specific overrides that might over-ride the lifecycle-wide policy.
Let me know how this goes for you, and if you have any further questions.
Yea, we have it set to 10 releases for every lifecycle in Library --> Lifecycles -->
Where do I see the phase specific over-rides?
EDIT: NM. on phase specific overrides you were meaning the phases of the lifecycle. I found a few overrides, but they were always to keep fewer builds, not more. I went ahead and reset them because we wanted a different number across the board.
Hi @casey.daniell!
That’s good news that you sorted out the phase-specific retention. Looking into this some more, I wonder if it’s stemming from the addition of the spaces feature and how that impacted deployments from pre-spaces. I’ll keep digging into this on my end, but you should be fine to manually prune those files if they’re imposing a system resource issue for you.
I don’t know that I consider this solved, but we did find those phase-specific retention policies, which were the same, or less than, the normal policies. I am sure there is a reason to keep all these results in small text files, but IMHO it seems like having these in the DB makes it better. Right now I have 300k tiny files (mostly 1KB) chewing up disk space, which isn’t an efficient use of space. Furthermore, I can’t really do an easy left join to see what files are extra and not in the DB. It’s going to be a custom Powershell script to look up each file in the DB and decide to keep or delete it. Not hard to accomplish, but more work than it should be.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.