data mover shared memory path

[karsten123]

Hi,

back in v8, the registry option DataMoverLocalFastPath was introduced.

Is it still valid for v12?

My specific case is a WAN accelerator and a backup repository on the same machine.
So i thought the disk fingerprints are much faster because local. But they are not as fast as it could be, i think.
And i saw traffic on the network stack.

thx guys
Karsten

[david.domask]

Hi Karsten,

The registry value is still valid, but there shouldn't be a need to change it from SharedMemory to any other options for some time now. SharedMemory is the optimal choice and there shouldn't be a need to work with this registry value anymore.

What kind of performance are you seeing and may I ask why it's expected to be different? Not saying there isn't an issue, just trying to understand the situation a little more. I would not bother with the registry value, but won't hurt to test naturally, but I expect you won't see any meaningful changes in performance.

WAN Accelerators need a bit of memory as noted in the User Guide, and since it's performing the role of repository, was the sizing checked for all the roles that the WAN accelerator plays? https://helpcenter.veeam.com/docs/backu ... ccelerator

[karsten123]

Hi David,

The machine is a 16 core EPYC with 192 GB memory and 24x SAS RAID60. So i expected like 1GB/s and its like 1Gbit/s like the network speed for this specific machine. Unfortunately no 10GbE+.
I just want to speed up the fingerprinting. It is time consuming for disk with 4+ TB.

So, shared memory is the default for v12.1?
Is it something different if the repository is a Cloud Connect repository?

Thx
Karsten

[david.domask]

So, shared memory is the default for v12.1?
Is it something different if the repository is a Cloud Connect repository?

Aha, it's been default for many versions, so it's not really a registry value you should need anymore. It was more relevant back when pre-2012 Windows machines were common for infrastructure, nowadays it's not so much needed.

Out of curiosity do you have the registry value set already for this machine perhaps to a different value? Also I must note that the fingerprinting can take awhile especially for larger machines. How much time is it consuming now?

[karsten123]

Hi David,

no registry value is set on the repository.
CloudConnectQuotaAllocationMode with value 2 is set on the vcc server.

Creating fingerprints for 1,5 TB Hard disk takes 2h 13 min.

Thx
Karsten

[karsten123]

Is this performance expected?
Is it faster with Server 2022? At the moment it is still Server 2016.
Should i raise a Veeam support case?

[david.domask]

Hi Karsten,

Hrm, the time is not so outrageous as the Fingerprints calculation can be a bit intense; it's basically reading the entire on the Target WAN Accel for the first copy to build this or if it needs to rebuild the fingerprints (e.g., previous fingerprints are missing or invalid).

Is this happening frequently that it needs to rebuild the fingerprints or we're discussing just the initial fingerprints calculation? If it's frequently needing to re-build the fingerprints, that I would recommend open a support case for.

If it's just the initial calculation, I'm not confident that the time is that far out of expected ranges for the fingerprint calculation. But if this is happening frequently where it has to re-calculate (you should see it mention this in the Job Statistics window), I would indeed open a Support case to check why it's happening so frequently.

[karsten123]

Hi David,

at the moment i just struggle with the initial process.

Thx very much and have a nice weekend.
Karsten

[karsten123]

Are there any tuning options?

[david.domask]

Regrettably at this time no tuning registry values I can see, but the point is clear that this is an area that is most time consuming for you. I don't think that it's specifically about OS performance and I'm not personally aware of 2022 vs 2016 making much of a difference so I would not expect significant gains, but I would be curious if you see better results if such an upgrade is already scheduled.

But regrettably no specific tuning values I can recommend.

https://bp.veeam.com/vbr/2_Design_Struc ... ccelerator
https://bp.veeam.com/vbr/2_Design_Struc ... ccelerator

I would suggest give this a read if you haven't already, because as noted, our recommendation is dedicated machines for WAN accelerators when possible as there can be some issues with over-committing resources, and the digests part on Target is pretty IO intensive; are you in a "many to one" scenario like it mentions for Target WAN Accelerator? I wonder if that might be where the bottleneck is.

[karsten123]

Hi David,

OS upgrade is planned for the next months. I will report back if it is significantly faster.
It is a many to one target WAN acc but only for 4 source accs.
I would prefer dedicated machines too and it was that way last week but my challenge is to mitigate the gigabit connection and the repository has lots of unused resources.

I already activated 4 copy jobs at the same time and the performance is scaling quite well while processing in parallel.

Thank you David for your help.