linux内存占用高不等于有问题，关键看available是否低于物理内存10%且是否触发oom或服务变慢；cached高属正常缓存，可用时无需干预；需用top/htop按res排序定位异常进程，结合日志与dmesg排查oom原因，再针对性优化。
Linux内存占用高不等于有问题，关键看是否影响服务响应或触发OOM。先别急着杀进程或重启，重点区分“真实占用”和“系统缓存”，再定位异常来源。
看懂内存指标：别只盯着free
运行 free -h 时，重点关注 available 列，不是 free。Linux会把空闲内存自动用于 page cache 和 buffers，这部分可随时回收，属于“可用但暂存”。如果 available 远低于物理内存的10%，且应用开始变慢或日志出现 “Out of memory: Kill process”，才说明真缺内存。
- cached 高通常正常，尤其在有大量文件读写或数据库场景下
- buff/cache 占比大但 available 充足 → 无需干预
- used 接近 total 且 available 持续趋零 → 需深入排查
定位高内存进程：用对命令排序
运行 top，按 Shift+M 按 RES（实际物理内存占用）降序排列。关注 RES 值高、且长时间不释放的进程。也可用更直观的 htop（需安装），支持鼠标操作和颜色高亮。
- 记下 PID 和 CMD，结合 ps -o pid,ppid,vsz,rss,comm -p [PID] 查看虚拟内存（VSZ）与实际驻留内存（RSS）
- 对 Java/Python 等语言程序，RSS 高可能意味着堆内存泄漏或配置过大
- 注意 zombie 进程虽不占内存，但大量存在常反映父进程异常，需一并检查
查日志与后台服务：容易被忽略的源头
有些内存增长缓慢，靠 top 快照难捕捉。用 journalctl -u [service] --since "2 hours ago" 查看关键服务日志，留意 OOM killer 日志：dmesg -T | grep -i "killed process"。
- 检查 systemd 启动的服务是否重复启动或未正确退出（如定时脚本 fork 多个实例）
- 确认 logrotate 是否失效，导致巨型日志文件被进程持续 mmap 加载
- 数据库（如 MySQL、PostgreSQL）连接数暴增或查询未加 limit，也会推高 RSS
针对性优化与临时缓解
确认问题进程后，根据类型选择处理方式。切忌直接 kill -9，优先尝试优雅终止或限流。
- 应用类进程：调整 JVM -Xmx 或 Python 的 gc 设置；限制 Nginx worker_rlimit_nofile / worker_connections
- 清理不可回收缓存（仅应急）：echo 3 > /proc/sys/vm/drop_caches（需 root，且效果短暂）
- 长期方案：配置 systemd MemoryMax 限制服务内存上限，或用 cgroups v2 管控资源
- 加监控告警：用 Prometheus + node_exporter 抓取 memory_available、process_resident_memory_bytes 等指标，设阈值预警
不复杂但容易忽略：多数“内存高”其实是预期行为，真正要防的是 RSS 持续增长、available 归零、OOM 杀进程这三类信号。抓准指标，再动手，省时又稳妥。
