From last 2 weeks we are observing performance issues with Vmware snapshot backup over SAN mode.
vMware backup jobs are taking 2-3 days to complete , throughput has declined from 1 TB/hr to 50 GB/hr.
The underlying backup library is healthy with no disk failures .
I see in command center health report that disk pruning status as critical for global vmware deduplication policy . data aging is running on daily basis .
How can i manually run pruning of DDB ? Is there any impact on running backup while pruning DDB manually. There is an option to validate and
Also , what does Read, write and network % means in Average throughout which is very low .
Average throughput 64.27 GB/hr (Read: 14.19%, Write: 0.83%, Network: 84.96%)
Regards, Mohit
Best answer by Mike Struening RETIRED
Updating with case solution:
-VM VSA backup running with poor throughput when dedupe is enabled -The VM backup runs with Average throughput of 30GB\Hr when dedupe is enabled. -For the same client when dedupe is disabled we get a throughput of 1.4 TB\Hr.
-Checked the DDB and noticed the Q&I is fine but the Pending deletes are high, 42 TB to be freed -Since pruning is running in the background, the backup performance could be affected. -We temporarily disabled pruning and initiated new job and noticed the Avg throughput was increasing gradually and the current throughput was 1.2 TB\hr -So this confirms pruning is the bottleneck.
-The disklibrary is 91% full hence we cannot disable pruning. At this point, our goal is to bring down the pending deletes to 0. -We enabled the pruning and increased the volume size updates to 9000 and update time interval to 15 Minutes. -checked the SIDBPrune logs and noticed Pruning works fine for its local path, and it tries to prune from the Shared MP and reports ReadOnly. This behaviour is seen from all MA's -So we provided "Read\Write" permissions to all MA's, so that any MA can prune the data. -Also added the additional key DedupPrunerThreadPoolSizeDisk with the value of 10.
Solution:
The pending deletes for reduced to 0 after implementing the changes. Backups are running with expected throughput
Can you copy and paste the excerpts from the PerformanceMetrics.log file at this time? It will give us a better breakdown.
Regarding the Dedupe concerns, jobs can run while pruning occurs, but the backup will take priority. More threads will apply towards the backups themselves compared to the pruning side.
Do you have time frames where backups won’t be running?
We don't have any time frame when backups are not running .
I ran 2 on-demand VM backup jobs with same MA and proxy , one with dedupe disable and other one with dedupe enabled and can see significant difference in backup throughput.
with dedupe disabled – received backup throughput close to 2 TB/hr
with dedupe enabled - received backup throughput of 80 GB/hr.
So definitely something is wrong with DDB store , Q&I time is fine ( 136 us)
there are 6 DDB partition for global dedupe policy .
How can i check when last DDB pruning happened and can i run DDB pruning manually and monitor it?
What action needs to be taken when DDB pruning status is Critical ? ( Attached screenshot)
Appreciate the logs and the context. Definitely dedupe related.
Open GxTail.exe and then open the SIDBPrune.log file and the SIDBPhysicalDeletes.log file to see when pruning occurs (logically and physically). SIDBEngine.log will help get further details on the store itself (check for the exact Store ID).
i checked these files and but not able to find the root cause why backups are running slow using dedupe.
See these SIDBPrunelogs :
9536 8184 09/14 09:18:15 ### 31-3 SetMountPath:330 Got path [E:\xxxxxxx\Local\VM\V3YWOW_Folder1\CV_MAGNETIC] for id [170]. User [] 9536 8184 09/14 09:18:15 ### 31-3 OpenIdx:3169 Cannot lock chunk [107288200]. 9536 8184 09/14 09:18:15 ### 31-3 OnChunkStart:1914 Cannot initialize SI Chunk pruner. iRet [-1]
SetMountPath:330 Got path [\\xxxxxx\xxxxxxx\Local\VM\Folder1\CV_MAGNETIC] for id [171]. User [xxxxxxxxxxxxx] 9536 7820 09/14 09:18:15 ### 31-3 PruneZRRecInt:2334 Got [1] primary records. Start ChunkId [106557690], Start Id [3458764514847122184], End Chunk Id [106557690], End Id [3458764514847122184] 9536 4114 09/14 09:18:15 ### 31-3 SetMountPath:359 Mountpath [171] is read only.
-VM VSA backup running with poor throughput when dedupe is enabled -The VM backup runs with Average throughput of 30GB\Hr when dedupe is enabled. -For the same client when dedupe is disabled we get a throughput of 1.4 TB\Hr.
-Checked the DDB and noticed the Q&I is fine but the Pending deletes are high, 42 TB to be freed -Since pruning is running in the background, the backup performance could be affected. -We temporarily disabled pruning and initiated new job and noticed the Avg throughput was increasing gradually and the current throughput was 1.2 TB\hr -So this confirms pruning is the bottleneck.
-The disklibrary is 91% full hence we cannot disable pruning. At this point, our goal is to bring down the pending deletes to 0. -We enabled the pruning and increased the volume size updates to 9000 and update time interval to 15 Minutes. -checked the SIDBPrune logs and noticed Pruning works fine for its local path, and it tries to prune from the Shared MP and reports ReadOnly. This behaviour is seen from all MA's -So we provided "Read\Write" permissions to all MA's, so that any MA can prune the data. -Also added the additional key DedupPrunerThreadPoolSizeDisk with the value of 10.
Solution:
The pending deletes for reduced to 0 after implementing the changes. Backups are running with expected throughput
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.