gitlab-ci-multi-runner-windows-amd64.exe causes high host CPU use when run in Windows 7 x64 guest on VMware Fusion

Took me forever to figure out where this was coming from...I'm running a Windows 7 x64 runner as a VM under VMware Fusion 8.1 on an OS X 10.10.5 (Yosemite) host. When the gitlab-runner service is started, host CPU usage for the vmware-vmx process on the host jumps from 3-4% to 25-30%, and drops back down when the service is stopped. When looking at the Windows guest's Task Manager, it shows approximately zero percent CPU either way. An OS X (Mavericks) VM on the same host, running the same revision of the gitlab-ci-multi-runner does NOT exhibit the same problem. One thing that has been pointed out in some VMware troubleshooting articles I've read points towards file system listeners as being a potential problem.

I haven't found any way to configure at runtime and change the behavior...am I missing something, or is this something that's previously gone unnoticed? I realize this may not be a common use case.

Have gone through a support ticket with VMware - they say there is no tuning option that would help here and that everything is working as designed and that I should speak with the authors of the software. Is there anything I can do at the GitLab CI end that would impact it?

Not sure what is the problem, we only check existence of single file every few seconds, but it shouldn't make a difference. Could you try to run gitlab-runner run from terminal or try to run the single-mode gitlab-runner run-single (you need to specify all tokens by hand) and check if this makes a difference?

Running runner as services makes it connect to Event Log and post messages there too, maybe this is a problem.

Sure, I'm away from the office today but will check and update on my return this evening. I have run the runner manually and didn't notice any error messages. I'll try the single mode, though...hadn't tried that.

I'm afraid the same thing happens when using run-single

time="2016-01-14T23:57:21-06:00" level=info msg="Starting runner for <ci url> with token <token> ..."```

CPU still goes to 23-24% on host, then drops as soon as I terminate the runner.

Another possible point of interest - when the gitlab-ci-multi-runner service is running in the Windows 7 VM, the OS X host reports ~1000 idle wakeups per interval in Activity Monitor for the VM task (vmware-vmx). When I stop the runner service, the host's idle wakeups for the VM process drop to ~50 per interval, which is much more typical. Possibly something to do with how you wait for connection that varies between Windows and OS X?

Additional information - this doesn't appear to be specific to VMware or to running on an OS X host. I uninstalled the VMware tools/drivers, copied the .vmdk to a KVM host and started the runner guest there. Same behavior, although the KVM host has significantly more resources and doesn't show the same percentages. On the KVM host I get about 11% host CPU when the guest is idle and runner service is started, and < 3% CPU when the runner service is stopped. That seems to be a lot of SOMETHING for just being idle. I may leave the VM here just because that server has better ventilation and can take a constant load better than a Mac Mini.

Thanks, I'll investigate this.

Milestone changed to v1.1

Added improvement label

Same issue here. I have gitlab-ci-multi-runner installed as a service on Windows 10 on KVM host. It utilizes 25% CPU on KVM host when idle, 3% CPU when i stop the service.

Milestone changed to v1.2

mentioned in merge request !122 (merged)

Milestone changed to v1.3

Latest amd64 Windows binary downloaded as of today's date seems to drastically improve this issue, possibly even fixes it entirely. host CPU usage for the Windows build VM is within a percent or two of the OS X build VM on the same host. I had upgraded the VM from Windows 7 to Windows 10, but was still having the issue as before. Downloaded new .exe. Stopped the service, replaced the binary, and restarted the service. This resulted in MUCH lower host CPU usage. FYI, and thanks!

Awesome to hear that :)

This is fixed.

Status changed to closed