cloud os 进程

一、先解读截图核心数据
进程 1：PID 64421 命令 oc，瞬时 CPU 177.8%
oc = OpenStack Controller 控制面核心调度 / 操作执行进程，属于 CloudOS 底层 OpenStack 管控组件；当前是瞬时突发高 CPU（运行时间仅 00:00.32，刚拉起短时冲击），不是长期持续高负载。
进程 2：PID 25625 scope，持续 150.0% CPU，运行时长 10 万 + 小时
scope 是 CloudOS 资源监控、指标采集、告警统计核心进程，长期持续占用多核 CPU，是本次高负载根因。
整机资源基线：
总内存 128G，空闲 40G，内存充足；无 Swap；CPU 空闲 88.5%，整机 CPU 资源富裕，只是两个进程抢占多核。
load average 3.2/4.6/4.79，多核服务器负载正常，无整机资源耗尽风险。
二、两个进程能否停止 / 重启？分风险等级
1. scope 进程（PID25625，长期 150% CPU）
进程作用
负责云主机、存储、集群、虚拟机 CPU / 内存 / 磁盘 IO 指标采集、时序数据库写入、监控图表渲染、阈值告警计算，CloudOS 前台「监控中心」所有数据依赖该进程。
启停风险
临时重启安全，禁止长期 kill 强制停止
正常重启：仅监控数据采集中断 30~60 秒，云主机、虚拟机、存储、虚机业务完全不受影响；
强制 kill -9：监控页面空白、无性能曲线、告警不触发，不会中断租户业务，但运维监控失效。
允许操作：优雅重启（推荐）
2. oc 进程（PID64421，瞬时 177.8% CPU）
进程作用
OpenStack 操作调度进程，创建 / 删除虚拟机、调整规格、迁移、快照、网络策略下发等操作时临时拉起，操作完成后自动退出；截图里是刚执行云平台操作产生的瞬时高 CPU。
启停风险
正常场景无需手动处理：操作执行完毕自动释放 CPU；
若操作卡死、oc 长期不退出：可优雅停止，会中断当前正在执行的云主机任务（如创建虚机失败、迁移终止）；
禁止频繁 kill，会导致 OpenStack 数据库任务残留、资源锁异常。
三、分步操作方案（先处理 scope 长期高占用，再处理 oc 瞬时进程）
步骤 1：重启 scope 进程（解决持续 150% 高 CPU，业务无影响）
方式 A：CloudOS 标准服务重启（最优，优雅释放资源）
CloudOS 基于 docker 容器化部署，scope 为容器服务
bash
运行
# 1. 查看scope对应容器名
docker ps | grep scope
# 2. 重启scope容器（平滑重启）
docker restart $(docker ps | grep scope | awk '{print $1}')

重启后等待 2 分钟，重新执行top -bn1查看 scope CPU 占用回落至正常 5% 以内区间。
方式 B：进程优雅终止（容器异常时使用，不推荐首选）
bash
运行
# 先优雅信号
kill -15 25625
# 等待30秒未退出再强制kill（万不得已）
kill -9 25625

注意：kill 后容器编排会自动拉起新 scope 进程，监控短暂断档。
步骤 2：处理 oc 瞬时高 CPU 进程
先判断：等待 3~5 分钟重新执行 top
若 64421 号 oc 进程自动消失：代表云操作执行完成，无需干预；
若进程长期存在、CPU 持续 170%+，说明后台任务卡死，执行优雅停止：
bash
运行
kill -15 64421

执行后当前未完成的云平台任务（新建 / 迁移 / 快照）会失败，需在 CloudOS 前台重新发起操作，不会破坏已存在虚拟机。
四、scope 长期高 CPU 根因排查（重启后反复冲高需要做）
查看 scope 日志定位采集瓶颈
bash
运行
# 进入scope容器
docker exec -it $(docker ps | grep scope | awk '{print $1}') /bin/bash
# 查看实时日志
tail -f /var/log/scope/scope.log

高频报错场景：
虚拟机数量上千，指标采集轮询间隔过密；
存储 OneStor 节点 IO 异常，磁盘指标采集阻塞；
时序数据库 InfluxDB 写入堆积，scope 大量线程阻塞；
大量失效 / 残留虚拟机，无效指标循环采集。
优化方案（日志确认瓶颈后）
CloudOS 前台【系统设置 - 监控参数】调大指标采集间隔（默认 1 分钟可改为 3 分钟）；
清理平台内长期已删除、残留未释放的虚拟机资源；
检查后端 InfluxDB 存储磁盘 IO 是否打满，扩容时序存储磁盘。
五、关键禁忌说明
不要直接kill -9长期运行的 scope，容易导致时序数据库文件损坏，监控数据全部丢失；
不要批量 kill 所有 oc 进程，会导致云平台批量虚拟机操作失败、产生脏数据；
scope 属于运维监控组件，重启不影响租户虚拟机业务；oc 是临时任务进程，仅影响正在执行的云操作；
整机内存、CPU 资源充足，无需紧急扩容，优先重启 scope 缓解负载。
快速总结
scope（PID25625）持续高占用：可以安全重启容器，仅监控短暂中断，租户业务无风险；
oc（PID64421）瞬时冲高：优先等待自动结束，卡死再优雅 kill，会中断当前云主机操作；
重启后如果 scope 反复高 CPU，需要查 scope 日志，优化监控采集策略或清理冗余虚机资源。

别重启了吧，oc重启集群节点应该会变成notready吧，整体CPU使用率还行