B20292 cpu spikes since b20292 due dedup

%3CLINGO-SUB%20id%3D%22lingo-sub-2147781%22%20slang%3D%22en-US%22%3EB20292%20cpu%20spikes%20since%20b20292%20due%20dedup%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2147781%22%20slang%3D%22en-US%22%3ESince%20the%20upgrade%20to%20b20292%20the%20server%20computer%20regularly%20has%20high%20cpu%20use%20Spikes%20(hear%20this%20due%20turning%20up%20fans)%20%2B%20TM%3CBR%20%2F%3E%3CBR%20%2F%3ECaused%20by%20dedup%20feature%20running%20ever%20since%20in%20this%20config.%20There%20is%20not%20much%20data%20changes%20and%20dedup%20optimize%20for%20VDI%20%2F%20Hyper-V%20%2F%20vhdx%3CBR%20%2F%3E%3CBR%20%2F%3EAnyone%20else.%20I%20will%20upgrade%20to%20the%20latest%20tomorrow%20and%20report%20back.%3CBR%20%2F%3E%3CBR%20%2F%3EImportant%20to%20note%20that%20the%20cpu%20hog%20in%20TM%20is%20not%20tied%20to%20dedup%20task%20but%20remaining%20unvisible%20for%20the%20user%20think%20so%20procmon%20might%20help.%3CBR%20%2F%3E%3CBR%20%2F%3EVolumes%20are%20either%20a%20mirrored%20Storage%20Spaces%20or%20Single%20volumes.%20All%20with%20lastest%20ReFS.%3CBR%20%2F%3E%3CBR%20%2F%3EAnyone%20else%3F%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2147781%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Ededuplication%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EStorage%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2175422%22%20slang%3D%22en-US%22%3ERe%3A%20B20292%20cpu%20spikes%20since%20b20292%20due%20dedup%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2175422%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20issue%20is%20that%20Background%20Optimization%20and%20Priority%20Optimization%20are%20running%20every%20hour%20and%20even%20conflict%20on%20their%20schedule.%20So%20some%20optimization%20jobs%20queue%20up%20but%20are%20successful.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EI%20would%20like%20to%20point%20out%20there%20is%20not%20much%20data%20IO%20%2F%20changes%20on%20the%20drives%20and%20I%20wonder%20why%20the%20release%20is%20seems%20agressive%20now%20on%20the%20Dedup%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eaffected%20builds%3A%20b20292%2C%20b20295%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22K_Wester-Ebbinghaus_0-1614628762699.png%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F259256i614CBF66C89BA93E%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20role%3D%22button%22%20title%3D%22K_Wester-Ebbinghaus_0-1614628762699.png%22%20alt%3D%22K_Wester-Ebbinghaus_0-1614628762699.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Frequent Contributor
Since the upgrade to b20292 the server computer regularly has high cpu use Spikes (hear this due turning up fans) + TM

Caused by dedup feature running ever since in this config. There is not much data changes and dedup optimize for VDI / Hyper-V / vhdx

Anyone else. I will upgrade to the latest tomorrow and report back.

Important to note that the cpu hog in TM is not tied to dedup task but remaining unvisible for the user think so procmon might help.

Volumes are either a mirrored Storage Spaces or Single volumes. All with lastest ReFS.

Anyone else?
5 Replies

The issue is that Background Optimization and Priority Optimization are running every hour and even conflict on their schedule. So some optimization jobs queue up but are successful.

I would like to point out there is not much data IO / changes on the drives and I wonder why the release is seems agressive now on the Dedup

 

affected builds: b20292, b20295

 

K_Wester-Ebbinghaus_0-1614628762699.png

 

you are certainly busy with Ignite. 

here is a screenshot from the PowerShell

again since b20292 it seems like Dedup Optimization is running over and over causing all day long cpu load

 

K_Wester-Ebbinghaus_0-1614711495972.png

 

 

The average looks low but this CPU load is only the average of 12 Threads and mainly caused by Dedup process

 

K_Wester-Ebbinghaus_1-1614711686444.png

 

@Elden Christensen do you know who could help to investigate this uncommon behaviour?

Is there anyone seeing the same issue still?
The issue seems to get better in a later release currently 20234

Hello @Elden Christensen I am afraid the issue is not solved.
I drilled down that it will appear as soon one enable Dedup for VDI use and "Background Optimization", which will keep the server busy the whole day even when there are no relevant changes on the stored vhdx's-

The scheduled optimize jobs are acting fine but the background optimization is running the whole day (starting, completing, starting again) consuming reasonable amounts of CPU time.