New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows runners are consistently extremely slow compared to Linux and macOS #7320
Comments
I suspect it might be Windows Defender in action.
|
Here are many other people similarly seeing that |
See commit myitcvscratch/slow-windows-actions@8b71de3 which resulted in run https://github.com/myitcvscratch/slow-windows-actions/actions/runs/4480846656/jobs/7876717612. It has basically no effect. I also tried making this change in the CUE project in https://review.gerrithub.io/c/cue-lang/cue/+/551317. That resulted in https://github.com/cue-lang/cue-trybot/actions/runs/4476128503 which again showed no effect. So assuming my testing is valid, turning off Windows Defender does not appear to have any effect in our case. |
Thanks, @mvdan. Just to emphasise however that the use of The reason I flag this is that ultimately we will consider this issue "fixed" when the |
I've also tried to disable Windows Defender, no significant difference so far https://github.com/ilia-shipitsin/slow-windows-actions/actions/runs/4483502669/jobs/7882868552 |
@myitcv , as for I mean, is degradation |
We only have the numbers from GitHub actions workflow runs. |
we need to narrow it, whether standalone Windows server behaves the same slow or not |
Duplicate of #5166 |
@mikhailkoliada - isn't #5166 demonstrating a slowdown between 2019 and 2022? The numbers we are seeing show consistent slowness on both 2019 and 2022. Therefore I'm not clear this is a duplicate. |
side note, I did some investigation on "checkout slowness", it looks like there's some delay between git and automation task. git itself takes 2-3 seconds (I put commands into cmd and wrapped with I can beleive that agent communication could add 15-20 sec, but it does not look like a root cause for |
Hey! let me chat with the team and see what is going on and see if we need a separate wrap up ticket for Windows Perf (or I will get someone to re-open this one!) |
@mvdan @myitcv we think this may be the same as the checkout issue. Given that 'hunch' we will tackle that tracking our progress here: actions/checkout#1186 We will keep this issue open until we can validate if it is a dupe and go from there (or start working on a new root cause for this after I guess 😱 let's hope not!) |
@nebuk89 - thanks for looking into this and the detailed update. Much appreciated. |
This job is still timing out sometimes. There are some open bugs about slow Windows runners, maybe relevant: actions/runner-images#7320
This job is still timing out sometimes. There are some open bugs about slow Windows runners, maybe relevant: actions/runner-images#7320
This job is still timing out sometimes. There are some open bugs about slow Windows runners, maybe relevant: actions/runner-images#7320
This is to make sure we stay cross-platform. Note that the Windows build and test is [a lot slower than Linux and Windows](actions/runner-images#7320). Because of that, I had to change the wait in one of the tests. Also, I'm using windows-2019, which is at least 2x faster than windows-latest: actions/runner-images#5166 On macOS, I ran into an issue where CloseRead on a connection that was already fully read causes an error, so I needed to update the test there too. It was a huge pain to figure out what was going on.
Per actions/runner-images#7320, the older runners perform better.
I would like to add that the situation seems to be even worse with larger runners. We have to use 8-core Windows runners (the regular one runs out of heap space) and they are only twice faster compared to the 2-core machines. On Linux the 8-core vs 2-core performance is as expected (though 8-core machines are still slower in some aspects; actions like checkout take 4-times longer etc.) and the steps that can be parallelised (the build step, for example) in fact take cca. 4 times less time. On windows that ratio is around 2. |
Many Cypress Windows tests are timing out even after increasing the timeout to 2 hours, likely due to actions/runner-images#7320. Hopefully running the tests at night during reduced load will reduce the prevalence of noisy neighbors since the GitHub Windows runners seem unable to properly isolate compute-heavy workloads.
providing some data here as a CI tool developer: Windows OS tends to prolong a ~5 mins done on MacOS and Ubuntu to 1HRS+ with unknown cause (Ref: https://github.com/corygalyna/AutomataCI/actions/runs/7083465554/job/19275876384) as of the date of this posting. This is observed since November 2023 and now it is incrementally getting unusable. Some CI tasks are in serial execution (ref: CI - Materialize) and all the commands are running via local PowerShell script. The timing statistics are making no sense:
The delay is usually at the start of a job or at the end of a job. Can't debug further without some kind of diagnostic guidance. Update (Dec 7, 2023 08:32 UTC): I think the GitHub solved something: https://github.com/corygalyna/AutomataCI/actions/runs/7125351326/job/19401138941 Suddenly, it's blazing fast. Update (Dec 8, 2023 00:14 UTC): Nevermind. It's back to its sluggishness: Should be server related problem. |
Same issues here -https://github.com/1kastner/conflowgen/actions/runs/7202425735/job/19620518126 and https://github.com/1kastner/conflowgen/actions/runs/7202425735/job/19620518686. It takes ages for the action to start. Before the test suite finishes (on my local laptop a matter of few minutes), it is aborted because I assume my time budget is consumed. |
This is also the case when building NuGet packages (the .NET/C# ecosystem). The process takes 57 seconds for my small project on |
I switched from |
according to the following source it should improve the performance: actions/runner-images#7320
Trying a suggestion mentioned at: actions/runner-images#7320 (comment) Signed-off-by: Paul Jolly <paul@myitcv.io> Change-Id: I37200a5c6bc936f2de3bb8b96034a2892404e48a Dispatch-Trailer: {"type":"trybot","CL":1174197,"patchset":1,"ref":"refs/changes/97/1174197/1","targetBranch":"master"}
Any chance we can get Windows XP runners? |
For completeness, this had no impact in our situation. |
Switching to |
Description
In the CUE project we are seeing incredibly slow run times on Windows 2022 runners.
For a recent example see https://github.com/cue-lang/cue-trybot/actions/runs/4477594562/.
Roughly speaking, here are the numbers we are seeing averaged out across 20-30 builds per day.
actions/checkout
go test
(cache hit)ubuntu-22.04
macOS-11
windows-2022
Notice that
actions/checkout
is consistently slower on Windows. Yes, there is a network access element to this, but it is minimal.The
go test
comparison is the cleanest comparison. As indicated in the column heading, these are the timings for a full cache hit. i.e. no network access required, no rebuilds required, no tests actually running (because they hit the test cache). So thego test
command is purely a function of disk access and CPU. For this command, Windows is consistently 15 times slower than Linux. macOS is, pleasingly, comparable with Linux.Platforms affected
Runner images affected
Image version and build link
For
windows-2019
:For
windows-2022
:Is it regression?
Unclear
Expected behavior
Windows runners to be comparable in terms of speed to Linux and macOS for
actions/checkout
andgo test
steps.Actual behavior
Windows runners consistently taking 15 times as long as Linux and macOS for CPU and disk-intensive commands.
Repro steps
The CUE repo itself is quite involved. So as a proxy for something that is relatively CPU and disk intensive we have created a slimmed down repo using
actions/checkout
.https://github.com/myitcvscratch/slow-windows-actions
See the most recent run for results:
https://github.com/myitcvscratch/slow-windows-actions/actions/runs/4477601338
Looking at averages of this setup across a number of runs we see similar figures for
actions/checkout
to those seen in our CUE setup:actions/checkout
ubuntu-20.04
ubuntu-22.04
macos-11
macos-12
windows-2019
windows-2022
So whilst this doesn't include the
go test
step (because getting a warm cache is a tricky step to reproduce) the use ofactions/checkout
is a sufficiently good proxy to show the problem.The text was updated successfully, but these errors were encountered: