站群系统内存占用过高怎么排查？从进程到配置的实战思路

站群系统内存占用过高，是不少站长在多站点运营阶段都会撞上的问题。一套站群系统往往要同时承载几十甚至上百个站点的进程、缓存与计划任务，内存曲线一旦失控，轻则页面响应变慢，重则进程被系统强制结束，站点批量无法访问。本文围绕这个关键词，梳理一套从现象到根因的排查思路，尽量讲得具体些，方便对照自己服务器的情况操作。

先分清是「真占用」还是「被缓存撑大」

看到内存占用 90% 先别急着加内存条。Linux 会把空闲内存拿去做文件缓存，free 命令里的 available 才是更靠谱的参考值。用 free -h 看一眼，如果 available 还有两三成，那大概率不是站群系统本身的问题。

真正要警惕的是常驻内存（RSS）持续上涨且不回落。我一般会连续观察 24 小时，每隔半小时抓一次 ps aux --sort=-%mem 的前十行，看是哪个进程在爬坡。站群系统常见的内存大户就三类：Web 服务进程（PHP-FPM、Node 进程）、数据库、以及系统自带的定时任务。

多站点并发是内存攀升的常见推手

站群系统的架构决定了它对内存的胃口。每个子站点通常要独立加载一套配置、模板和缓存实例，站点数量翻倍，内存占用往往不是线性增长，而是带着系数往上走。有个做外贸站群的朋友，服务器 8G 内存跑到 60 个站点时开始频繁告警，后来把 PHP-FPM 的 pm.max_children 从 50 压到 18，内存立刻降了将近一半。这个参数很多人直接照搬默认值，其实要按单进程平均内存乘以可用内存来倒推。

顺带说一句，站群后台的批量采集、伪原创、自动发布这类功能，单个任务内存不算高，但并发跑起来就很可观。我个人的习惯是给这类任务加队列，一次只放行两三个，宁可慢点也别把服务器拖垮。

数据库连接池与慢查询，容易被忽略的隐形消耗

站群系统里站点一多，数据库连接数会成倍增加。MySQL 每个连接都要分配缓冲区，连接数虚高时内存看着不多，累积起来同样吓人。执行 show status like 'Threads_connected' 看看当前连接数，再对比 max_connections 的设定，差值太小就该动手了。

慢查询是另一个坑。站群各个子站共享一张大的文章表时，没走索引的查询会把临时表塞进内存。开启慢查询日志跑一天，把执行时间超过 1 秒的语句拎出来看看，多数情况加个联合索引就能缓解。这部分我没法给通用数值，得看实际表结构。

缓存策略没配好，内存只进不出

很多站群系统自带页面缓存和对象缓存，默认策略是「能缓就缓」，过期时间设得极长。站点内容更新频繁时，旧缓存没人清理，内存就被一点点吃掉。检查缓存目录的体积，du -sh 一下那个 cache 文件夹，如果比站点程序本身还大，基本可以确认是缓存堆积。

• 把页面缓存的过期时间从「永久」改成按栏目区分，新闻类 10 分钟，产品页 1 小时；
• 对象缓存优先走 Redis 并设置 maxmemory 和淘汰策略，别让它无限增长；
• 写一个每日清理脚本，删掉超过 7 天未命中的缓存文件，用 crontab 定时执行。

进程层面的几个具体动作

排查到这一步，大致能锁定方向了。给 Web 服务进程设内存上限，PHP-FPM 的 pm.max_requests 设为 500 左右，进程处理够请求数就自动重启，能有效防止内存泄漏累积。Node 进程可以加 --max-old-space-size 参数限制堆内存。

还有个土办法但很管用：给站群系统的管理后台进程单独做资源隔离，用 systemd 的 MemoryMax 限制它最多用多少内存，超了就重启，别让它拖累前台站点。这套组合拳打下来，多数站群系统的内存曲线能回到一个平稳区间。当然，如果站点规模已经到几百个，独立服务器加容器化拆分才是长久之计，光靠调参解决不了架构层面的压力。