Server 2025 - high CPU and RAM

[jokoenen]

Hi all!
Today I tested the Windows version 26100.6584 on both, W11 and Server 2025.
I started with the W11 machine 32GB Ram, Intel core ultra 7 155U with 12 cores, 14 logical CPUs. On a ReFS volume with veeam backups - full and incremental - I deleted one folder with 9 TB size.
It took 76 minutes to free up the space of the deleted files. During this time period the CPU load was between 13% and 40%, memory usage between 60% and 86%, writing speed approx 96% or 90 MB/s, which is near the maximum and reading speed 2-4 MB/s during all the time it took.

So far so good, but the long time it took, might cause some problems when space is needed or if speed slows down due to e.g. parallel backup writing.

Afterwards I tried it on a Server 2025 deleting 6.5TB of veeam backup files stored in a different directory.
Intel Xeon E-2224 CPU 4 cores, 32GB RAM. It started quite ok with 34% CPU and 60 % RAM. The free space increased slowly over time similar to the W11 machine, but then after 10 minutes it happened:
The remote console became non responsive. I waited for another 40 minutes - no real change, only the time display in the bottom line changed a little bit was far - 26 minutes - behind reality.
I decided to unplug the HD and connected it back to my W11 PC. Here the cleanup process continued immediately and finaly the space became fre, but 93GB stayed reserved and for System.
In the meantime the Server 25 recovered by itself and I could check the eventlog. But nothing meaningful has been in there, only, that the timelimit 30000ms of a transactionresponse has been reached.

So in summary, there is some progress how deleting of huge files is processed, but the long time and relatively high loads it takes to free up the space is not acceptable. The freezing of the Server 2025 is definetly beyond acceptance. I did not any tuning in the registry, so this might reduce but ybe not solve the problems.

So my advice regarding ReFS volumes:
Avoid deleting of huge files - mine have not been really huge since still below the 4TB border.
So reverse incremetal backups and full backups with incremetals following are ok. But don't delete a full backup to built up a new one. Don't replace an old backup with a new one on the same device. This only works after formatting it.

Hope this helps.
Jo

[ChristophINV]

@jokoenen

Thanks, had nothing to delete yet and as I'm running on Reverse-Incremental right now, that's helpful to have in mind!

So I "just" finished the 69 TB-Job (Full, 40 hours) and one Reverse-Incremental step on Top (Server 24H2 Build 6584 as well) without any problems. System peaked at 24 GB of RAM, went back to 14 GB once done. Guess I can downsize it back again from its current 64 GB. Reporting CPU-Load during operation is pointless for me, as it is where it is supposed to be at Max-Compression (28 Threads Xeon Gold 6132) as I'm somewhat Storage-Performance-Limited anyway (300 MB/s Limit on the ReFS-Repo, but that's going constantly). System did not crash, that's a good start. As an Increment is done within three hours, I'm scheduling that thing for the upcoming week and monitor how it goes.

Seems like KB5065426 did something. Time will tell. Hopefully Microsoft will improve things before someone needs to delete something.

[Flole]

From my experience deleting works but it requires that the OS is restarted a few times in between to clean up the memory. I deleted 5 TB of data and rebooted the machine 3-4 times while it was reclaiming space. No registry tweaks, just rebooting, and eventually the deleted files space was fully reclaimed.

[Heimer-BEAS]

I thought the "private" fix was supposed to go live in August?

[HenrikS.]

Seems we hit this behaviour with large memory usage, 100% CPU and system lock.

New AIO server with Windows Server 2025, set up a couple of weeks ago, 2xReFS volumes of 250TB each, no initial tuning and September 2025 patches installed.
Problems started yesterday after having changed retention period for a large job, resulting in deletion of about 20TB of data.
Server froze some hours later. Forcefully rebooted, would then start working on freeing up space again, but would lock up after about 30 minutes with memory usage of 190GB and 100% CPU on 24 cores.

Checked some of the registry tweaks,
RefsEnableLargeWorkingSetTrim=1 (This was set by default it seems, it was already there and I cannot remember to have set it earlier.. ?)
RefsEnableInlineTrim=1 (I set this after a couple of forceful reboots)

RefsEnableInlineTrim seemed to do the trick, after setting this, the server would not lock up after a reboot, but continued to work on freeing up the space. Memory usage was still <190GB, but CPU usage was way lower and it did not lock up.
After it finished some more hours later, the memory usage dropped to 43GB while idling. It'll be interesting to follow the next run..

[m.novelli]

I'm wondering how Microsoft cannot manage to solve what looks like a commodity: delete a huge amount of data from a filesystem

Marco