Windows VM massive RAM usage

[Jackmynet]

Hi everyone, I am hoping you guys might be able to help me understand something about my windows VM's.

I have a Proxmox cluster with 3 Nodes and 3 Windows VM's running on them. Our requirements are very small and the severs are running small monitoring softwares. The Cluster is all working great and i am using Ceph shared storage etc.

My issue is that the windows machines seem to go through a daily cycle with hug RAM usage. When I check it then it shows optimizing Disks as the source of this usage.

I have Qemu guest agent enabled on 2 of the VM's and diabled on another but it is happening on all of them now. Also using Q35 Machine type.

I have also attached a snapshot of the specific RAM operation from the windows task manager. it does this for a few hours and then stops until the next day.

Any ideas?

 

[justinclift]

As a thought with that screenshot, it's showing about 10GB of ram (roughly) being used by the disk defragmenter process.

When you created the virtual machines, what type of drive (Bus/Device setting) did you tell Proxmox to pretend it is?

Asking because with the `IDE`, `SATA`, and `SCSI` drive types there's an option for `SSD emulation`. If you set that, then I'm thinking the disk defragmenter process wouldn't even get started by Windows as it doesn't run for SSDs.

Alternatively, you could probably set the drive type to be "VirtIO" when you create it. That doesn't have an "SSD mmulation" option in the settings window on the web interface, as I think (from rough memory) that it tells windows it's an SSD anyway.

 

[Jackmynet]

Hi thanks for the reply.

I have SSD emulation ticked yes. From what i am reading it is maybe best to simply disable the disk optimization in windows when running in virtual environment.

The Bus device i used is scsi on all them.

Am I maybe best disabling this process in windows all together?

 

[justinclift]

Yeah, I'd tell the disk optimizer to just not run. That should at least solve the memory usage problem it's causing.