concurrent tasks on proxy vs repository

[kaboomza]

Hi there,

What I wanted to understand was, if I Have a proxy that can handle 8 concurrent tasks but my repository has a limit of 4 concurrent tasks, how exactly does that work?

Am I correct in saying if I have a proxy that can run 8 tasks and multiple jobs, I would at any given point in time see 8 vms being processed with 1 disk each being done at a time across the jobs?

[Egor Yakovlev]

Hi Jaques!

"Tasks" are measured differently depending where you set the limit:
- Tasks on a Proxy server are defined 1 task per 1 CPU core per VM disk to process in parallel. So 8 tasks from your example could be 1 VM with 8 VMDK disks or like 2 VMs with 4 disks each.
- Tasks on a Repository are either 1 task per Job, or 1 task per VM(if you set per-VM backup chains).

Am I correct in saying if I have a proxy that can run 8 tasks and multiple jobs, I would at any given point in time see 8 vms being processed with 1 disk each being done at a time across the jobs?

Yes.

p.s. Good read on Tasks allocation\Limits here.

/Cheers!

[kaboomza]

Thank you but let me ask you this.

Lets say I have only one job configured with a bunch of VM's in it, and the proxy it's assigned to can do 8 concurrent tasks, should I See 8 vm's being processed in that one job at a time?

[kaboomza]

Additionally. If I have a server with 20 cores that can, in essence, handle 20 concurrent tasks. can I up the number of concurrent tasks on the repository as well? I would assume that would not be a smart idea.

[Egor Yakovlev]

8 core Proxy = 8 tasks no matter of jobs amount. So yeah, if you group 8VMs(1 vmdk disk each) together in 1 job, your Proxy will process 8 VMs simultaneously.
Task require a CPU Core and some RAM(see Best Practices) - if your Repository has enough resources I don't see any reason not to extend the limit.

Note that backup process performance is not just about Proxy and Repository limits\resources - typical backup contains of 4 components:
- Source: how fast Veeam can read data from production. Here Transport Mode means a lot. Slow read can be your bottleneck, and having 20 cores Proxy will yield no value.
- Proxy: CPU and RAM on Proxy machine. How efficient Proxy can compress\deduplicate data.
- Network: path from Proxy to Repository. If you have 1g link between Proxy and Repository, your backup will never be faster than 125MB\s(physical limit of the network wire).
- Target: how fast Repository service can ingest data to target storage. Once again, if you have slow target storage disks(say cheap NAS with entry-level capacity tier disks) that can become a bottleneck no matter how powerful in terms of CPU and RAM are Proxy and Repository servers are.

Hope that helps!

[foggy]

Hi Jaques, answering your first question, provided your repository has 4 available slots, they will be given to 4 first disks in the queue, other disks will queue up and wait for available resources, despite there are 4 more proxy slots available. Also, keep in mind that synthetic operations are also counted as separate tasks on the repository.

[kaboomza]

Thanks for the feedback guys. @foggy the one thing I am not clear about is the following:

As per Egor's comment "tasks on a Repository are either 1 task per Job" so if I had only 1 job configured with all my vm's in it, I am not utilizing the other 3 slots available on the repository since I only have 1 job running. Or is this incorrect?

[foggy]

This is correct in the case per-VM chains are not enabled. Otherwise, all 4 repository slots will be utilized, as per the second part of Egor's comment: "Tasks on a Repository are either 1 task per Job, or 1 task per VM(if you set per-VM backup chains).".