Description of problem: Recently I've noticed that ksmd is using quite a lot CPU on my oVirt node. While I have plenty RAM, my CPU is way slow. Thus ksmd is eating up the most limited ressource here. I've noticed that settings for ksmd are handled by MoM: /etc/vdsm/mom.d/03-ksm.policy. I'd like to use a higher value for sleep_millisecs to reduce CPU usage (with the possible side effect of higher RAM usage). I suggest to make this configurable with the "engine-config" tool. Version-Release number of selected component (if applicable): ovirt-engine-3.3.0.1-1.fc19.noarch ovirt-engine-backend-3.3.0.1-1.fc19.noarch ovirt-engine-cli-3.3.0.5-1.fc19.noarch ovirt-engine-dbscripts-3.3.0.1-1.fc19.noarch ovirt-engine-lib-3.3.0.1-1.fc19.noarch ovirt-engine-restapi-3.3.0.1-1.fc19.noarch ovirt-engine-sdk-python-3.3.0.7-1.fc19.noarch ovirt-engine-setup-3.3.0.1-1.fc19.noarch ovirt-engine-setup-plugin-allinone-3.3.0.1-1.fc19.noarch ovirt-engine-tools-3.3.0.1-1.fc19.noarch ovirt-engine-userportal-3.3.0.1-1.fc19.noarch ovirt-engine-webadmin-portal-3.3.0.1-1.fc19.noarch ovirt-engine-websocket-proxy-3.3.0.1-1.fc19.noarch ovirt-host-deploy-1.1.1-1.fc19.noarch ovirt-host-deploy-java-1.1.1-1.fc19.noarch ovirt-host-deploy-offline-1.1.1-1.fc19.noarch ovirt-image-uploader-3.3.1-1.fc19.noarch ovirt-iso-uploader-3.3.1-1.fc19.noarch ovirt-log-collector-3.3.1-1.fc19.noarch ovirt-release-fedora-8-1.noarch vdsm-4.12.1-4.fc19.x86_64 vdsm-api-4.12.1-4.fc19.noarch vdsm-cli-4.12.1-4.fc19.noarch vdsm-jsonrpc-4.12.1-4.fc19.noarch vdsm-python-4.12.1-4.fc19.x86_64 vdsm-python-cpopen-4.12.1-4.fc19.x86_64 vdsm-xmlrpc-4.12.1-4.fc19.noarch How reproducible: always Steps to Reproduce: 1. start using 10+ VMs on oVirt node 2. CPU usage of ksmd will increase dramatically Actual results: ksmd is one of the top5 CPU consumer Expected results: Ksmd should not be *that* aggressive in reclaiming RAM, but rather configurable depending on the hardware configuration (more RAM => less aggressive, more CPU => more aggressive). Additional info:
(In reply to Frank Wall from comment #0) > > Actual results: > ksmd is one of the top5 CPU consumer > > > Expected results: > Ksmd should not be *that* aggressive in reclaiming RAM, > but rather configurable depending on the hardware configuration > (more RAM => less aggressive, more CPU => more aggressive). > > > Additional info: Hi Frank, Since oVirt 3.2, KSM is being handled by mom, which has policy rules for KSM. Starting 3.3, the engine can update mom's policy and this is already implemented for ballooning. So what we should probably look into, is suggesting an alternate policy parameters which a cluster can use, rather than the default one. Feel free to suggest patches for it. In the mean time, this is just merged: http://gerrit.ovirt.org/#/c/20879/ which you can use to disable ksm if indeed you have sufficient RAM. You can also edit 03-ksm.policy for a specific host if you still want KSM running.
is there any news on managing mom policy on a cluster or host level through engine? the current approach via editing the policy file installed by mom has serious disadvantages such as: you need to restore your custom policy everytime you update mom
(In reply to Sven Kieske from comment #2) > is there any news on managing mom policy on a cluster or host level through > engine? > the current approach via editing the policy file installed by mom > has serious disadvantages such as: > you need to restore your custom policy everytime you update mom Sven, we'll consider it during 3.6 planning. As you probably know there are lots of RFEs and less than that programming hands. So we need to see where it stands in relation to other requests.
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
The BZ#1256949 reports ksmd high cpu usage due to the sleep_millisecs set to 0. Limiting sleep_millisecs to minimum 10 was the solution adopted there.
Configuring it can be done easily via Ansible. Closing for the time being. Please re-open if still relevant.