fix(status): keep an emulator's memory in its workspace and let ps finish under load - #1828
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
stim status --jsonreported an idle emulator workspace'smemoryMbas 442, 3200 and about 4700 MB a few minutes apart (#1791). Only ~4700 is a real reading (qemu footprint + Metro). The other two are separate failures:attributeMachineUsagerequiredandroid.serial, which comes from the adb lookup. When that lookup misses (always during boot, sometimes under load) the qemu tree lands on an owner withworkspace: null. The requirement came in with feat(status): attribute CPU and memory to one owner per process #1586 with no stated reason; the running qemu-avd <name>process already proves the emulator runs.psread returns null. On this heavily loaded Mac thatpsusually takes 30-80 ms but sometimes stalls for seconds and hit the 5 s timeout; one realstatus --jsoncame back withmachine: nulland the workspace at 3200. The footprint helper never stalled.A dev checkout has one more path to 3200 (
dist/stim-footprint.swiftmissing during a rebuild); published installs never hit it, so it is left alone.Solution
psgets 10 s instead of 5 s, so a stall finishes instead of swapping in a different measure. A retry would run into the same stall.Trade-off: the host table is read synchronously, so a stalled
psnow blocks for up to 10 s instead of 5 s: onestatus --watchrefresh (still under its 15 s interval), the one-shotgc --idleand budget activity reads, and the bare supervisor's idle-stop check, which runs Metro in-process and so pauses it; that check only runs once a workspace is past its idle deadline. The async web-driverpskeeps its 5 s timeout.Payload meaning and
memorySourcevalues are unchanged, so the phone app, Desktop, stim-server and guide need no edits. Summing RSS as a fallback was ruled out: the same qemu's RSS swung 1636-3334 MB in the issue's log while its footprint held at ~4.1-4.3 GB.Test plan
machine-usage.test.ts: new case with an emulator atserial: null, state: 'not-detected'; fails onmain, passes here.Real emulator in my own workspace, cycled with
stim stop/start/androidwhile samplingstatus --jsonfrommain's build and this branch's at the same moments. The sample where qemu ran but adb did not list it yet:After boot both read the same (~4.9-5.5 GB, Metro bundling included).
pslatency with the exact status arguments in aspawnSyncloop at load avg ~140-270: p50 73 ms, p99 780 ms, max 2.5 s in 800 runs; one ETIMEDOUT at 5196 ms in another 300; two concurrent runs stalled to 4.1 s together. The helper's max was 51 ms in 800 runs. This branch'sstatus --jsonruns the unchangedpsarguments against the real tool.Fixes #1791