Linux无统一“吞吐占比”指标，需分网络、磁盘、内存层分别计算：网络用nload/iftop测速率并除以实测网卡上限，磁盘用iostat对比物理介质理论值，内存用perf或pcm-memory.x测MB/s后除以CPU规格书中的最大带宽。

Linux 没有“吞吐占比”这个统一指标——它必须拆解到具体资源层：网络、磁盘、内存各自独立，且“占比”需要你手动提供基准值（如网卡标称带宽、磁盘顺序写上限、内存理论带宽）才能算。直接跑 top 或 free 得不到任何占比。

查网络吞吐并估算带宽占比

真实吞吐看 iostat -x 是磁盘的事，网络得用别的工具。nload 显示的是瞬时速率，但“占比”要你自己填分母：

• nload -u M 输出的数值单位是 Mbps（兆比特每秒），不是 MB/s；若网卡是 1Gbps，满速是 1000 Mbps，看到 850 就约等于 85% 占比
• iftop -B -n -N 的 TX/RX 列默认是 bytes/s，需换算：显示 12500000 ≈ 12.5 MB/s ≈ 100 Mbps → 占 1Gbps 网卡的 10%
• 别信 ethtool eth0 的 “Speed: 1000Mb/s” 就是实际可用带宽——TCP/IP 栈开销、中断处理、驱动队列都会吃掉 5–15%，实测能到 900 Mbps 已算良好
• 容器或云环境（如 AWS ENA、阿里云 ENS）的虚拟网卡标称值常虚高，真实上限得靠 iperf3 测，否则占比全是错觉

查磁盘吞吐并对比理论带宽

iostat -xk 1 给出的 rMB/s 和 wMB/s 是绕过 page cache 的真实设备吞吐，但“占比”取决于你手头那块盘的物理能力：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• SATA SSD 顺序写通常 500–550 MB/s，看到 wMB/s 长期卡在 540，基本就是 98% 占比；NVMe PCIe 4.0 x4 盘理论 6–7 GB/s，500 MB/s 只占 7–8%
• avgrq-sz × r_ios × 512 ≈ rkB/s × 1024？如果偏差大（比如算出来是 800 MB/s，但 rMB/s 才 200），说明有压缩、去重、RAID 缓存或 NVMe 多队列分流，此时“占比”失去意义
• %util 不是利用率百分比，而是队列非空时间占比；%util 100% + await > 50ms → 真瓶颈；%util 30% 但 rMB/s 已达上限 → 是 IO 模式（随机小包）或介质本身慢，不是队列堵

查内存带宽并确认是否打满

Linux 内核不暴露内存带宽占比，/proc/meminfo 里的数字全是用量或缺页统计，和字节传输速率无关：

• 用 perf stat -e uncore_imc_00/event=0x04,umask=0x0f/,uncore_imc_00/event=0x05,umask=0x0f/ -I 1000 -a sleep 5 抓读/写字节数，再除以时间 → 得 MB/s；再除以 CPU 规格文档里的 Max Memory Bandwidth（如 51.2 GB/s）才是占比
• pcm-memory.x 1 直接输出 MEM READ/MEM WRITE（GB/s）和顶部的 Max Memory Bandwidth，两者相除即占比，但仅限 Intel 且需匹配平台版本
• 多通道内存下，perf 默认只采 socket 0；要全量，得手动枚举 uncore_imc_00 到 uncore_imc_03 并求和，否则占比严重低估
• NUMA 节点跨访问会触发隐性带宽竞争——pcm-memory.x 显示总带宽 80%，但节点 0 的程序可能已跑满其本地通道，此时单看全局占比会误判

真正麻烦的不是怎么算，而是“基准值”从哪来：网卡标称值常被虚标，磁盘顺序带宽在随机负载下毫无参考价值，内存理论带宽在 NUMA+多通道混合访问时根本无法线性叠加。不测不准，不查规格手册不算。