Gitlab runner on windows with shell executor limited to efficency cores
Summary
CI jobs started in the windows shell executor with gitlab-runner running as a Windows service are limited to efficency cores and jobs take very long.
When starting the gitlab runner manually with gitlab-runner run
, jobs can use all threads and complete 3x faster - but a user needs to log in and start the runner manually for this.
Steps to reproduce
Build a resonably large dotnet project on a bare-metal windows machine with an Intel CPU 12th gen or newer.
My CI script is
.gitlab-ci.yml
build:
stage: build
script:
- cd $SolutionFolder
- dotnet clean
- dotnet build
tags:
- windows-test-runner
Actual behavior
dotnet build only runs on e-cores (4/20 threads used on an i7-12700), CPU load ~35%
Expected behavior
All threads used, 100% usage
Environment description
Self-Hosted Runner
CPU: Intel i7-12700 - 8 p-cores, 4 e-cores
Up to date Windows 11 (23H2)
Up to date Gitlab Runner (16.11.1, built 2024-05-03)
Up to date net8
config.toml contents
concurrent = 1
check_interval = 0
shutdown_timeout = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "windows-test-runner"
url = "xxx"
id = 18
token = "xxx"
token_obtained_at = 2024-05-14T11:47:51Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "shell"
shell = "pwsh"
[runners.custom_build_dir]
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
Used GitLab Runner version
.\gitlab-runner.exe --version
Version: 16.11.1
Git revision: 535ced5f
Git branch: 16-11-stable
GO version: go1.21.9
Built: 2024-05-03T15:52:47+0000
OS/Arch: windows/amd64
Possible fixes
Maybe the QoS Level "Utility" introduced in the Windows 22H2 update is to blame: https://learn.microsoft.com/en-us/windows/win32/procthread/quality-of-service
But I see no option to set change the QoS level for a service from my side.