AFF

AFF C190 Compression Poor Performance

YeremiaSionC
2,685 Views

Hi All,

 

We have an issue in our customer project, we are migrating data from DC Site (AFF C190) to DRC Site (AFF C190) using Commvault, both NetApp AFF C190 version ONTAP 9.8P3. data migrated from source to destination is 6TB and our capacity is full in the DRC then i check in the storage saving. The issue is why compression performance is very poor, we only got 1.00:1 ratio also same with Deduplication just giving 1.00:1 ratio. Inline Compression, Inline Dedupe, Compression, Dedupe, Compaction are already enabled.

 

Here is some information i can provides:

YeremiaSionC_0-1634643617930.png

YeremiaSionC_1-1634643657798.pngYeremiaSionC_2-1634643685870.pngYeremiaSionC_3-1634643710307.pngYeremiaSionC_4-1634643749429.pngYeremiaSionC_5-1634643796406.png

 

 

1 ACCEPTED SOLUTION

Ontapforrum
2,655 Views

I think there is a major change in Ontap 9.8 compression process, as it differentiates data into cold and hot classification. Hot data is compressed inline using 8K compression groups, and the old data is then compressed again in the background using a more aggressive 32K compression group. These changes mean better performance for hot data and better data reduction ratios for all data.

 

I believe in your case - the data that has come in (via migration) is considered 'hot' so its less aggressive  and I believe over a time (depending upon the default cooling period), your aggr efficiency will improve as it will have more 'colder' blocks to compress using 32k compression set/group.


This kb is worth a read, though it's NOT the cause for your issue. It's just a information guide for changes in Ontap 9.8 for adaptive inline compression.
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/No_compression_savings_in_ONTAP_9.8P1

View solution in original post

4 REPLIES 4

Ontapforrum
2,656 Views

I think there is a major change in Ontap 9.8 compression process, as it differentiates data into cold and hot classification. Hot data is compressed inline using 8K compression groups, and the old data is then compressed again in the background using a more aggressive 32K compression group. These changes mean better performance for hot data and better data reduction ratios for all data.

 

I believe in your case - the data that has come in (via migration) is considered 'hot' so its less aggressive  and I believe over a time (depending upon the default cooling period), your aggr efficiency will improve as it will have more 'colder' blocks to compress using 32k compression set/group.


This kb is worth a read, though it's NOT the cause for your issue. It's just a information guide for changes in Ontap 9.8 for adaptive inline compression.
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/No_compression_savings_in_ONTAP_9.8P1

YeremiaSionC
2,645 Views

Hi,

 

Thanks for the replies!

Anyway is there a way to change / modify the TSSE Cooling periods to make it more shorter?

CHRISMAKI
2,616 Views

How was Commvault used to migrate the data, was it orchestrating Snapmirror in the background, or was Commvault the actual data mover. Is it possible that Commvault either compressed or worse, encrypted the data, making it non-compressible to ONTAP?

 

The instructions for running post-process sooner are in that KB pointed out above. Run a 0-day cold data scan:

 

volume efficiency inactive-data-compression start -vserver <vserver> -volume <volume> -inactive-days 0

YeremiaSionC
2,525 Views

Its using Commvault data mover, since the Commvault used was software version it doesn't provide compression from Commvault itself. but the issue already solved.

Public