TeamCity command line script not utilising all cores.
I've got the following setup; TeamCity server setup on one agent with a second agent setup as a build.
I've got a custom command line script that isolates some products and then builds those products, this process on the build agent PC LOCALLY takes 39 mins consistently.
The same set of command line scripts running from the TeamCity server takes almost twice as long.
I think this is down to the CPU utilisation on the build agent.
When ran locally denenv.com (which is called from within my scripts) will take all the cores available and it needs. However when running from TeamCity it appears to only use half the cores.
Above is the CPU usage from TeamCity execution.
I cannot find anything within TeamCity to adjust/control this, any ideas, any help appericated. Thanks.
Please sign in to leave a comment.
Hello Jack,
Am I correct to assume you use command line build step to run the executable in question? TeamCity just delegates execution to OS's shell (either directly or by creating a temporary file containing the script if you define it inline). Any chance the affinity was manually changed for the agent process? If yes, this could maybe explain the behavior for its sub-processes. If you run agent process as a service, does stopping it and starting it from the console via script change anything?
Hi Fedor,
Yes I am using the command line build step, as follows; c:\cygwin\bin\bash.exe --login -c "script argument argument"; So I a tempoary file is being created for case.
I have not changed the affinity of the agent, but I can certainty try to up it, thanks for the suggestion.
So I believe this is now related to e and p cores. I think only e-cores are being used when launched from TeamCity
Hello Jack,
What version of Windows do you run on this agent? I found something that may be relevant in regards to how background processes are handled on Windows 10 - please see this Reddit thread for the details.
Hi Fedor,
Thanks for that link, I too had found similar reports.
Good news is that I've been able to solve the issue. Since the introduction of the “new” settings menu in windows there are 2 power settings that “conflict” with each other. The control panel power setting needs to be set to balanced and then the new menu setting set to best performance, this allows the windows scheduler to play nicely with e and p cores.
On one agent I had control panel setting set to High Performance which hides the new menu setting, and on other agent both were set to balanced mode.
Thanks for the help and hope this helps people going forward.
Thank you for all the details! This definitely was not trivial.