接手一台 Linux 服务器之后最难回答的问题往往不是这个命令怎么用而是我的服务器现在到底行不行。尤其是当业务反馈接口变慢、报警群开始刷 CPU 告警、磁盘使用率持续走高的时候你会发现自己需要在一分钟内回答三个问题CPU 是否超负荷内存是不是不够了磁盘还有没有救这不是靠直觉能回答的。Linux 提供了一系列资源查看命令其中最基础、也最常用的就是 lscpu、w、top、free、df。很多人对它们停留在知道名字的程度真到排查问题时却分不清 load average 高是 CPU 的问题还是 IO 的问题分不清free里内存被 cache 占用到底算不算不够用也分不清df -h还有空间为什么应用却报磁盘已满。这篇文章会把五个命令拆开讲透。不会只贴手册而是从输出里每一行在说什么讲到真实排障时怎么组合使用最后给出一套可以直接落地的排查顺序。看完之后你至少能做到服务器变慢时不再毫无章法地乱敲命令。1. 为什么这几个命令必须放在一起学单独学 lscpu、w、top、free、df 中的任何一个都像是在背单词。它们真正有价值的时候是被组合起来回答一个完整问题当前这台服务器的资源瓶颈到底在哪。在多数的实际故障中瓶颈不是单一维度的。某个 Java 服务内存泄漏会导致进程频繁 Full GCCPU 飙升同时把 swap 吃满某个日志目录写爆磁盘会拖动整个文件系统变慢进而让数据库连接超时某个定时任务瞬间拉起几十个子进程会直接拉高 load average即使 CPU 和内存都还有余量。如果只靠单一命令你很可能把问题定性错。把五个命令放在一起学底层逻辑是三条链路CPU 链路CPU 型号、核数、架构决定执行能力w/top 的 load average、%Cpu(s)行决定执行压力。内存链路物理内存大小、buffer/cache 占用、swap 使用情况决定内存是否紧张。存储链路磁盘分区剩余空间、挂载点使用率、inode 余量决定写入是否正常。在排查阶段应该先看整体再看细节。lscpu 解决机器什么配置w 解决系统当前负载大概什么水平top 解决哪个进程在消耗资源free 解决内存还剩多少真正可用df 解决磁盘能不能继续写入。这五个命令刚好组成自顶向下的排查骨架。对后端开发、运维工程师、SRE、以及正在准备 Linux 相关面试的读者来说这套骨架不只是会敲命令更是一套可复用的故障排查方法论。2. 性能排查前的三个基本概念进入命令详解之前有三个概念必须先说清楚否则后面对输出内容的判断都会失真。2.1 什么是系统负载Load Averageload average 是 Linux 系统负载的标准度量英文直译是平均负载。它的含义是在特定时间窗口内处于可运行状态和不可中断状态的进程平均数量。通俗理解可以把 CPU 想象成一个银行柜台。每个进程都是一个需要办业务的客户load average 就是正在柜台前办理业务的客户 排队等待的客户的平均人数。如果人数长期超过柜台数量就意味着客户需要排队系统处理速度会下降。为什么 load average 有三个值因为 w 和 top 会同时显示 1 分钟、5 分钟、15 分钟的平均负载。三个值一起看可以判断负载是瞬时现象还是持续趋势。这一点在后面会详细展开。2.2 user、system、iowait 与 CPU 时间top 命令中的%Cpu(s)行会显示 us、sy、ni、id、wa、hi、si、st 等指标。这里最重要的三类ususer用户态 CPU 时间占比。应用程序自己代码执行、JVM 运行都算在这里。sysystem内核态 CPU 时间占比。系统调用、内存管理、进程调度等内核操作算在这里。waiowaitCPU 等待 I/O 完成的时间占比。比如进程在等待磁盘读取返回这期间 CPU 无事可做就计入 iowait。很多新手把所有 CPU 问题都归结为us 高但这其实是片面的。如果一个进程发生频繁的磁盘读写wa会很高CPU 本身并没有在干活而是在等磁盘。此时盲目加 CPU 核心数没有意义真正要做的是优化磁盘 I/O 或减少读写次数。2.3 物理内存、虚拟内存与 swap物理内存就是服务器上的 RAM。虚拟内存是操作系统对内存的抽象每个进程都认为自己拥有独立连续的地址空间。swap 是磁盘上划分出来的一块空间在物理内存不足时充当慢速内存。Linux 的习惯和 Windows 不同它会积极地把空闲物理内存拿来做文件缓存cache而不是让内存白白空着。这就导致很多人运行free时看到used很高、free很低以为是内存泄漏。其实这种理解是有偏差的。Linux 中可用内存的正确口径是available列而不是free列。这三个概念是后续所有命令输出的基础。接下来逐个命令拆解。3. lscpu先搞清楚机器的 CPU 是什么水平lscpu 是最容易被忽略的命令。很多人排查性能问题时一上来就敲 top却忽略了这台机器到底有几个物理核、几个逻辑处理器。这个信息直接决定你对负载数值的判断。3.1 lscpu 输出里每一行是什么意思在终端执行lscpu后典型输出如下不同系统和虚拟化环境下数值会不同本文以教学场景为例$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 158 Model name: Intel(R) Core(TM) i7-7700HQ CPU 2.80GHz Stepping: 9 CPU MHz: 2800.000 BogoMIPS: 5616.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K NUMA node0 CPU(s): 0-7关键字段解读字段含义为什么重要ArchitectureCPU 架构常见 x86_64、aarch64决定能否安装某些二进制软件CPU(s)逻辑 CPU 总数判断并行能力的表面口径Thread(s) per core每个物理核的线程数超线程开启时为 2Core(s) per socket每个 CPU 插槽的物理核数物理核才是真实执行单元Socket(s)CPU 插槽数即物理 CPU 颗数区分单路/双路服务器Model nameCPU 厂商型号和主频判断处理器代际和性能NUMA node(s)NUMA 节点数大内存数据库调优时需要关注这里有一个重要公式逻辑 CPU 总数 Socket(s) × Core(s) per socket × Thread(s) per core本例中就是1 × 4 × 2 8。云服务器场景下CPU(s)通常对应云厂商分配的 vCPU 数量但底层可能是共享物理核也可能是超线程核。不同云厂商的实现方式不同不能仅凭CPU(s)判断你独享了多少物理资源这一点在争抢型实例上尤其明显。3.2 实际使用场景判断服务器适不适合上高并发服务假设你准备把一个 Nginx 网关部署到新机器上Nginx 官方建议的worker_processes auto会按照逻辑 CPU 数启动 worker。执行lscpu看到CPU(s): 8说明网关可以充分利用 8 个逻辑处理器。反过来假设你用 lscpu 看到Thread(s) per core: 2说明开启了超线程。超线程带来的收益并不是翻倍的通常只能提升 15% 到 30% 的吞吐量。如果你的应用是计算密集型比如视频编码、科学计算那么真正重要的是物理核数而不是线程数。此外lscpu 的数据来源是/proc/cpuinfo和 sysfs 中的 CPU 拓扑信息。少数虚拟化环境下Model name可能显示为空或者被虚拟化层遮蔽这个问题会在第 9 节常见问题中单独讲。4. w看一眼系统负载和谁在登录w 命令的全称是 who is logged in and what are they doing但它最有价值的输出其实在第一行load average。$ w 10:23:45 up 30 days, 2:15, 2 users, load average: 1.20, 0.80, 0.65 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 10:00 2.00s 0.05s 0.01s sshd: rootpts/0 zhangsan pts/1 192.168.1.20 09:30 53:12 1.20s 0.10s -bash第一行从左到右依次是当前时间10:23:45系统已运行时长up 30 days, 2:15表示这台机器已经连续运行 30 天中间没有重启当前登录用户数2 users系统的平均负载load average: 1.20, 0.80, 0.65load average三个值分别是过去 1 分钟、5 分钟、15 分钟的平均负载。判断负载高低不能只看裸数字要结合 lscpu 看到的逻辑 CPU 数。判断口径load average 长期小于 CPU 数系统还有富余处理能力。load average 约等于 CPU 数CPU 接近饱和可能出现轻微排队。load average 持续大于 CPU 数进程在排队系统整体变慢。比如一台 8 核机器load average: 1.20, 0.80, 0.65说明最近 15 分钟平均只有不到 1 个进程在排队负载很低。但如果同样数值出现在 2 核机器上1.20已经超过核数需要关注。三值趋势判断技巧如果1 分钟值 5 分钟值 15 分钟值说明负载正在上升可能是突发流量或异常任务启动。如果1 分钟值 5 分钟值 15 分钟值说明负载正在下降刚才的高峰已经过去。如果三个值非常接近且有规律说明系统处于比较稳定的运行状态。w 第二行开始的表格能看谁在线、从哪个 IP 登录、登录多久、正在执行什么命令。在多人共用的服务器上这条信息很实用当系统负载突然升高时你可以先看是不是有其他同事正在跑一个耗时的构建任务或数据脚本。5. top动态观察 CPU 和进程的全景图top 是这套命令里的主战场。它既能看系统整体资源又能按 CPU 或内存排序定位具体进程。top 默认每 3 秒刷新一次是动态视图。5.1 上半部分系统级统计信息执行top后屏幕上半部分一般长这样top - 10:30:01 up 30 days, 2:15, 2 users, load average: 1.20, 0.80, 0.65 Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie %Cpu(s): 8.3 us, 2.1 sy, 0.0 ni, 89.1 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 15984.5 total, 2058.3 free, 2812.4 used, 11113.8 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 12455.7 avail Mem逐行解读第一行与 w 的第一行类似包含当前时间、运行时长、登录用户数和 load average。第二行 Tasks统计进程总数和状态分布。running表示正在运行的进程sleeping表示休眠等待stopped表示已停止zombie表示僵尸进程。如果 zombie 数量长期不为 0就要留意是不是有父进程没有正确回收子进程。第三行 %Cpu(s)us用户态占用通常来自应用进程sy内核态占用系统调用、驱动、调度等ni被 nice 命令调整过优先级的进程占用id空闲 CPU 比例waI/O 等待hi / si硬件中断 / 软件中断st被虚拟化层偷走的 CPU 时间云服务器上如果 st 长期过高说明宿主机的 CPU 资源争抢严重第四行 Mem物理内存总量、空闲量、已用量、buff/cache 占用量。注意这里的free空闲并不代表真实可用内存因为 buff/cache 在需要时可以被回收。第五行 Swapswap 总量、空闲量、已用量以及最后一行的 avail Mem 真实可用内存。如果 swap 被大量使用说明物理内存已经明显不足。5.2 下半部分进程级列表默认按 CPU 使用率从高到低排序核心列含义列名含义PID进程 IDUSER启动进程的用户PR / NI内核调度优先级 / nice 值VIRT虚拟内存大小RES常驻物理内存大小这是判断内存占用的主要指标SHR共享内存大小S进程状态R 运行、S 休眠、D 不可中断、Z 僵尸%CPUCPU 使用率%MEM物理内存占用百分比TIMECPU 累计消耗时间COMMAND进程名一个常见误区是盯着 VIRT 判断内存占用。实际上 VIRT 包含进程申请但可能从未访问过的虚拟地址空间数值通常远大于 RES。判断物理内存占用首选 RES。5.3 top 交互快捷键top 不是只能看默认视图按下快捷键可以切换信息维度这部分是排查效率的分水岭快捷键作用1展开或合并每个 CPU 核心的使用率P按 CPU 使用率排序M按内存使用率排序T按累计 CPU 时间排序c显示完整命令行k按 PID 结束进程会提示信号类型r调整进程优先级u只显示指定用户的进程q退出比如你怀疑内存泄漏可以按M让进程按 RES 排序观察哪些进程的内存占用一直在上涨。按下1则可以看到每个逻辑 CPU 的独立使用率这对判断多核负载是否均衡很有帮助。5.4 从 top 输出定位问题wa高是一个重要信号。当%Cpu(s)中wa明显偏高比如超过 30% 而us很低时系统的瓶颈大概率在磁盘 I/O 而不是 CPU。此时按P排序不一定能看到明显的 CPU 消耗者因为大家都没有真正在算而是在等磁盘。下一步需要用iostat或pidstat -d进一步确认。st高则是云服务器的特有问题。如果你用的是共享型云主机当宿主机上其他负载较高时你的虚拟机可能被调度器推迟执行表现就是st升高服务响应变慢但你在系统内部看不到任何异常进程。这种时候需要考虑升级到独享型实例或者在业务层增加重试和降级机制。6. free内存不是看 free 列而是看 availablefree是用来查看内存使用概貌的命令。它短小精悍但也最容易产生歧义。6.1 常用形式与输出解读$ free -h total used free shared buff/cache available Mem: 15Gi 2.7Gi 2.0Gi 183Mi 10Gi 12Gi Swap: 2.0Gi 0B 2.0Gi这里的-h表示人类可读格式Gi/Mi。各列含义total物理内存总量。used已被进程使用的内存。free完全空闲的内存。关键点这个数字低不代表内存不够。shared多个进程共享的内存如 tmpfs。buff/cache内核用于缓冲区buffer和文件缓存cache的内存。available估算的、在需要时可以立即分配给新进程的内存大小。Linux 内核会把空闲内存尽量用作文件缓存提升读写性能。这些缓存会在内存紧张时被自动回收。所以真实的可用内存更接近available而不是free。举例来说上面输出中free只有 2.0 Gi看起来内存快用完了但available有 12 Gi说明还有大量可回收的缓存系统并不缺内存。如果只看free值去调度很容易误判。6.2 buffer 和 cache 到底有什么区别虽然新版本 free 已经合并展示为 buff/cache但理解区别仍然有用buffer是对块设备磁盘的缓冲用于暂存写入磁盘的数据。cache是对文件内容的缓存用于加速文件的重复读取。两者都是内核加速 I/O 的手段都是可以回收的。6.3 内存真正告急的信号判断内存是否真的不够用应该看三个信号available 持续走低比如接近 total 的 10% 以下新进程启动可能失败。swap 持续增长说明内存回收也满足不了需求进程被迫使用磁盘交换空间性能会迅速劣化。进程 RES 总和接近 total且出现 OOM 日志系统可能触发 OOM Killer 杀掉进程。在free -h中如果Swap行的used非 0可以进一步用top按M排序找到 RES 最高的进程判断是谁在消耗内存。6.4 不要随手去清 cache网上流传过sync echo 3 /proc/sys/vm/drop_caches这类手动清理缓存的方法。这个操作在生产环境非常不推荐它会强制丢弃页缓存之后的大量读请求反而会退化为磁盘读带来性能抖动。Linux 内核自带的缓存回收机制已经足够成熟available才是内核给出的真实可用口径。手动清缓存通常是心理安慰大于实际收益。7. df磁盘空间看 df但别忘了 inode磁盘问题是线上最烦人的一类问题平时不显眼一旦使用率达到 100%应用写不了日志、数据库落不了盘、临时文件创建失败整个链路都可能雪崩。7.1 df -h 查看磁盘空间使用率$ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 35G 3.3G 92% / devtmpfs 7.8G 0 7.8G 0% /dev tmpfs 7.8G 16K 7.8G 1% /dev/shm tmpfs 7.8G 780M 7.1G 10% /run重点关注挂载在/的根分区使用率。Use%超过 80% 就应该开始规划清理或扩容超过 90% 要立即处理。tmpfs是临时文件系统它占用的其实是内存空间不是真实的磁盘分区。所以df -h看到 tmpfs 使用率增长时要考虑是 /tmp、/dev/shm 下的临时文件占用了内存。7.2 df -i 查看 inode 使用率inode 是文件系统用来保存文件元数据权限、所有者、大小、数据块位置等的数据结构。每个文件或目录都占用一个 inode。磁盘空间还有剩余但 inode 被耗尽时系统同样会报告No space left on device。$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2621440 2621440 0 100% /如果IUse%达到 100%即使df -h显示还有几个 G 空间也创建不了新文件。这种情况通常由大量小文件引起比如临时缓存文件、邮件队列、日志堆积。排查 inode 耗尽问题时可以使用如下命令找到文件数量超多的目录for d in /*; do echo $d: $(find $d -xdev -type f 2/dev/null | wc -l); done注意-xdev限制不跨文件系统避免把/proc、/sys等虚拟目录统计进来。7.3 df 与 du 的配合使用df看到的是文件系统整体使用情况du看到的是某个目录下文件实际占用的块大小。如果df显示根分区使用率很高可以用du定位大目录du -h --max-depth1 / 2/dev/null | sort -hr | head -20这条命令列出根目录下第一层目录的磁盘占用并按大小倒序。通常很快就能找到占用大头比如/var/log、/home、/opt。一个常见困惑是du统计的占用和df显示的占用对不上。原因可能包括文件已被删除但进程仍然持有文件句柄文件系统存在保留块du按目录统计时某些挂载点没有计入。如果文件已删除但空间未释放可以查看是否有进程仍占用lsof L1L1会列出没有链接但仍被进程打开的文件帮助定位删除不生效的问题。8. 组合实战一次服务器变慢的排查过程单独讲完五个命令后把它们串起来走一遍完整排查流程会更接近真实工作场景。假设你收到业务反馈订单查询接口最近变慢整体响应时间从 200ms 涨到 2s。你登录服务器后按下面的顺序操作。第一步用 w 看负载先建立整体感知$ w 11:20:32 up 12 days, 3:10, 3 users, load average: 9.80, 7.20, 5.40从 lscpu 已知这是一台 8 核机器。当前 1 分钟负载 9.80已经超过 8说明 CPU 处理能力吃紧并且三个值梯度上升说明负载越积越高。接下来要用 top 定位是谁在消耗 CPU。第二步用 top 找到 CPU 消耗大户$ top -b -n 1 | head -20-b表示批处理模式-n 1表示只输出一次适合在非交互脚本中抓取快照。输出中看到某个 Java 进程 PID 为 2314%CPU达到 680%RES 达到 6.5G。这台机器总共 16G 内存这个进程已经占掉了接近一半物理内存。第三步用 free 判断内存是否承压$ free -h total used free shared buff/cache available Mem: 15Gi 11Gi 400Mi 180Mi 3.6Gi 4.3Giavailable 只有 4.3G内存已经偏紧。再结合 top 中的进程列表发现除了 2314还有两个内存占用量大的业务进程。第四步用 df 检查磁盘写入是否正常$ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 35G 3.3G 92% /根分区使用率 92%虽然还没写满但如果这个 Java 应用持续写日志空间很可能在几小时内耗尽。综合判断接口变慢的主要原因是 CPU 和内存双双承压磁盘也逐渐接近容量上限。第五步采取临时应急措施在确认 2314 这个进程确实属于可重启的业务模块之后先通过kill -HUP 2314触发一次应用层的配置重载让进程自行释放一部分无用内存。如果还是没有效果再考虑重启。这里给到一个原则没有确认进程身份之前不要随意 kill 进程。生产环境任何杀进程操作都需要走审批和备份流程。组合排查的核心思路是先整体、后局部、再定位到进程最后结合磁盘空间给出临时与长期方案。只要把 w、top、free、df 这条链路跑通多数资源型故障都能在几分钟内定位到大方向。9. 常见问题与排查思路实际使用中以下问题出现频率很高问题现象可能原因排查方式解决方案load average 很高但 CPU 使用率很低进程处于 D 状态等待 I/O或网络等待top 查看 wavmstat 查看 bi/bo定位 I/O 热点优化磁盘读写free 显示内存 free 很少系统却不卡buffer/cache 占用较多available 仍充足free -h 看 available 列无需处理这是正常缓存行为df -h 显示有空间但创建文件报 No space leftinode 耗尽df -i 查看 inode 使用率清理小文件或扩容 inode 数量某个进程 CPU 长期 100%代码死循环、GC 频繁、单线程瓶颈top 确认 PID配合 jstack/perf 分析修复代码调整 JVM 参数lscpu 不展示型号Model name 为空虚拟化平台遮蔽 CPU 信息lscpu 查看全部字段尝试 dmidecode云环境属正常现象以云厂商规格为准top 中看不到某个进程当前用户权限不足或进程已退出使用sudo top再确认需要授权时请遵循最小权限原则zombie 进程数量越来越多父进程未调用 wait 回收子进程ps -ef 检查 PPID定位父进程修复父进程逻辑或重启父进程swap 被大量使用物理内存不足内存回收压力大free -h 结合 top 按 M 排序扩容内存或优化进程内存占用这里单拎出 lscpu 不展示型号的问题多说一句。很多虚拟化平台为了隐藏宿主机信息会在/proc/cpuinfo中把model name置空或直接不暴露。这种情况下 lscpu 显示Model name:后面是空的并不代表机器坏了也不需要过度处理。如果确实需要确认物理 CPU 信息可以尝试dmidecode -t processor但云服务器上这条命令通常也没有权限读取底层信息。另一个值得注意的问题是load average高但 CPU 使用率不高。这个组合很迷惑人它通常说明进程并不是在消耗 CPU而是大量处于D不可中断睡眠状态比如在等待磁盘 I/O 或网络 I/O。此时用top看wa或者用vmstat 1观察wa、bi、bo列比单纯看 us/sy 更有意义。10. 最佳实践与日常监控建议命令本身是事后排查的工具真正稳定运行的系统还需要事前预警。基于这五个命令可以形成一套最小化的日常监控实践。10.1 定期记录关键指标可以在 crontab 中定时把核心指标写入日志保留历史数据*/5 * * * * echo $(date %F_%T) load$(cut -d -f1-3 /proc/loadavg) mem$(free -h | awk /^Mem:/{print $3/$2}) disk$(df -h / | awk NR2{print $5}) /var/log/sys_check.log这条 cron 每 5 分钟记录一次 load average、内存使用、根分区使用率。看着很简陋但故障发生后它能帮你回答最关键的问题指标是什么时候开始异常的。10.2 别只看一个指标要看组合系统排查中最大的坑是单指标归因。CPU 高不一定是要加 CPU可能是大量中断、频繁切换进程、或者 I/O 等待内存不足不一定要立刻加内存可能是某个进程内存泄漏磁盘满了不一定是日志多可能是临时文件没清理。任何单一指标都必须放到组合里交叉验证。推荐的最低组合层面一负载用 w 或 uptime层面二CPU/内存/进程用 top层面三磁盘用 df -h 和 df -i层面四I/O 细节用 vmstat、iostat、sar前三个层面就是本文五命令的职责范围第四个是后续进阶方向。10.3 在自动化脚本中注意输出格式如果要把 top 输出写入文件用-b -n 1指定批处理模式如果要用 awk 解析 free最好用-m固定单位为 MiB避免不同版本输出格式波动。云服务器上脚本要注意存在/usr/bin/free和/proc/meminfo两种数据来源需要时直接读/proc/meminfo更稳定。10.4 安全边界与权限top 中按k可以结束进程kill -9可以强制终止进程这属于高风险操作。任何时候执行 kill 之前都要先确认 PID 对应的进程是否在预期范围内最好先执行ps -p PID -f查看完整命令行。如果进程属于他人业务或共享环境应优先通知相关负责人而不是自己直接 kill。对于涉及生产环境的变更包括清日志、删文件、重启服务一定先检查备份和回滚方案。清日志前使用du -sh *确认目标文件路径无误保留最近 N 天日志再动手。10.5 进一步学习方向这篇文章讲的是资源查看的第一层。真正要成为一名合格的系统排查者建议继续精读以下方向vmstat 1动态观察 CPU、内存、I/O 的队列状态。iostat -x 1深入观察磁盘的利用率、等待时间、队列长度。sar从历史文件中回放系统负载变化。perf和strace从内核角度分析进程卡点。理解 cgroup 和 systemd现代容器环境下资源隔离会改变free和 top 的呈现口径。如果把这篇文章当作一个起点那么你收获的不应该是五个命令的孤立记忆而是一套配置确认 - 负载评估 - 进程定位 - 内存判断 - 磁盘检查的完整方法。下次再遇到服务器变慢你可以先告诉自己问题通常藏在这五个命令组成的雷达图里。