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.
DavidHampson
2 Intern
•
1080 Posts
410
1
Posted September 14th, 2009 01:00
Target sessions is not the same as parallelism - it is not a maximum number of streams as parallelism is but rather the minimum number of streams the drive will accept before going on to another drive; once all usable drives are filled any other streams are distributed amongst valid drives in a round robin fashion. So we need to determine whether or not your group could be using the full parallelism of the server - firstly check the group parallelism and ensure it is set below 32 and not 0 (unlimited streams) - you want this to be set to 16 I believe. Also check the parallelism settings for your clients. Once you have checked these values come back to us if you still believe there is an issue.DavidHampson
2 Intern
•
1080 Posts
410
0
Posted September 14th, 2009 06:00
That is your answer then - the group will back up as many streams that the clients will throw at it it - subject to the limitation of the sum of their client parallelisms and the global parallelism. Once you have sent 4 streams each to storage node 1 these drives will continue to accept streams until the server parallelism is reached - each drive will be receiving 8 drives each so the server will be able to handle no further streams until that completes.
mpn1
48 Posts
410
0
Posted September 12th, 2009 21:00
From your Q... wat i get is there are total of 8 drives, each with target session as 4. So the total target sessions available is 8x4=32 = Global Parallelism, which is ideal.
Can u tell me the group parallelism of both the groups as well as the client parallelism