云机实例资源隔离与稳定性治理 - CPU 绑核与黑屏根因定位产品系统

多台 Android 云机并行运行在同一块板卡上，是云手机与云真机平台的常态。实例一多，CPU 争抢和偶发黑屏这两类问题就会直接冒出来：多个实例的前台与渲染线程挤在同一个核簇里，画面掉帧、触摸不跟手；个别实例画面全黑但进程还在、ADB 能连，故障横跨宿主内核、crosvm 与 guest 三层，定位成本很高。这套能力就是把资源隔离与稳定性治理补到宿主侧，让多实例并发时每台云机都能稳定交付给测试与演示场景。

宿主侧的多实例治理能力，主要包含：一、CPU 资源隔离，按 Android cpuset 分区调整 top-app、foreground、foreground_window、background、system-background 的 cpus 集合，把前台与渲染相关分区收敛到大核簇；二、生效校验，读取 effective_cpus 确认父分区没有把子分区限回小核，并采样 RenderThread 实际所在 CPU，验证绑核真正作用到渲染关键线程；三、实例级配额与进程数约束，避免单个云机跑飞把同板其他实例一起拖慢；四、实例状态面板，聚合每台云机的 ADB 端口、代理 IP、在线状态、CPU 占用、RSS 与进程数；五、属性覆盖，支持在线覆盖实例属性并保留重启后生效，便于复现与回归；六、长稳测试与崩溃采集，把偶发问题固化成可复现样本。

我负责宿主侧的资源隔离与稳定性治理。资源隔离方面，梳理 /dev/cpuset 下各分区的职责与继承关系，调整 top-app、foreground、foreground_window 等分区的 cpus 集合，把前台与渲染线程收敛到大核簇；改完不只读配置，而是读 effective_cpus 确认继承链没有被父节点卡住，再采样 RenderThread 落在哪个 CPU 上，确认绑核作用到了渲染关键路径。稳定性方面，围绕云机偶发黑屏做根因定位：搭建实例级监控，持续采集宿主 dmesg、crosvm 进程与线程状态、guest 侧 logcat 与渲染标记，并把板卡时间、内存、uptime 作为时间轴基准，把黑屏时刻宿主与 guest 两侧的证据对齐，收敛故障范围到画面链路。管理侧补了实例状态聚合面板，集中展示 ADB 端口、代理 IP、CPU / RSS / 进程数，并支持属性覆盖与重启生效，便于复现和回归验证。