宝塔面板CPU内存监控查看教程

宝塔面板首页实时精准展示CPU、内存等核心资源使用率，数据源自psutil每3秒采样，但常见“无数据显示”或数值异常多因监控服务未启动或系统时间漂移，90%问题可通过一键重启面板解决；需注意内存“已用”含缓存、CPU标红预警提示单核瓶颈、进程RSS易误判而USS更反映真实压力，监控页的历史趋势与IO细节、进程管理中的多维指标对比，才能穿透表象定位性能根因——它不是万能诊断工具，而是高效发现异常的第一道哨兵。

首页直接看 CPU 和内存实时使用率

登录宝塔面板后，首页就是最快速的状态入口——不用点任何菜单，CPU、内存、硬盘、网络四项核心指标全在顶部“资源使用情况”区域动态刷新。这里的百分比是真实采样值，不是估算，底层调用的是 psutil.cpu_percent() 和 psutil.virtual_memory()，每 3 秒更新一次。

常见错误现象：刚登录看不到数据，或数值长期卡在 0%。这通常是因为面板后台监控服务没启动，或系统时间异常（比如时钟漂移超 5 秒会触发 psutil 采样失败）。别急着查日志，先点右上角“重启面板服务”按钮试试——90% 的首页无数据显示问题靠这个解决。

• 内存显示里，“已用”包含 cached 和 buffers，不代表真被进程占满；真正要警惕的是 swap 使用量持续上升
• CPU 使用率超过 90% 且持续 2 分钟以上，首页会自动标红，这时别只盯着平均值，得进“监控”页看单核是否某核跑满（比如 Python 多线程受 GIL 限制常出现单核 100%）
• 如果首页 CPU 显示为 0%，但 top 明显有负载，大概率是宝塔运行用户（如 www）权限不足，无法读取 /proc/stat ——检查 /www/server/panel/class/system.py 运行上下文

进“监控”页查历史趋势和 IO 细节

首页只能看“此刻”，而性能问题往往藏在波动里。点击左侧菜单的 监控，开启监控后等 2–3 分钟，就能看到带时间轴的折线图。这里的关键不是看峰值，而是对比：比如凌晨 3 点定时备份任务是否导致磁盘 IO wait 拉高，进而拖慢 PHP-FPM 响应。

容易踩的坑是把“内存占用率高”直接等同于内存泄漏。实际上宝塔默认启用 Linux 的 vfs_cache_pressure=200，会主动回收 dentry/inode 缓存，所以内存“占满”反而是健康表现——只要 swap 不涨、uss（独占物理内存）稳定，就不用干预。

• 磁盘 IO 图里的“读写速度（MB/s）”和“IOPS”要一起看：SSD 上 IOPS 高但吞吐低，可能是小文件随机读；吞吐高但 IOPS 低，大概率是大文件顺序写（如日志归档）
• 网络流量图默认统计所有接口，但如果你绑了多 IP 或用了 Docker，得点右上角“筛选”，选中 eth0 或 br-* 才能准确定位业务流量
• 告警阈值建议设为：CPU > 80% 持续 5 分钟、内存可用 、swap > 256MB——太激进会误报，太宽松会漏掉缓慢泄漏

用“进程管理”定位具体耗资源程序

当监控图报警，下一步必须锁定是哪个进程在吃资源。进 安全 → 系统工具 → 进程管理，默认按 CPU 使用率 降序排列。注意列名里的几个关键内存指标：rss 是常被误读的——它含共享库，多个 Python 进程共用同一个 NumPy 库，rss 会重复计算；真正反映内存压力的是 uss（独占物理内存）和 swap。

典型使用场景：网站变慢，首页 CPU 70%，但“进程管理”里 top 3 进程加起来才占 20%。这时要看 load average（1/5/15 分钟均值），如果远高于 CPU 核数（比如 4 核机器 load 达 12），说明瓶颈在磁盘或锁竞争，不是 CPU 计算本身。

• 点击进程名可查看其打开的文件列表，快速识别是否因 logrotate 未 reload 导致 Nginx 持有已删除日志文件句柄（状态为 deleted）
• 结束进程前务必确认：systemctl is-active xxx 是否为 active，避免误杀由 systemd 托管的服务（宝塔不支持直接删这类服务）
• 对 Node.js 进程，io写 高但 CPU 低，大概率是 fs.writeFile 同步写大文件——该换成 fs.createWriteStream

为什么有时监控数据和 top / htop 对不上？

这不是 Bug，是采样逻辑差异。宝塔的 system.py 调用 psutil 时默认用 percpu=False，返回的是所有 CPU 核心的加权平均值；而 top 默认显示每个核的瞬时快照，且默认刷新间隔 3 秒（可按 s 修改）。更关键的是：宝塔为降低开销，对进程列表每 10 秒轮询一次，而 htop 是实时 inotify 监听 /proc。

所以当你看到“宝塔显示 CPU 40%，但 top 里有个进程占 99%”，大概率是那个进程生命周期短于 10 秒（比如 cron 启动的脚本），宝塔还没来得及捕获就被销毁了。这种瞬态负载，得靠 atop 或 sysdig -c procstat 抓。

• 验证方法：执行 python3 -c "import psutil; print(psutil.cpu_percent(interval=1))"，对比宝塔首页值——如果一致，说明面板采集正常；不一致，检查是否启用了 cgroups 限频（如 Docker 容器设置了 --cpus=0.5）
• 宝塔不显示 GPU 使用率，也不监控 NVMe 温度，这些得靠 nvidia-smi 或 smartctl 单独查
• 如果服务器开了 swap，宝塔内存图表里的“可用”值 = free + cached + buffers - swap_used，这个公式在低内存场景下会误导，实际可用应以 MemAvailable 字段为准（需内核 ≥ 3.14）

宝塔的监控数据可信，但它的设计目标是“快速发现异常”，不是替代 perf 或 eBPF 做深度诊断。真遇到诡异的延迟毛刺或内存缓慢增长，别只盯着面板——/proc/[pid]/status 里的 mm 段、cat /proc/meminfo 的 PageTables 增长量，才是更硬的证据。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《宝塔面板CPU内存监控查看教程》文章吧，也可关注golang学习网公众号了解相关技术文章。