-
Notifications
You must be signed in to change notification settings - Fork 5k
testing azdo vm memory - wasm leg timeouts #111662
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
Conversation
Observations from azdo build Right now it shows But it was showing following messages during build And the reason is probably because there are multiple MSBuild processes in memory, eating gigabytes RSS (resident set size KB) on msbuild totals about 13GB while the real work we are doing at that moment is running emcc/llvm/wasm-opt child process. This is after the runtime was already build and we are building samples (and maybe tests). At that point we probably don't care about msbuild caches populated during libraries build. @rainersigwald is there way how we can tell the msbuild to flush caches ? @lewing @steveisok any advice on making the AzDO agent larger SKU ? At the moment we have 16GB RAM. |
No, we don't have a hint for this, just normal GC triggers. We do keep a bunch of memory in weak-handle caches so GC should be able to free stuff up when it does trigger. |
"Have You Tried Turning It Off And On Again ?" Is that what we need to do ? Run different subsets separately from top level shell ? Is there better way ? |
2359d42
to
b430871
Compare
Now I'm testing And |
AzDO builds of WASM legs are slow/killed/timeout about 50% of the time.