直接运行top后按大写M键可按%MEM降序实时排序，内存占用高的进程排最前；注意区分小写m（单位切换）和P（CPU排序），-o %MEM在新版top中有效但缩写不支持。
用 top 按内存排序看实时占用
直接运行 top，默认按 %CPU 排序，但你要的是内存 —— 按下 M 键（大写 M），进程列表会立刻按 %MEM 降序排列，内存吃得多的排最上面。注意别误按成小写 m（那是切换内存显示单位），也别和 P（CPU）混淆。
常见误区：有人以为 top -o %MEM 能一次性启动就排序，但在 CentOS 7 默认的 top 版本（procps-ng 3.3.10）里，-o 参数不支持字段名缩写，必须写全：top -o %MEM 是有效的，但 top -o mem 或 top -o RES 会失败并退回默认排序。
-
RES列是实际物理内存（KB），比%MEM更适合横向比较绝对值 -
VIRT包含已分配但未使用的虚拟内存，不能反映真实压力 - 按
u键可输入用户名，快速过滤某用户所有进程，避免被系统进程干扰
用 ps 批量导出内存数据做分析
如果要导出、筛选或写脚本处理，ps 比 top 更可控。关键不是记一堆参数，而是盯住两个字段：rss（驻留集大小，单位 KB）和 vsz（虚拟内存大小，单位 KB）。
执行：ps aux --sort=-%mem | head -n 10 可快速列出内存占比前 10 的进程；但注意：%mem 是浮点数，ps 默认只保留小数点后一位，排序精度有限。更稳的方式是按 rss 排：ps -eo pid,user,%mem,rss,comm --sort=-rss | head -n 10。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
-
--sort=-rss中的负号表示降序，正号升序 -
comm只显示命令名（如java），args会显示完整命令行，但可能换行或截断 - 别用
ps aux | grep xxx查特定进程的内存 ——grep自身也会出现在结果里，多一行干扰；改用pgrep -f "xxx" | xargs -r ps -o pid,%mem,rss,comm -p
free 和 top 显示的 “可用内存” 不一致？
这是最容易困惑的点：free 输出里的 available 字段，和 top 里所有进程 RES 加起来的总和，数值差得远 —— 这不是 bug，是设计使然。
available 是内核估算的、能立即分配给新进程的内存，它扣除了不可回收的内核开销、预留页、以及部分 buffers/cache（并非所有缓存都能秒级释放）。而 top 的 RES 是每个进程当前“占着”的物理页，包含共享页（比如多个 Java 进程共用的 JVM 库），会被重复计算。
- 所以别用
sum(RES)去验证free的used或available—— 两者统计口径不同 - 真正判断是否内存紧张，看
free的available是否持续低于总内存 10%，以及Swap的used是否增长 -
top左上角的MiB Swap: xxx used比free更早暴露交换区启用迹象
为什么 ps 看到的 RSS 总和远超物理内存？
这不是内存泄漏，是 Linux 内存管理的正常现象。核心原因是：RSS 统计的是进程独占 + 共享页的“引用计数”，不是物理页的实际去重后大小。
例如一个用了 200MB 共享库的进程，和另一个同样加载该库的进程，各自 rss 都算 200MB，但物理内存只存一份库代码 —— ps 不做去重，smaps 才有精确的 MMUPageSize 和 RSS 分解。
- 想看某个进程的真实内存开销，查
/proc/<pid>/smaps</pid>里的RssAnon（私有匿名页）和RssFile（私有文件映射页），加起来才是它“净占”的物理内存 -
ps的vsz更容易虚高 —— 它包含已 malloc 但未 touch 的内存页（lazy allocation），这些页还没真正分配物理内存 - 容器环境下（如 Docker），
ps显示的是宿主机视角，需结合cgroups的memory.usage_in_bytes才准
RES 高，但 available 还剩 30%，说明问题不在总量，而在局部分配不均或碎片；%MEM 看着低，但 Swap 在涨，那可能是大量进程在抖动式申请/释放内存，触发了内核的换页逻辑。 
