Skip to main content

Background:

I see a single job running in a “Waiting” state that has this as the reason for waiting: “All device streams configured to this Storage Policy including their multiplexing factor are in use. Advice: Please check the jobs currently running to this Storage Policy. Current job will run once a stream becomes available.”

Doing some searching: The CommVault docs go into an in depth of what streams are, how to set the maximum allowed streams (at several levels/areas, like at the storage policy level) and all I see of ‘other jobs using this storage policy’ is a single running job claiming to be using 10 readers. The storage policy is configured to use 70 streams, the job stuck in waiting is set to use 8… I’m not sure why there are not 60 streams available….but it got me wondering:

 

Question: is there a way to determine (like with a query or a report not manually clicking on each subclient or going through a gigantic report and manually summing up stream counts by hand) how many streams the system is actually allocating to each job as it runs, or ‘streams allocated/used per hour’ or similar?  For my issue I wrote about above, it would be nice to go “so, at this moment what is using or requesting more than 60 streams to cause this job to go into waiting” and I could get those jobs, and then I could look historically to see if this is “normal” or if the stream usage/allocations have been ramping up.

Hello @tigger2 

Thanks for the great question and I am glad you have done some digging on streams and how they work in CV as it is quite an expansive topic. 

I currently do not know of a way to view the amount of streams active on a SP level and only know how on a CS level ( bottom of the job controller ). 

The thing that may be tricking you up is that an Aux copy job will use streams in some scenarios. The device streams on a Storage Policy is essentially how many writers you can have on the primary copy at one time. So if you have an Aux copy job that is moving data from a secondary copy back to the primary ( not very common but may be happenings in this case ) it will consume streams and cause backup jobs to wait. 

Out side of the above, if you have an example of the jobs waiting when you think they should not be please raise a case to support, you may be hitting a bug and we would like to fix that ASAP. 

 

Kind regards

Albert Williams


Reply