Attachment uploads are currently disabled. This is a temporary situation and will resume as normal in the coming days.
Solved!
Go to SolutionParallelism problem
I've got a strange problem since upgrading to 7.4.4 (i'm pretty sure it didn't occur in 7.2.2).
Basically we have 2 backup groups which kick off thoughout the night. One contains clients which use Storage Node 1, and the other contains clients which use Storage Node 2. When the first group kicks off, it uses the expected (maximum) number of drives on Storage Node 1 with the correct level of multiplexing. There are far more savesets than drives though so some savesets are queued.
When the second Group starts, all the savesets queue up, even though there are no jobs running on Storage Node 2.
When the majority of the first groups savesets have completed, the second groups savesets start to backup on Storage Node 2.
I can't really understand why this is. Does anyone have any ideas?
To give you some real numbers, the two storage nodes have 4 drives each (which can multiplex 4 savesets each), and the global Parallelism value is set to 32.
Basically we have 2 backup groups which kick off thoughout the night. One contains clients which use Storage Node 1, and the other contains clients which use Storage Node 2. When the first group kicks off, it uses the expected (maximum) number of drives on Storage Node 1 with the correct level of multiplexing. There are far more savesets than drives though so some savesets are queued.
When the second Group starts, all the savesets queue up, even though there are no jobs running on Storage Node 2.
When the majority of the first groups savesets have completed, the second groups savesets start to backup on Storage Node 2.
I can't really understand why this is. Does anyone have any ideas?
To give you some real numbers, the two storage nodes have 4 drives each (which can multiplex 4 savesets each), and the global Parallelism value is set to 32.
