top按%mem排序时看不到rss绝对值，因为默认不显示res列；需按f启用rss字段才能同时查看百分比和kb数值，否则无法判断200mb还是2gb等实际内存开销。
top 按 %MEM 排序时为什么看不到 RSS 绝对值？
因为 top 默认字段不强制显示 RSS 列，只保证 %MEM 可见。它反映的是该进程占用物理内存占系统总内存的百分比，不是 KB/MB 数值——所以即使排序靠前，你也无法直接判断是 200MB 还是 2GB。
要同时看到百分比和绝对值，启动 top 后按 f 进入字段管理界面，用方向键选中 RSS（通常标为 “RES”），按空格启用，再按 q 返回。此时列头会出现 RES，单位是 KB，可直观对比实际内存开销。
-
%MEM对多核或大内存机器敏感：一台 128GB 内存的服务器上，%MEM5% ≈ 6.4GB；而 4GB 小内存设备上 5% 才 200MB - 按
M（大写）排序后，top仍每 3 秒刷新一次，但排序逻辑只在刷新时生效，中间手动滚动不会改变顺序 - 若目标进程未出现在前几页，可用
/键搜索进程名（如输入java），匹配行会高亮，再按n跳转下一处
ps aux --sort=-%mem 输出里 RSS 和 %MEM 不一致怎么办？
ps 的 %MEM 是根据 RSS / MemTotal × 100 实时计算的，而 MemTotal 来自 /proc/meminfo，不含内核保留内存或热插拔未识别部分。所以当你看到某进程 RSS 是 1.2GB、%MEM 却只有 1.8%，说明系统报告的 MemTotal 约为 66GB——这可能是开启了 hugepages、kdump 预留，或存在硬件保留内存。
验证方式：运行 grep MemTotal /proc/meminfo，将输出的 KB 值除以 1024² 得到 GB，再用 RSS ÷ 该值 × 100，结果应与 %MEM 基本吻合（误差 ≤ 0.1% 属正常浮点舍入）。
- 避免用
ps aux | sort -k4nr替代--sort=-%mem：前者按第 4 列（即%CPU）排序，极易误判 - 加
--no-headers可去掉表头，方便脚本解析；但首次人工排查建议保留表头，防止列错位导致读错RSS或%MEM - 如果
ps aux --sort=-%mem | head -5中出现多个[kthreadd]或[rcu_gp]，不用紧张——内核线程的%MEM是按单个线程算的，实际共享内核内存，不能累加
想查某个服务（比如 nginx）的精确内存，只用 ps grep 会漏掉子进程吗？
会。ps aux | grep nginx 只匹配命令行含 “nginx” 字符串的进程，但 nginx 主进程可能派生出多个 worker 进程，其 COMMAND 显示为 nginx: worker process，而 master 进程是 nginx: master process——两者都含 “nginx”，一般不会漏；但若启用了 systemd 的 slice 隔离或容器化部署，worker 可能被重命名或隐藏在 cgroup 下，grep 就不可靠了。
更稳妥的做法是先获取主进程 PID：pgrep -f "nginx: master"，再用 ps --ppid $PID -o pid,%mem,rss,comm 查所有直系子进程。或者直接看整个进程组：ps -g $(ps -o sid= -p $(pgrep -f "nginx: master") | tr -d ' ') -o pid,%mem,rss,comm。
- 不要依赖
ps aux | grep nginx | grep -v grep：末尾的grep进程本身也会被匹配到，造成干扰 - systemd 管理的服务优先用
systemctl status nginx.service，其中 “Memory:” 行给出的是 cgroup 级汇总值，比单个ps更真实 - 容器环境（如 docker）必须进容器 namespace 查，宿主机上的
ps看不到内部进程，或显示 PID 1 以外的异常值
free -h 显示 available 充足，但 top 里却有进程占满 %MEM，矛盾吗？
不矛盾。free 的 available 是内核估算的“当前可立即分配给新进程”的内存，已扣除了 page cache、slab、buffers 等可回收部分；而 top 的 %MEM 分母是 MemTotal，分子是该进程独占的 RSS（不含共享页）。一个进程 RSS 高，只说明它锁定了大量物理页，不代表系统真的没内存了——只要 available > 0，且 swap 未触发，就不算内存瓶颈。
真正危险的信号是：free 中 available 持续 SwapUsed 显著增长、top 里频繁出现 zombie 进程或 OOM killer 日志（dmesg | grep -i "killed process"）。
-
/proc/[pid]/status中的VmRSS和ps的RSS值基本一致，但VmSize（虚拟内存）可能远大于它——别拿VmSize当真实开销 -
smem -s rss -r比ps更公平：它用PSS（Proportional Set Size）统计共享内存分摊值，适合多进程共用库的场景（如 Java 应用集群） - 别迷信 “%MEM 最高就一定有问题”：数据库缓存、JVM 堆、Redis 实例等本就是内存密集型设计，重点看是否持续增长、是否触发 GC 或 swap
