内存显示快满但服务正常

free -h 里 used 快顶满，服务却一切正常，这算故障吗？多数情况不算——Linux 会把空闲内存拿去做文件缓存，这是设计行为，不是内存泄漏。 ## free 输出怎么读 free -h 的表头里，total 是总量，used 是已用量，buff/cache 是内核缓存，真正该看的是 available 一列（可供新进程使用的内存估算值）。一台跑了几天的 8G 内存机器，used 显示 7.1G、free 只剩一两百 MB，available 往往还剩两三 GB——used 高，多数是被缓存占走了。 经验口径记一条：available 低于总内存的一成，或一周趋势持续下滑，才值得动手查，单点数值高不代表有问题。 ## 为什么这样设计 内存闲着才是浪费：磁盘上的文件反正要读，读进内存的副本留着，下次命中就省一次磁盘 IO。Linux 的策略是"应用用不完的，拿来做缓存"，所以运行一段时间的服务器 used 居高是常态。老版本 free 的输出没有 available 列，很多人拿 free 判断告急，误报就是这么来的。 想主动归还缓存也可以 echo 3 > /proc/sys/vm/drop_caches，但只用于测试观察，生产环境没必要常态化，缓存本来就会被内核自动回收。 ## 什么时候才真的要担心 看两个信号：available 持续走低并逼近零；swap（交换分区）开始频繁换入换出。验证命令： free -h vmstat 1 5 vmstat 输出里 si、so 两列长期不为零，说明物理内存确实不够，系统在靠交换分区硬撑，这时才需要扩容或排查泄漏，ps aux --sort=-%mem | head 看谁吃得多，再决定是加内存还是优化程序。想看单个进程的真实占用，top 里按 Shift+M 以内存排序，RES 列是实际物理内存，VIRT 大不代表吃得多。 Redis 这类内存数据库不适用这套判断，容量规划按它的真实占用算，别被页缓存逻辑带偏。 运维口径建议统一：监控告警看 available 和 swap 活动，别拿 used 或使用率百分比吓自己。监控平台同理，阈值配 available 的绝对值或占比，比配 used 百分比靠谱得多。看到内存"快满"先查 available，数值充裕就放心跑。顺手把 free -h 的输出存进巡检记录，趋势有了，判断就有了依据。