宝塔首页cpu显示0%或卡死，通常因监控服务未运行；先重启面板服务，再检查时间同步、selinux权限及/www用户对/proc/stat读取权限。
宝塔首页CPU显示为0%或卡死，先检查监控服务是否运行
首页顶部“资源使用情况”里的CPU数值来自 psutil.cpu_percent()，每3秒采样一次。如果显示为空、恒为0%或长期不刷新，90%是面板后台监控服务未启动，而不是系统真没负载。别急着翻日志，直接点右上角“重启面板服务”按钮，等10秒后刷新页面——多数情况当场恢复。
若仍无效，检查时间同步：timedatectl status 看系统时钟是否漂移超5秒；漂移过大会导致 psutil 采样失败，返回0值。
另一个常见原因是权限问题：宝塔以 www 用户运行，若该用户无法读取 /proc/stat（比如SELinux启用或目录权限被改），也会表现为CPU始终为0。可临时切到root执行 su - www -c "python3 -c 'import psutil; print(psutil.cpu_percent())'" 验证。
用 top 快速抓取瞬时高CPU进程快照
面板监控有5秒采样间隔，而 top 是内核级实时视图，适合捕捉短时尖峰。执行以下命令获取当前最耗CPU的前5个进程：
top -b -n 1 | head -n 5
注意这不是交互式界面，输出里第二行的 %Cpu(s) 是总体占用率，第三行起才是进程列表。关键字段包括 %CPU、PID、USER、COMMAND。
容易踩的坑：
-
top -b -n 1默认只显示前15行，可能漏掉真正元凶；加| head -n 20更稳妥 - Python多线程程序常表现为单核100%，但整体CPU%不高——这时看
psr列（需top中按f添加字段），确认是否所有高占用进程都挤在PSR=0上 - 某些恶意脚本会快速启停，
top -b -n 1可能拍不到；可改用ps aux --sort=-%cpu | head -n 11，它不依赖采样周期，更稳定
在宝塔“进程管理”中交叉验证并持续观察
进【安全】→【系统工具】→【进程管理】，这里默认按 %CPU 降序排列，数据源与 ps aux 一致，但带UI筛选和终止功能。重点不是看“此刻谁最高”，而是做三件事：
- 比对
PID和COMMAND是否与top或ps aux输出一致——不一致说明面板进程列表缓存未更新，点右上角“刷新”按钮 - 点击进程右侧“详情”，查看其
PPID（父进程ID）和启动路径，判断是正规服务（如/www/server/php/82/bin/php-fpm）还是可疑脚本（如/tmp/.x/xxx.py） - 勾选多个疑似进程，点“结束进程”后，立刻回首页看CPU是否回落；若回落，再查其父进程或定时任务（
crontab -l或/var/spool/cron/）
注意：宝塔进程管理不显示线程级信息，top 中的 Threads 列或 htop 的树状视图才能看到子线程分布，这对排查PHP-FPM worker或Java应用很有用。
单核跑满但整体CPU%偏低？必须查CPU亲和性与GIL限制
宝塔监控图只显示整体平均值，掩盖了核心不均衡问题。比如Python多线程Web服务受GIL限制，所有线程只能争抢一个核，可能出现PSR=0长期100%、其余核空闲，但面板显示整体CPU才40%——这时网站响应明显变慢，监控图却“风平浪静”。
验证方法：
- 终端执行
ps -eo pid,psr,comm | grep your_process_name，看所有线程是否都落在同一PSR上 - 查Nginx或PHP-FPM配置：
worker_cpu_affinity是否错误绑定了单核；PHP-FPM pool里process_manager = static+max_children过大也易引发争抢 - 如果是Python应用，用
taskset -cp 0-3 PID临时把进程绑到多核，观察是否缓解
这个层面的问题，仅靠宝塔面板+top 无法闭环定位，必须结合进程绑定策略、应用线程模型和硬件拓扑一起看——最容易被忽略的是，你看到的“CPU正常”，其实只是“平均值正常”。
