哈喽，咱们一步步来排查这个CPU负载过高的问题——我之前也处理过类似的Supervisor+Python服务的性能故障，下面从几个核心方向拆解：

首先得搞清楚到底是哪个进程在吃CPU，别瞎猜：

• 用htop或者top命令看系统进程，找到CPU占用最高的进程（大概率是你的两个Python程序之一，或者频繁重启的Supervisor相关进程）。
• 用supervisorctl status看看两个程序的状态，是不是一直在重启（比如显示STARTING或者BACKOFF），如果频繁重启，那进程反复初始化肯定会耗CPU。
• 对Python程序做性能剖析：用python -m cProfile -s cumulative your_websocket_script.py运行WebSocket程序，或者给检查程序加同样的参数，看看哪个函数占了最多的CPU时间，精准定位热点。

1. 15秒检查的while循环程序 #

这个程序很容易成为CPU大户，尤其是如果你的逻辑写得不够高效：

• 是不是忙等？ 如果你写的是while True: 检查逻辑; time.sleep(15)那没问题，但如果是没加sleep的忙等循环（比如反复检查时间直到15秒到），那会直接占满一个CPU核心！赶紧确认sleep的逻辑是不是正确。
• 检查用的SQL有没有优化？ 比如你查最近15秒的写入记录，是不是用了全表扫描？给数据的写入时间字段加个索引：CREATE INDEX idx_data_write_time ON your_table(write_time);，这样查询速度会快N倍，CPU消耗骤降。
• 有没有必要轮询？ 可以换成PostgreSQL的LISTEN/NOTIFY机制：在数据写入时触发NOTIFY，检查程序只需要监听通知，不用每隔15秒查一次数据库，彻底干掉轮询的CPU消耗。

2. WebSocket数据接收程序 #

这个程序如果处理逻辑有问题，也会吃很多CPU：

• 是不是单条写入数据库？ 每次收到一条数据就commit一次，数据库交互的开销极大，而且程序会频繁等待数据库响应，CPU上下文切换也会增加。改成批量写入：比如攒100条数据或者每隔5秒批量提交一次，用executemany或者批量INSERT语句。
• 有没有复用数据库连接？ 如果每次写入都新建数据库连接，连接的创建和销毁会非常耗CPU。用连接池吧，比如psycopg2的SimpleConnectionPool，或者SQLAlchemy的连接池，复用连接能省很多资源。
• 消息解析是不是低效？ 如果用标准库的json解析大量数据，换成ujson或者orjson这类更高效的库，解析速度能提升好几倍，CPU占用自然降下来。
• 重连逻辑是不是太激进？ 如果WebSocket连接断了就立刻重试，没有退避策略，那会反复尝试连接，耗CPU。加个指数退避：第一次等1秒，第二次2秒，最多等30秒，避免无效重试。

3. Supervisor重启逻辑的问题 #

你的重启策略可能放大了CPU消耗：

• 别重启整个Supervisor！ 重启整个Supervisord会把所有管理的进程都重启一遍，开销极大。改成只重启失效的WebSocket进程就行：在检查程序里调用supervisorctl restart your_websocket_process_name，而不是重启整个服务。
• 是不是频繁触发重启？ 看Supervisor的日志（默认在/var/log/supervisor/），如果因为短暂的网络波动就触发15秒无写入的判断，那会不断重启进程。把阈值调高到30秒甚至1分钟，减少不必要的重启。
• 解决WebSocket连接失效的根本原因：为什么连接会经常断？是不是没发心跳？WebSocket服务端一般会主动断开长时间无交互的连接，你在程序里加个心跳逻辑，每隔30秒发个ping包，维持连接，从根源上减少重启需求。

• 用pidstat -u 1 -p <进程PID>持续观察目标进程的CPU使用率，看优化后有没有下降。
• 开启PostgreSQL的慢查询日志：在postgresql.conf里设置log_min_duration_statement = 100（记录执行时间超过100ms的查询），看看你的SQL是不是有拖后腿的。
• 盯紧Supervisor的日志，确保进程不再频繁重启，稳定运行。

内容的提问来源于stack exchange，提问作者Alex