-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
The random access performance of macOS runners is incredibly slow #2707
Comments
Hi @smorimoto! |
Here are the hardware and software informations for the slow machine. This is probably helpful for identifying one by serial number.
I ran a simple benchmark with sysbench. If you're not familiar with how to do that, here's how: |
In my experience, the slowdown on some machines seems to have started suddenly several months ago. MacStadium sometimes uses fairly old machines as hosts, so consider that possibility. |
@smorimoto I'm afraid the serial number is the same across all the VMs, so it won't help us. We can identify a particular machine by a link to the run. |
@smorimoto thanks, I see some of them are about 1-2min and some 4+. We'll take a look more carefully. |
Are you referring to the system profiler? I'm not familiar with macOS, so I don't know, but the time it takes doesn't seem to have much to do with the storage performance of the machine. |
Sorry, I should have checked carefully. By the way, you provided the same link both for the slow and normal ones. |
Hmm? I think I've provided the 8th and 10th jobs. |
@smorimoto I've checked your run and there are 2 slow examples — 7&8, both were run in the data center, which is currently being deprecated. It'll take 2-3 more months to finish infrastructure migration, so I suggest bringing up the issue again if it persists after this time. |
Got it, thanks for the investigation. I hope all slow instances won't be used as soon as possible. |
@miketimofeev shouldn't this issue remain open until the infrastructure migration has completed? |
@miketimofeev Many VMs still seem to have the issue. Especially, the write performance is often terrible: https://github.com/smorimoto/actions-ve-repro-2707/actions/runs/752151426 |
@miketimofeev Don't know if you'd prefer a new issue, but now it's months after, and I'm seeing the same/similar. It's random, but often: 10-25% of the runs are slow. A good run can "uninstall homebrew" (i.e. mostly disk i/o) in 184 seconds https://github.com/rokmoln/support-firecloud/runs/3295490478?check_suite_focus=true#step:3:190 A slow run can "uninstall homebrew" 2.5 times slower, in 483 seconds Similarly, reinstalling homebrew (disk, network and cpu bound) happens 1.8 times slower, in 593 seconds https://github.com/rokmoln/support-firecloud/runs/3295490501?check_suite_focus=true#step:3:447 instead of 333 seconds https://github.com/rokmoln/support-firecloud/runs/3295490478?check_suite_focus=true#step:3:456 Overall, my builds time out even with a 2x-than-normal timeout (normally 23minutes, timeout 45 minutes). |
@andreineculau yes, create a new issue, please. It would be great if you can provide the minimal repro steps so we will be able to make a few runs and gather data that can be escalated to the engineering team. |
As the title says. However, this does not always happen, and it seems to be a random problem with some runners. This makes everything incredibly slow if you build on the problem runner.
According to the GitHub documentation, it says "GitHub hosts macOS runners in GitHub's own macOS Cloud" but somehow it seems that there are runners managed on 54112 and 36459, are slow on either of them? (Sorry, I don't have time to spend investigating this and you probably have more information.)
The text was updated successfully, but these errors were encountered: