S4-8G 内存占用观测与优化

发布时间:2026-06-09 17:26

看内存别只盯着 used 那一列，这是排障时最常见的误区。顺云 S4-8G 有 8G 内存，理论余量不算小，但观测方法用错，容易把正常缓存当成问题，也可能漏掉真问题。这篇把 free 的解读和缓存服务调优分开讲清楚。 free 的正确读法 执行 free -h，重点看 available 列而不是 free 列。Linux 会把空闲内存拿去做页缓存（buff/cache），加速文件读写，这部分随时可回收，所以 free 低不等于内存不足。经验线：available 长期低于总量一成（8G 机型即 800M 左右），才需要认真对待。想看压力来源，用 vmstat 1 观察 si、so 两列，持续非零说明在换页，内存确实紧张；偶发几个非零值属正常抖动，不必紧张。拿到一台新机器，建议先跑一次基线记录，把空载时的 available 和各进程内存存档，日后对比才有参照。 缓存服务的调优 Redis 和 Memcached 这类缓存服务本来就要吃内存，调优方向是划清边界而不是压榨。Redis 设 maxmemory 1gb 并配 maxmemory-policy allkeys-lru，超限后自动淘汰冷键，避免无界增长；有持久化需求的要注意 fork 时的内存占用翻倍问题，used 内存接近物理内存一半就该警惕。MySQL 侧对应 innodb_buffer_pool_size，按物理内存三到四成配置即可，配小了读请求都压到磁盘，配大了挤压其他进程，两头都要避开。 进程自身的隐蔽增长 应用内存泄漏比缓存增长更难发现，因为曲线爬升缓慢，天天看反而不觉。排查用 ps aux --sort=-rss | head 取内存前几名，隔半小时再跑一次对比增量；更省事的做法是每天定时把进程内存快照落一份日志，一周后纵向对比。某个进程持续单调上涨且不回落，基本可判定泄漏，重启只是临时手段，根治要靠应用侧修代码。对比时注意采样条件一致：同样的时段、同样的负载状态，否则结论不可靠。 建议：给 available 设 800M 告警线，配合每周一次的进程内存对比，8G 机型就能长期稳定运行。观测先行，优化才有依据，顺序不要颠倒。内存问题九成能在曲线里看出端倪，曲线不存档，经验就无法积累。