ps aux --sort=-%mem 最直接查看进程内存占比，%MEM 列即进程 RSS 占系统总物理内存（MemTotal）的百分比，不包含 swap 和 buffers/cache，精度高于 top 的实时采样值。
ps aux --sort=-%mem 看进程内存占比最直接
Linux 中没有“某个进程占系统总内存百分比”的独立统计项，但 %MEM 列就是你要的答案：它等于该进程的 RSS（常驻物理内存）除以系统 MemTotal，再乘以 100。这个值在 ps 和 top 中都真实存在，不是估算。
执行以下命令可立即看到内存占用前 10 的进程：
ps aux --sort=-%mem | head -n 11
注意：head -n 11 是为了保留表头 + 10 条数据；--sort=-%mem 的负号表示降序。输出中 %MEM 一列就是每个进程对系统总物理内存的占用百分比。
-
%MEM基于/proc/meminfo中的MemTotal计算，不包含 swap，也不扣减 buffers/cache - 如果某进程显示
%MEM为 12.5，说明它独占了约 1/8 的物理内存（比如总内存 16GB，它用了约 2GB RSS） - 该值会随系统
MemTotal动态变化（如热插拔内存、cgroup 限制等场景下可能被缩放）
为什么 top 按 M 排序后 %MEM 和 ps 不完全一致？
现象：你在 top 里按 Shift+M 排序，发现某进程 %MEM 是 9.3，但用 ps aux --sort=-%mem 查出来是 9.1 —— 这不是 bug，而是采样时机和字段精度差异导致的。
-
top默认每 3 秒刷新一次，%MEM是基于当时瞬时RSS和MemTotal计算，且只保留一位小数 -
ps是快照式命令，无刷新，计算更“静态”，默认显示两位小数（可通过ps -o pid,%mem,rss,comm自定义格式） - 两者底层都读
/proc/[pid]/statm和/proc/meminfo，但top内部做了四舍五入和单位归一化处理
排查时优先信 ps 的结果，尤其做自动化判断（比如告警脚本）；交互式观察用 top 更直观。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
不要把 RSS 当成“真实内存开销”
RSS（Resident Set Size）常被当作进程实际占内存的指标，但它有严重误导性：
-
RSS包含共享库的物理页 —— 多个进程共用同一个libc.so，这部分内存会被重复计入每个进程的RSS -
RSS不排除被内核标记为“可回收”的 pagecache 映射（如 mmap 读文件），这些页随时可能被踢出 - 容器或 cgroup 环境下，
RSS可能被 memory.limit_in_bytes 截断，此时%MEM会虚高
真正反映进程“不可共享、不可回收”内存压力的，是 PSS（Proportional Set Size），需用 cat /proc/[pid]/smaps_rollup | grep Pss 查看，但大多数发行版默认不启用 smaps_rollup，得先确认内核配置是否打开 CONFIG_PROC_PAGE_MONITOR。
free -h 的 available 字段才是内存是否真紧张的关键
很多人盯着 free 输出里的 used 值猛增就 panic，其实只要 available 还剩 10% 以上，系统基本不会 OOM。这是因为：
-
used = total − free − buff/cache，而buff/cache中大量是可回收的 pagecache -
available是内核估算的“此刻立刻能分配给新进程的内存”，已扣除不可回收部分（如 active file cache、内核 slab 等） - 当
available持续低于 5%，swap开始频繁使用，kswapdCPU 升高，这才是内存瓶颈信号
所以查进程内存只是第一步；最终要交叉验证：ps 找大户 → free -h 看 available 是否告急 → cat /proc/meminfo | grep -E "^(MemAvailable|SwapCached|SReclaimable)" 看可回收空间是否充足。
