Skip to main content
commvault.com commvault.com

Hi,

Since few weeks two media agents get very high load during SIDBPrune. Media agent and all lib paths went offline. OS get load above 70 because number of concurrent operation to disk array. 

What i found in SIDBPrune.log :

59123 e6f3 03/08 17:38:05 ### PRNCTLR GetThreadPoolSize:4140 Found u80] processor cores. Setting pruning thread pool size to  80] for fDisk] media.


DedupPrunerThreadPoolSizeDisk registry need to limit threads and fix the issue. 

 

Does anyone know what is behind that? Setting thread pool to number of CPU for background task like prunning probably isn't good idea. For sure for media agent with high number of CPU and SATA array attached to it. 

 

Thanks. 

Hi @lborek thank you for the question.

Setting thread pool size to same number as cores could be putting the MA under pressure, so there’s a couple of approaches here:

1 - Restrict the number of pruner threads:

As you’ve suggested with DedupPrunerThreadPoolSizeDisk:

https://documentation.commvault.com/commvault/v11_sp20/article?p=11947.htm

Also check if any other Dedup* or *Thread* additional settings are set that may govern MA behaviour. Threads may be increased during support cases to get on top of pruning backlog for some other reason, but these should be removed/disabled following resolution of the case.

Previously DedupMaxDiskZerorefPrunerThreadsForStore additional setting was used, but this is replaced by DedupPrunerThreadPoolSizeDisk from SP13:

https://documentation.commvault.com/commvault/v11_sp20/article?p=1497.htm

2 - Set a blackout window for pruning to only occur during quiet periods:

https://documentation.commvault.com/commvault/v11_sp20/article?p=6614.htm

Thanks,

Stuart

Hi @lborek thank you for the question.

Setting thread pool size to same number as cores could be putting the MA under pressure, so there’s a couple of approaches here:

1 - Restrict the number of pruner threads:

As you’ve suggested with DedupPrunerThreadPoolSizeDisk:

https://documentation.commvault.com/commvault/v11_sp20/article?p=11947.htm

Also check if any other Dedup* or *Thread* additional settings are set that may govern MA behaviour. Threads may be increased during support cases to get on top of pruning backlog for some other reason, but these should be removed/disabled following resolution of the case.

Previously DedupMaxDiskZerorefPrunerThreadsForStore additional setting was used, but this is replaced by DedupPrunerThreadPoolSizeDisk from SP13:

https://documentation.commvault.com/commvault/v11_sp20/article?p=1497.htm

2 - Set a blackout window for pruning to only occur during quiet periods:

https://documentation.commvault.com/commvault/v11_sp20/article?p=6614.htm

Thanks,

Stuart

Nice. Thanks! 

Blackout window at media level also will do the job. 

Wondering what trigger the pruning process? Is it daily job? As i see that i start at random time. 

Hi @lborek 

Pruning jobs should follow on naturally after Data Aging job, which I believe is scheduled by default at 12:00 midday every day.

Data Aging reads jobs in the Commserve database and logically ages jobs that have exceeded retention, then sends batches of requests to MAs to perform the physical pruning on disk libraries afterwards.

Thanks,

Stuart

Reply


Terms & ConditionsCookie settings