Hi there,
We’ve had an Octopus installation running for several years now, and we’re getting to the stage where our ServerTasks (83k) and Events (143k) seem huge compared to the other indexes we have. Even deployments (43k) is pretty hefty.
Is there any way of applying a retention policy or something to these indexes? Or should we just not be concerned and carry on as normal? I get the feeling that these are loaded into memory in some way, so it’d be nice to reduce that footprint.
Thanks,
Stu
Hi Stu,
Thanks for getting in touch! What version of Octopus are you using? (I am going to assume 2.x).
Are you planning on upgrading to 3.x in the future? Do you use our server retention policies? If so what are they set to?
Are you noticing any Octopus Server performance issues?
Vanessa
Hi Vanessa,
Sorry for not replying earlier.
We’re on version 2.5.10.567. We’re not planning to upgrade as it adds significant functionality that we don’t require.
We’re using retention policies in Octopus, but only at the Project level - I’ve not seen a way of doing it at a server level. This removes releases etc, but not the ServerTasks or Events that we’ve seen build up.
Although we don’t see any performance issues while the system is up, we did have a problem when we had to re-index, it took hours. Reducing the size of the backup would also be awesome 
I did try deleting the documents directly from RavenDB but it really didn’t like that…
Any help is appreciated,
Stu
Hi Stu,
Yeah Raven doesn’t like those kinds of deletions plus you can potentially break your interface if you delete records that are linked.
For that version, if you do not want to upgrade (the ServerTasks are deleted as part of the retention policies in 3.x) your best option would be to create your own API script that determines any ServerTasks that are not matched to existing releases and deployments.
The Events table is different - it is your audit data, and while it has links to other data, nothing links to it, so it can be deleted with more abandon. But due to Raven you can only delete a few hundred records at a time, and slowly. Your service will have to be stopped when you perform this.
Upgrading to at least 2.6 will help with the ServerTasks (but not the currently orphaned ones) as it has a superior retention policy system linked via Lifecycles. There will come a time where we cannot support Raven growth issues as this is a factor to why 3.x was designed with SQL Server. You are doing amazingly well as generally around the 70k mark of total documents Octopus has performance issues, but it does depend on the use.
The indexes themselves are not part of the backup, only the documents themselves.
I have also attached a screenshot of a query you can do in Raven. These are safe documents to delete that are only used while a deployment is running and then never used again. They are cleaned up in 3.x also.
Hopefully this will give you some breathing room.
Vanessa
