# Superfluous vm.drop\_caches in vmm/kvm/\*?

**URL:** <https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537>\
**Category:** Product Support\
**Created:** [September 19, 2023, 8:51am UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537 "2023-09-19T08:51:31Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yenya](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/yenya/32/4624_2.png) [@Yenya](https://forum.opennebula.io/u/Yenya)\
**Post date:** [September 19, 2023, 8:51am UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/1 "2023-09-19T08:51:31Z")

</div>

Hello,

when running `onehost flush` before host reboot, I observe _huge_ load spike after the VMs are migrated away from the host-to-be-rebooted. The root cause is that there are tens of CPU-eating sysctl processes, probably two for each VM that used to be running on that host. `grep sysctl vm/kvm/*` shows the following:

```auto
vmm/kvm/cancel: (sudo -l | grep -q sysctl) && (sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &) || true
vmm/kvm/deploy: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 >/dev/null
vmm/kvm/migrate: ssh_exec_and_log "$DEST_HOST" "(sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 >/dev/null || true" \
vmm/kvm/migrate: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &
vmm/kvm/migrate_local: ssh_exec_and_log "$dest_host" "(sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 >/dev/null || true" \
vmm/kvm/migrate_local: ssh_exec_and_log "$src_host" "(sudo -l | grep -q sysctl) && (sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &) || true" \
vmm/kvm/resize: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 >/dev/null
vmm/kvm/resize: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &
vmm/kvm/restore: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 >/dev/null
vmm/kvm/save: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &
vmm/kvm/shutdown: (sudo -l | grep -q sysctl) && sudo -n sysctl vm.drop_caches=3 vm.compact_memory=1 &>/dev/null &

```

Is it really necessary to do this on every migration/deployment/… etc? On a host with 512 GB RAM and 19 running VMs the above `sysctl` command takes 29s real and 28s system time, and probably also affects other running VMs negatively, dropping the memory cache under them.

It _might_ have sense to compact memory for example hourly or nightly, but definitely not after removing/migrating a single VM out of tens which might be running on that host. And definitely not in parallel when multiple deployments/migrations are in progress.

(and of course having several forms of the sysctl call, differing slightly from each other, is _really_ ugly …)

Thanks in advance for considering a different approach to memory compaction in vmm/kvm/\*.

-Yenya

---

<div class="post-metadata">

**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\
**Post date:** [September 19, 2023, 9:05am UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/2 "2023-09-19T09:05:13Z")

</div>

Hello Yenya,

You could alter the behaviour via the `remotes/etc/vmm/kvm/kvmrc` file:

> # Compact memory before running the VM  
> #CLEANUP\_MEMORY\_ON\_START=yes
> 
> # Compact memory after VM stops  
> CLEANUP\_MEMORY\_ON\_STOP=yes

It is just an on/off switch to turn off the feature globally.  
And yes, maybe the default configuration behaviour could be different…

Best Regards,  
Anton

---

<div class="post-metadata">

**Author:** ![Yenya](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/yenya/32/4624_2.png) [@Yenya](https://forum.opennebula.io/u/Yenya)\
**Post date:** [September 19, 2023, 9:29am UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/3 "2023-09-19T09:29:50Z")

</div>

Hi Anton,

thanks for the fast reply. Yes, this would solve my problem, but I agree that the default behaviour should be carefully considered 🙂

-Yenya

---

<div class="post-metadata">

**Author:** ![tinova](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/tinova/32/25_2.png) [@tinova](https://forum.opennebula.io/u/tinova)\
**Post date:** [September 19, 2023, 5:21pm UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/4 "2023-09-19T17:21:38Z")

</div>

This can indeed be improved, thanks for your feedback.

[This issue](https://github.com/OpenNebula/one/issues/6324) can be used to track associated improvements.

---

<div class="post-metadata">

**Author:** ![Yenya](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/yenya/32/4624_2.png) [@Yenya](https://forum.opennebula.io/u/Yenya)\
**Post date:** [September 19, 2023, 7:50pm UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/5 "2023-09-19T19:50:17Z")

</div>

Subscribed, thanks.

-Yenya

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex031/uploads/opennebula/original/2X/1/14d66f1130b9cd292905f575da9b68a9f574dd03.png) [@system](https://forum.opennebula.io/u/system)\
**Post date:** [June 25, 2025, 3:48pm UTC](https://forum.opennebula.io/t/superfluous-vm-drop-caches-in-vmm-kvm/11537/6 "2025-06-25T15:48:00Z")

</div>

Closed on June 25, 2025, 3:48pm UTC

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.