Orchestrator using 85GB of disk space

Help Orchestrator
,
1

Our on-prem Orchestrator has grown to use 85GB of space on the Orchestrator web server. This is unsustainable. I suspect the culprit is error screenshots. How can their retention be managed? Is the only option manual deletion or is there a management process that can be configured?

2

Check this Maintenance considerations documentation Maintenance Considerations

3

Thanks though that’s all SQL maintenance and not something that will save me disk space.

4

Hi @Craig1 ,

delete the unwanted old logs its may occupy more space in derive

image
image681×542 11.8 KB

Regards,
Arivu

5

That deletes them from the database, which doesn’t have anything to do with the web server Orchestrator runs on.

6

Exactly. I’m not sure how to be more clear. This has nothing to do with the database. Orchestrator is using nearly 100GB of disk space on the Orchestrator web server.

7

Have you determined what the files are that are taking up that space?

8

Hi @Craig1 ,
I do not have any experience with on-prem Orchestrator, but 2 things come to my mind -

  • Storage Buckets - Are your processes using a lot of files in the storage buckets?

  • Multiple processes with different versions - I have been facing an issue of disk space utilization because my .nuget folder has become too large (since there are multiple processes and each process has multiple versions and each version has dependency on packages which are stored directly in the .nuget folder). Can you check if there is a similar storage structure for on-prem orchestrator when it comes to storing processes and their dependencies? (I had raised this issue earlier as well - Nuget folder suggestions)

9

This is relevant to the servers where you’re running the automations, not for the Orchestrator server itself.

10

Yep. Thought so. Thanks @postwick

Would still like to understand how packages are stored on an on-prem Orchestrator.

Storage buckets might still be causing issues - Storage buckets - how it works? - #5 by sonaliaggarwal47

Processes might not be storing data explicitly but might be moving from Action Center

11

I am not using storage buckets at all.

What I’m hearing is that disk space usage by Orchestrator can grow in an uncontrolled manner and there are no tools made available to manage it.

12

I’ve confirmed it’s the screen captures, which are stored in Orchestrator/Storage/Orchestrator-{guid}/ExecutionMedia/Robot-n/ and then many {guid} folders each containing a ScreenCapture.zip. What I would like to know is will I break anything in Orchestrator if I just go ahead and delete ones older than, say, this year?

13

Nothing will break if you delete old screenshots, apart from getting an error when you find the old job that generated them and trying to view the screenshots.

14

Hi @CosminV thanks for confirming. I’ll go ahead and delete some old ones and free up some space.

It would be nice if a disk space usage / cleanup guide was somewhere in the documentation.

1 Like
15

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.