v6 Backup Management Server Memory Usage (RAM)

[jkcouch]

Support case - 5162899

As I have previously posted on other threads, I have 1 backup server with around 70ish jobs running on it. There are currently 12 active proxies in virtual mode. The backup server doesn’t process data, it’s simply a management server.

I started this server out with 2 Vcpus and 6gb of ram thinking it would be just fine to handle the load of v6 mgmt for 100 job processes since the load would be on the proxies, and I was very shocked to find out that each job uses roughly 400mb on average for each active job. So in my case I hit 30gb of ram utilization nightly for at least 3 hours while in the heat of backups. I also almost max out 8 Vcpus on the server.

Is this normal for a setup our size?

What has Veeam tested as the theoretical limit on number of jobs/VMs on a single backup server?

What kind of memory consumption have other customers found with v6 running virtual mode with proxies?

We have another 30ish jobs to create and this server, and at this rate it isn’t going to be able to house it like I had hoped (all jobs on one server for easy management).

[Gostev]

400MB per job is normal usage for backup management server in large infrastructures. When the job starts, it caches lots of data (for example, whole vCenter infrastructure) for fast access (because vCenter communications normally takes way too much time to be done "inline"). Just install more RAM in your management server, and you should be able to have 100 jobs. Otherwise, you can always deploy multiple management servers.

I will discuss with development on what can we do to reduce the memory consumption in future versions, as I agree with you that this is an area for improvement.

[jkcouch]

Thank you for explaining that. It makes sense how it caches vcenter information and why that would cause a large ram footprint.

A thought I had was have the backup service cache the information instead of the job. I think we could see other benefits of this change elsewhere in the product as well. One example being when you add VM objects to jobs, this process takes upwards of 2 minutes at times to cache our vCenter information on every request. I see the benefits of checking regularly in order to keep up with the rapid changes, but at times it becomes cumbersome when making large changes in Veeam.

[Gostev]

Excellent point.

[chrisdearden]

That would be very handy indeed - I assume the cache for the job is built up during the "building vm list" phase of a job ? I assume the vcenter API is a little bit throttled in terms of how fast we can pull data from it but I've seen that selection take upwards of 200 seconds on a large vcenter ( 3000+ vm's , 200+ data stores ) - the only other way to help speed up job selection would be to be more selective on how you pull - for example initially just query for datacenters , then only clusters in that DC - at present it seems to pull everything in , which means that the UI experience isn't as smooth as it could be.