Number of concurrent tasks

[FrancWest]

Hi,

case #03963023

The engineer stated that I should limit the number of concurrent tasks for the proxy (=veeam backup server itself) and it's repositories so that their sum would be equal to 24 (=number of cores).

In my opinion this is not correct and I should only look at the concurrent tasks on the server. That one is set to 24, which is equal to the number of cores. Veeam gives a green checkmark on this. If I must lower this to account for the number of concurrent tasks on the repositories, this would have a major impact on the throughput of our backup server.

In my opinion, the concurrent tasks on the repositories is irrelevant (they are only used to limit the stress on the disks of that repository) since the number of tasks on the repository is dependent on the number of tasks on the proxy. It are the tasks on the proxy that cause a task on the repository.

What do you think?

Franc.

[HannesK]

Hello,
the support engineer is configuring it to the settings from the user guide / best practice guide. So that's okay and I would not blame him for that.

https://helpcenter.veeam.com/docs/backu ... l?ver=95u4
https://www.veeambp.com/proxy_servers_i ... ckup_proxy

Unfortunately, the information about repository tasks / core sizing is not clearly documented right now (we are working on that). But in the best practice guide, you can find a 2:1 ratio for the repository

So you can raise the values from support a little bit. But probably there was a reason to reduce the tasks (I did not read through the case).

Best regards,
Hannes

[FrancWest]

Hi,

Thanks, the 2:1 ratio mention it's for virtual repositories. We are using a physical Veeam backup server. Does this same guideline apply to that?

Franc.

[foggy]

Hi Franc, in case you assign both proxy and repository roles to the same server, you should keep in mind the total number of tasks since both components run on the same machine.

[FrancWest]

Hi, ok, but does the 2:1 rule also apply for physical proxies?

[foggy]

I'd say it is a general rule for the initial environment sizing.

[soncscy]

Interesting thread -- so am I getting it right that in an all in one set up, regardless of physical/virtual, we can safely subscribe our infrastructure components on a 2:1 Task:Core ratio? We've sized things heavily towards total tasks for infrastructure items that share roles, but am I sizing improperly here? (i.e. if I have something acting as both a repository and a proxy, should I size for $TotalProxy + $TotalRepo or how should I approach this?)

Also, why doesn't the User Guide mention 'vCPU' but the Best Practices Guide does? Foggy writes that 2:1 is safe across all environmental items, but if that's the case, where did 1:1 come from for the User Guide, and why does the Best Practices guide specify vCPU? Or am I taking that too literally?

[Gostev]

I think you're all just talking about different things.

Recommendation is 1:1 for proxies, 2:1 for repositories.
Task:vCPU for VMs, Task:Core for physical servers.

[tsightler]

It's true that the Best Practice guide does specifically list the 2:1 ratio in the "Guidelines for virtual repositories", which is a little confusing because there is not "guidelines for physical repositories" section in the guide, however, in the field, when designing large physical repositories, we generally use the 2:1 ratio as somewhat of a baseline.

However, it's important to note that repositories have more to do with what makes sense for the storage, network and available RAM while also considering the impact on things like backup copy jobs and synthetic operations, since that's where those are limited.

To come back to the original discussion in this thread, I took a look through the support case at a high level, and it seems you have a single server with both proxy and repository roles. In that scenario I would also generally recommend 1:1 ratio for both proxy and repo unless you are sure you have plenty of resources, especially RAM. Looking at the logs it looks like you only have 96GB of RAM in the server even which means you are under the best practice RAM recommendation for 24 cores if you want to also use the best practice tasks values. The best practice RAM is 2GB/core for proxy and 4GB/core for repo, but you have to combine those when both are running on the same box, so that's 6GB/core, which would be 144GB RAM as the best practice recommendation. That's at least one possibility why you are seeing issues with the shared memory connection and thus reducing repo task could definitely help here.

[tstarken]

If you have a physical server (24 cores) as a mount server for iSCSI storage (Synology NAS) at a remote location which only stores long term backup copies, what would the ratio recommendation be in this case?

[HannesK]

the recommendation is always the same. of cause, for a repository-only machine (it sounds like that), you do not need to take proxy resources into account.

[FrancWest]

The best practice RAM is 2GB/core for proxy and 4GB/core for repo, but you have to combine those when both are running on the same box, so that's 6GB/core, which would be 144GB RAM as the best practice recommendation. That's at least one possibility why you are seeing issues with the shared memory connection and thus reducing repo task could definitely help here.

RAM usage is not the issue as it appears from the performance counter captures. We mostly have 40 to 50% free. It seems that the load on the 12 disks on the NAS is the issue during the reFS merges. When several copy job run the reFS merges at the end, it cripples the disk access and causes the shared memory error.

[HannesK]

We mostly have 40 to 50% free

it's not about "mostly" - it's about peaks... you did not write how much RAM you actually have...

From a support perspective, reducing tasks is a good way to troubleshoot.