云服务器面板显示内存使用率超过 90%，不少人第一反应是重启服务或清理缓存。但 Linux 会主动利用空闲内存保存文件缓存，单看已用比例很容易把正常现象当成故障。
判断服务器是否真的缺内存，不能只看 used。更有价值的是可用内存、Swap 活动、进程增长和内核是否触发过 OOM。
先读懂free命令
执行：
free -h常见输出包含 total、used、free、buff/cache 和 available。其中 free 只表示完全没有被使用的内存，而 available 会估算在不触发交换的情况下，新程序还能使用多少内存。
Linux 内核会把暂时不用的内存用作页面缓存，提高文件读取效率。当应用需要更多内存时，其中相当一部分缓存可以被回收。因此，free 很小但 available 仍然充足，通常不代表马上会发生内存不足。
可以再查看 /proc/meminfo：
grep -E 'MemTotal|MemAvailable|Cached|Buffers|SwapTotal|SwapFree|Shmem' /proc/meminfo内核文档把 Cached 描述为文件页面缓存，而 tmpfs 与共享内存会反映在 Shmem 等项目中。不同内核版本和工具算法可能略有差异，不建议手工把几个数字简单相加后当成唯一结论。
找出真正占用内存的进程
先按常驻内存排序：
ps aux --sort=-rss | head -n 15也可以使用：
top重点观察同一进程的 RSS 是否持续增长，而不是只看某一时刻的排名。数据库、Java 服务和缓存程序为了性能主动占用较多内存并不一定异常，只要占用在配置边界内稳定，系统还有足够 available，也没有频繁交换。
容器环境还应查看每个容器的使用量：
docker stats --no-stream宿主机看到的是总量，容器内部看到的统计可能受 cgroup 限制影响。出现异常时要同时检查容器限制、应用进程和宿主机余量。
看趋势比看单次截图更可靠
内存泄漏常见特征是某个进程的占用随时间持续上升，直到服务重启后暂时下降。单次 top 截图无法证明泄漏，也无法区分流量高峰与长期增长。
可以使用系统已有监控记录观察 24 小时或更长趋势。安装了 sysstat 时，可查看历史内存：
sar -r没有监控系统时，也可以短期定时记录 free、进程 RSS 和请求量，但不要让调试日志无限增长。把内存曲线与业务流量、定时任务、备份、数据库维护时间对齐，往往能找到突增原因。
如果占用只在流量高峰上升，流量下降后能够回落，更像业务容量问题；如果请求量不变而 RSS 单向增长，才需要重点检查应用版本、插件、连接池和对象释放。
Swap使用不等于一定有故障
查看 Swap：
swapon --show
free -h系统把长期不活跃的内存页换出后，即使后续内存变得充足，Swap 中的旧内容也不一定立刻回到物理内存。因此只看到 Swap 已使用，不能直接判断当前正在频繁交换。
更重要的是观察交换活动：
vmstat 1 10输出中的 si 和 so 分别反映换入与换出。持续出现较高交换活动，同时系统响应变慢、磁盘等待上升，才说明内存压力正在影响业务。
不要在余量不足时直接执行 swapoff -a。这个操作需要把交换页搬回物理内存，空间不够时可能加重故障。是否调整 Swap 大小与 swappiness，应结合工作负载和内核行为判断。
检查有没有发生OOM
物理内存和可用 Swap 无法满足分配时，内核可能触发 OOM Killer 终止进程。检查本次启动以来的内核日志：
journalctl -k | grep -iE 'out of memory|oom-killer|killed process'也可以使用：
dmesg -T | grep -iE 'out of memory|oom-killer|killed process'如果日志明确记录某个进程被终止，就不能再把问题解释成正常缓存。此时要确认是谁申请了大量内存、是否存在容器上限、数据库缓存是否配置过大，以及故障前业务负载是否异常。
重启只能释放当时的占用，不会消除导致 OOM 的配置或代码原因。 若同一进程反复被终止，应先处理增长来源，再考虑扩容。
不要习惯性清理缓存
网上常见的 drop_caches 操作会让内核丢弃可回收缓存。Linux 内核文档明确说明，这个接口主要用于测试和调试，并不用于控制缓存增长；执行前还可能需要先同步脏页。
清理后面板里的已用内存会暂时下降，但接下来的文件读取需要重新从磁盘完成，反而可能降低性能。只要 available 足够、没有持续 Swap 抖动和 OOM，缓存通常应该由内核自行管理。
如果缓存异常大，应继续判断它来自普通文件页面、tmpfs、共享内存还是特定工作负载，而不是把所有缓存都当作可以随时删除的垃圾。
什么时候需要优化或扩容
出现以下组合时，扩容更有依据：
MemAvailable长期处于低位vmstat持续发生换入换出- OOM 日志重复出现
- 核心进程已完成合理限额和配置优化
- 业务高峰仍然缺少安全余量
扩容前先计算基础服务、数据库、缓存和并发请求的大致需求。小型站点只看 CPU 套餐，很容易选到内存余量过小的配置。需要长期稳定运行时，可以在 萤光云 这类提供多地区云服务器的平台选择合适规格；业务负载还没稳定时，LightNode 的小时计费更便于逐档验证实际占用。选择哪种计费方式都应以监控数据为依据。
如果只是单个服务没有限制，也可以先调整数据库缓冲池、Java 堆、PHP-FPM 进程数或容器内存上限。设置过小会频繁重启，设置过大又会挤压系统空间，修改后要观察完整业务高峰。
修改后的验收标准
优化或扩容后，至少观察一个完整高峰周期。确认 MemAvailable 保持安全余量、Swap 没有持续抖动、OOM 日志不再增加，并且接口延迟和数据库响应没有恶化。
同时保留进程级监控，避免总内存看起来稳定，但某个服务仍在缓慢增长。真正的恢复不是面板数字变绿，而是内存压力、交换活动和业务响应同时恢复正常。
常见问题
Linux内存使用率90%一定要扩容吗？
不一定。先看 MemAvailable、Swap 活动、OOM 日志和业务响应，缓存占用高可能完全正常。
buff/cache可以直接清理吗？
不建议作为日常优化手段。内核会按需回收可回收缓存，强制清理可能让后续磁盘读取变慢。
为什么重启后内存很低，运行几天又升高？
可能是文件缓存逐渐建立，也可能是进程持续增长。对比进程 RSS 和业务流量趋势才能区分。
没有Swap会更快吗？
不能一概而论。Swap 可以为短时压力提供缓冲，但频繁交换会影响性能，是否启用和大小要结合工作负载决定。
