-
Notifications
You must be signed in to change notification settings - Fork 361
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
Regularly reset iOS/tvOS Simulators #9274
Comments
Impact:
|
Every build for Build tvOS arm64 Release AllSubsets_Mono job has an AzDO error: "The job running on agent Azure Pipelines xx ran longer than the maximum time of 180 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134". I see that this fix wasn't yet released, it should be done today cc @jtschuster Builds: 1866699 7/7 PM 1865333 7/7 AM 1864252 7/6 PM 1863024 7/6 AM 1861843 7/5 PM 1860642 7/5 AM 1860343 7/4 PM 1859672 7/4 AM 1859371 7/3 PM 1859092 7/3 AM 1858774 7/2 PM 1858309 7/2 AM 1857518 7/1 PM 1856450 7/1 AM 1855530 6/30 PM |
@greenEkatherine this is just too many jobs hitting the queue. Nothing to be done from our side. Maybe too many runs of extra-platforms? |
This PR moves runtime onto 12.00 with newer simulators that have never been reset. Let's see if this alleviates the issue |
Saw this problem today in a tvOS job for runtime-extra-platforms: https://dev.azure.com/dnceng-public/public/_build/results?buildId=38971&view=logs&j=f4520fb1-1559-5885-1d9c-3cb3f6a85e23&t=6c7a8cfe-f92e-569a-eef9-b2ad3e13056d
The changes in the PR are unrelated: dotnet/runtime#76565 |
@carlossanlop I don't think this is related as this issue is about simulators but your job is from a real device |
@premun Thanks for the confirmation. Should I open a new issue in this repo, or do you know if there's an existing one for real devices? cc @steveisok |
@steveisok is there a tracking issue on your side for the TCP issues? |
The original reset we talked about and are not going to do but the unrelated issue discussed below has been resolved by #11700 |
Context
The Simulators are slowing down as they are being used. The folder with their data grows substantially. I did an analysis and found sizes up to 12 GB, most frequently ranging from 2 to 7 GB. This is a potential cause of the slowdown.
To be done
XHarness has a command that wipes the Simulator data and resets the Simulator. We should do this repeatedly on our OSX queues to keep them healthy.
A good fit might be the weekly OSOB pipeline?
Notes
Simulators can be reset via following Helix job:
The text was updated successfully, but these errors were encountered: