宝塔首页“内存占用”不能直接判断泄漏，因其包含可回收的cached和buffers；应重点观察RSS是否单向爬升及swap是否持续上涨。
为什么宝塔首页的“内存占用”不能直接判断泄漏
宝塔首页显示的“已用内存”包含 cached 和 buffers，这部分是内核可随时回收的页缓存，不是进程真实占着不放的内存。真正要盯的是 RSS（常驻内存）是否随时间单向爬升，以及 swap 使用量是否缓慢上涨——这两项才是泄漏的铁证。
常见误判：看到首页内存 95% 就以为出事了，结果进任务管理器一看，所有进程 RSS 总和才 1.2GB，其余全是缓存。Linux 这种“内存不用白不用”的策略反而是健康表现。
- 重点关注
swap是否从 0MB 慢慢涨到 100MB+，且持续不回落 - 观察宝塔监控页的“内存”曲线是否平缓上升（非锯齿状波动），尤其在无流量时段也未回落
- 首页数值卡在 0% 或长期不动？大概率是面板监控服务没启，先点右上角「重启面板服务」
用宝塔任务管理器快速筛出可疑进程
任务管理器是宝塔里最轻量、最贴近进程级的泄漏初筛工具，但默认不按内存排序，容易漏掉慢泄漏进程。
- 进左侧菜单「任务管理器」→ 切到「内存」标签页 → 点击
RSS列标题降序排列 - 重点看
RSS > 300MB且运行时间 > 30 分钟的进程，尤其是名字含python、php-cgi、node、gunicorn、uwsgi或你自定义脚本名的条目 - 点 PID 右侧「详情」，确认
启动时间和CMD字段：如果进程已跑 5 小时，RSS从 200MB 涨到 650MB，且命令行是/usr/bin/python /www/wwwroot/myapp/app.py，基本可以锁定
用 htop 补全宝塔看不到的关键信息
宝塔任务管理器不显示内存分配模式（如是否 mmap 大块内存）、不支持按内存增长速率排序、也无法看到子线程或共享内存细节。这时候 htop 是必要补充。
- SSH 登录后执行：
htop -C（-C启用颜色，更易识别高耗进程） - 按
F6→ 选MEM%→ 回车，按内存占比排序 - 按
F4输入关键词（如python）快速过滤，再按Enter展开树状视图，看清父子进程关系 - 关键区别：
htop显示的RES（Resident Set Size）≈ 宝塔的RSS，但能实时刷新、支持鼠标悬停看完整 CMD，且不会因面板权限问题读不到/proc/PID/status
交叉验证泄漏趋势的实操技巧
单次快照没意义，得看变化。宝塔不支持自动比对，但可以用极简方式人工建模：
- 每 15 分钟，在宝塔任务管理器内存页截一张图（或记下 top 3 进程的
RSS值），持续 2 小时 - 同时 SSH 执行：
ps -eo pid,comm,rss --sort=-rss | head -n 6，把输出重定向到文件：ps -eo pid,comm,rss --sort=-rss | head -n 6 >> /tmp/rss.log - 若发现某
python进程RSS从 280MB → 340MB → 410MB → 490MB 线性上涨，而请求量平稳，基本可确认泄漏 - 注意排除干扰：PHP-FPM 的
pm.max_children配置过大、Supervisor 的startsecs过短导致反复重启，都会造成类似假象
真正难搞的是那种每天只涨 50MB、连续七天才触发 OOM 的慢泄漏——这种必须靠定时采集 + 对比，宝塔本身不提供自动告警，得自己写个简单脚本盯 /proc/PID/status 里的 VmRSS 字段。
