I'm curious of the expected logic when a job starts.
If a backup job has 10 VMs and has 4 tasks on the repo (so it's the limit), when it gets to the last few tasks should the processing rate increase with less to process? So let’s say it’s 70 MB/s with 4 tasks, 6 are pending. When it gets to 1 or 2 tasks (so less than the limit) will the rate go up everything being equal? Is Veeam aware of possible throughput and just “carves” out for tasks at the start (which I don’t think it’s anything like that but am curious). For example, 100 MB/s is carved into whatever task limit as if 25 MB/s per task no matter how many are left once the job has started. Is there such a correlation between parallel tasks and processing rate? Thanks!
-
tevans8
- Enthusiast
- Posts: 30
- Liked: 5 times
- Joined: Jun 21, 2012 8:48 pm
- Full Name: Travis Evans
- Contact:
-
HannesK
- Product Manager
- Posts: 14844
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: Processing Rate and Parallel Tasks
Hello,
there is a relationship between number of tasks and speed (if no other infrastructure components are the bottleneck). The key point is the bottleneck (storage, network).
That means: the more tasks, the more speed. With only 1 or 2 tasks instead of 4 tasks working, the speed will usually be lower.
There is no speed limit per task. I usually calculate with 100 MByte/s per task (1 task at proxy = 1 CPU core. 2 tasks at repository = 1 CPU core because data reduction work is on the proxy. that's why the repository is faster).
Best regards,
Hannes
there is a relationship between number of tasks and speed (if no other infrastructure components are the bottleneck). The key point is the bottleneck (storage, network).
That means: the more tasks, the more speed. With only 1 or 2 tasks instead of 4 tasks working, the speed will usually be lower.
There is no speed limit per task. I usually calculate with 100 MByte/s per task (1 task at proxy = 1 CPU core. 2 tasks at repository = 1 CPU core because data reduction work is on the proxy. that's why the repository is faster).
Best regards,
Hannes