DDB lookup very high percentage (98%) of backup load with 68% deduplication savings

Hi ​@Paul D NZ,

Here the issue is with the Q&I value. The average Q&I time is the average time (in micro seconds) that was taken for insertion and query of signature in the deduplication database.  

https://documentation.commvault.com/2024e/expert/monitoring_deduplication_database_partitions.html

• As per the screenshot, the backend size of store ID:17 is 70.52 TB

• Also, the "Garbage collection" has been enabled.

• I hope the respective MA is associated only with the store ID:17

• 1 Node, 1 SSD disk per node will support up to 75 TB. This will be under "Medium" range.

https://documentation.commvault.com/v11/expert/hardware_specifications_for_deduplication_mode.html

• For this workload we require "600 GB SSD Class Disk 1,2 2 GB Controller Cache Memory7 For Linux, the DDB volume must be configured by using the Logical Volume Management (LVM) package" disk.

• 5K dedicated Random IOPS

https://documentation.commvault.com/2024e/expert/testing_iops_of_deduplication_database_disk_on_windows.html

• Please let us know whether the DDB disk is hosted from a local SSD disk.

• Is it configured from a dedicated RAID or shared with any other resource. Also, share the IOPS details.

Please refer to the below document, to run the IOmeter test to validate the IOPS.

https://documentation.commvault.com/2024e/expert/testing_iops_of_deduplication_database_disk_on_windows.html

Regards,

Wasim

Paul D NZ wrote:

 Here is a screenshot of the current status of the ddb.   Backups are running over desired time windows with 98.27% of load being ddb lookups.   We are close to capacity currently with backup storage though this will be resolved soon.   How can we resolve the high DDB lookup % issue?

DDB and job status screenshots below. 

 

 

Make sure your DDB is hosted on a SSD, preferably one that is NVMe connected, and if this is already the case then you should look into the specs and health state of the drive.