我接手过不少服务也帮同行排查过几次故障。有个很典型的场景客户说服务器卡得厉害让帮忙看看登录上去第一件事就是确认这台机器到底有几个核、多少内存、硬盘多大。本来以为一句话的事结果发现不少人在这上面栽过跟头——不是命令记不全而是把输出看错了。比如以为/proc/cpuinfo里processor有多少个物理核就有多少个或者看到free -h显示的内存总容量比标称小了一大截直接慌了。这篇文章就把这三件事彻底讲透从命令到原理从输出解读到实战坑点一次说清楚。这篇适合刚接触Linux的运维新手、准备面试的技术人员以及所有需要快速摸清服务器配置的人。我不打算只丢几个命令给你那没什么意义。关键是把每个命令背后的逻辑讲明白这样换一台机器、换一个场景你都知道该怎么查、怎么看、怎么判断结果靠不靠谱。1. 为什么要手动查看这些信息从一次故障排查说起说个我自己的经历。有次处理一个性能问题应用层各种慢开发那边一口咬定是服务器配置不够说要申请加资源。我上去一看CPU核数确实不多内存也看着吃紧硬盘好像也快满了。当时差点就被带偏了直接写报告申请扩容。后来仔细一看发现是另一个服务把CPU跑满了和配置没什么关系。这里有个教训如果你连“这台机器真实配置是多少”都说不准排查问题等于蒙着眼睛走路。还有一类场景是资产管理。公司几百台服务器型号不同、时期不同配置五花八门。你想统计一下总共多少个核、多少内存总不能一台台开机箱看吧在云环境里更麻烦——你买的是4核8G的云主机可实际分配到你的容器里的资源到底是多少只有登录进系统看才能拿到真实数据。再有就是新接手项目的时候。老员工交接说这台机器配置很高随便跑。你接手了总得自己确认一下吧。靠嘴说没用拿到系统里实际的数字才靠谱。像lscpu、free、df、lsblk这些命令就是最快、最准的核实手段。这些场景背后有一个共同点你需要的不是“大概多少”而是“精确到多少”。CPU是几核几线程内存是总容量多少、可用多少硬盘是物理盘多大、文件系统可用多少。这些东西在系统里都真实记录着只是你需要知道去哪看、看哪个字段。下面我按CPU、内存、硬盘三个方面分别展开每个部分都会把命令列出来把关键字段的含义讲清楚最后再补上我实际使用中踩过的坑。2. CPU核数从/proc/cpuinfo到lscpu的完整解读2.1 先区分两个概念物理核与逻辑核查CPU核数之前必须先搞清楚一个基本问题你要的“核数”到底是什么。一台物理机上CPU是插在主板上的一颗CPU叫一个“物理封装”通常也叫一个Socket。每一颗CPU内部有多个物理核心叫做物理核。而操作系统看到的往往是“逻辑核”或者叫“逻辑CPU”。这中间的差额就是超线程Hyper-Threading技术带来的——一个物理核可以被系统识别为两个逻辑核为了充分利用计算单元。打个比方。物理核就好比一个厨师超线程就是这个厨师左右手各拿一把铲子同时炒两口锅。对客人来说他一个人顶两个人用但他毕竟还是一个人。CPU的算力并非两个逻辑核就等于两倍的物理核可能只提升20%-30%。所以在判断“这台机器够不够用”时物理核数更加重要逻辑核数则决定了操作系统层面能并发跑多少线程。这就是为什么很多人栽跟头的地方看到系统里显示的CPU数量很多以为性能很强。实际上可能是超线程虚增的数字。2.2 lscpu命令最直接、最准确的查看方式在绝大多数Linux发行版上lscpu都是最省事的查询方式。它从系统信息中收集CPU相关的所有数据并整理成易读的表格。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: 142 Model name: Intel(R) Core(TM) i7-8550U CPU 1.80GHz Stepping: 10 CPU MHz: 998.400 ...重点看几个字段CPU(s)逻辑CPU总数也就是操作系统看到的执行单元总数。Thread(s) per core每个物理核有几个线程也就是超线程的比例。如果是1说明没有开启超线程如果是2就是开了超线程。Core(s) per socket每个物理CPU封装上有几个物理核。Socket(s)插槽数也就是物理CPU颗数。它们的关系是逻辑CPU总数 Socket数 × 每颗CPU物理核数 × 每个物理核的线程数用上面这个例子验证1 × 4 × 2 8。和CPU(s)显示的8一致。所以这台机器的物理核是4个逻辑核是8个。如果要论“真正的计算能力”说4核比较实在如果说“系统并发能力”可以说8线程。2.3 /proc/cpuinfo的字段为什么processor不能直接当物理核数lscpu本质上读取的也是/proc/cpuinfo的数据只是做了汇总。/proc/cpuinfo是虚拟文件系统/proc里的一个文本文件记录着系统启动时探测到的每个逻辑CPU的详细属性。直接用cat查看也没问题但信息量很大通常配合grep使用。grep -c ^processor /proc/cpuinfo这条命令会统计以processor开头的行数得到的就是逻辑CPU总数。很多人会在这里犯一个错误以为这个数字就是物理核数。如果你在一台开启了超线程的机器上执行会发现返回8但物理核其实只有4个。所以这条命令统计的是逻辑核不是物理核。想进一步确认物理核数和CPU颗数需要看physical id和core id两个字段grep physical id /proc/cpuinfo grep core id /proc/cpuinfophysical id表示这个逻辑CPU属于哪一颗物理CPUcore id表示它属于那颗CPU上的哪个物理核。理论上统计唯一的physical id数量就是CPU颗数统计唯一的physical id core id组合数量就是物理核总数。不过说实话在生产环境里我不太推荐手动去数这些字段又麻烦又容易错。直接用lscpu就完了。了解/proc/cpuinfo的存在是为了让你理解lscpu的来源出了问题的时候知道该去哪里排查。2.4 nproc与taskset当前进程能用几个核还有一个命令叫nproc很多人容易忽略。nproc直接输入返回的就是当前shell可用的处理器数量。这个值通常等于逻辑CPU总数但在某些受限环境比如容器、cgroup限制了CPU配额中它会反映实际可用的数量。nproc --all加上--all显示的是所有逻辑CPU数量不受cgroup限制影响。这里有个常见场景你在容器里跑服务用nproc发现只有2但lscpu显示主机是8核。这时候不要慌是容器配额限制了你只能用2个核不代表你的程序只能跑2个线程但调度器确实只会让你用到这么多。排查容器资源问题的时候nproc比lscpu更接近真实可用的情况。另外如果你只想知道某个具体进程跑在哪个CPU上可以用tasksettaskset -cp PID它会输出该进程允许使用的CPU列表。做性能分析时这个信息能帮你确认进程是否被绑核了绑得合不合理。2.5 查看CPU核数的避坑经验我在实际使用中遇到的坑基本集中在三点第一把逻辑核当物理核。这个前面说过了判断性能上限时容易误判。特别是买云主机、选物理服务器时销售说的“8核”可能指逻辑线程也可能指物理核一定要问清楚。在Linux系统里lscpu里的Core(s) per socket和Socket(s)才是准确的物理核信息。第二容器里看到的核数不对。你在一台8核宿主机上起了个容器限制只能用2个核。进入容器执行lscpu有的环境依然会显示宿主的8核有的会显示2核取决于运行时和内核版本。判断容器内可用资源的可靠依据是nproc以及cgroup里的cpu.max或cpu.cfs_quota_us配置。第三NUMA架构下核数分布。大型服务器会有多个NUMA节点lscpu输出里会包含NUMA node(s)和每个节点对应的CPU列表。做性能优化时尽量让进程的内存分配和CPU执行在同一个NUMA节点上避免跨节点访问带来的延迟。这个细节如果前期没注意后面压测的时候性能会差得离谱。3. 内存容量free、/proc/meminfo与单位换算的坑3.1 free命令最常用的内存查看工具查看内存容量第一反应基本都是free。free -h输出的样子total used free shared buff/cache available Mem: 7.6Gi 2.1Gi 1.2Gi 245Mi 4.2Gi 5.1Gi Swap: 2.0Gi 0B 2.0Gi这里的关键是看懂几列total内存总容量。used已使用的内存。free完全空闲的内存。shared共享内存主要是tmpfs之类的文件系统用掉的。buff/cache用于缓存和缓冲的内存这部分虽然被占用但可随时释放给应用程序使用。available真正可用的内存它是free加上可回收的buff/cache。很多新手看内存只盯free那列觉得内存快没了吓得不行。实际上buff/cache是大功臣Linux会尽量把空闲内存用作缓存来提高性能应用需要时再释放。所以判断内存够不够优先看available。容量的单位也需要注意。free -h里的Gi是Gibibyte吉比字节也就是1024进制的GiB而硬盘厂商和很多云厂商习惯用GB十进制1GB1000MB。所以free -h显示7.6Gi实际相当于8GB左右但不会正好等于标称8GB。这不是系统“吃了”内存而是单位换算差异。如果习惯用MB来看可以执行free -m用兆字节为单位显示更直观total used free shared buff/cache available Mem: 7776 2157 1233 245 4385 5224 Swap: 2047 0 20473.2 /proc/meminfo与dmesg查询物理内存的另一种方式free的数据来源实际上是/proc/meminfo。直接查看这个文件字段更完整cat /proc/meminfo开头几行MemTotal: 7959808 kB MemFree: 1263352 kB MemAvailable: 5349876 kB Buffers: 23588 kB Cached: 4197880 kB SwapCached: 0 kB ...MemTotal就是总内存单位是kB。注意这里的kB是1024字节的KiB和前面说的单位问题一样。如果你想查物理内存条的信息比如有几个内存插槽、每个插槽多大、什么频率free就无能为力了。这时候用dmidecodesudo dmidecode -t memory输出很长重点看Size字段和Locator字段。如果某根内存条没插Size会显示No Module Installed。这个命令在排查物理机内存故障、确认是否双通道、统计整机内存容量时非常实用。不过dmidecode需要root权限而且虚拟机环境下看到的信息可能是虚拟化软件模拟出来的不完全等于真实物理内存条信息。云主机尤其如此。3.3 为什么内存总容量看起来比标称小很多人刚接触服务器时会发现一个现象买的是16GB内存free -h显示total只有15Gi甚至更少。第一反应是系统有问题、被偷了。其实原因不复杂。一是单位换算。标称的16GB是十进制的GB系统里显示的是二进制的GiB。16GB除以1.024的三次方约等于14.9GiB。二是硬件保留。集显会占用一部分内存作为显存BIOS或固件也会保留一部分。尤其集成显卡的机器显存共享内存占用多少取决于BIOS设置和驱动。云主机如果配置了显卡直通或GPU实例也会有一部分内存被保留。三是内核预留。内核本身和早期启动代码需要占据少量内存MemTotal是系统可用物理内存已经减去了这部分。所以正确的心态是物理内存容量以dmidecode和系统dmesg里的信息为准操作系统层面能用的MemTotal作为一个动态值。两者有差异只要差异不大5%以内基本都是正常现象。3.4 查看内存的避坑经验遇到内存相关的问题我总结了几条经验第一不要只看free列。free列小不代表内存不够。真正要看的是available。如果available持续见底swap用得越来越多那才是真的紧张。第二注意swap和内存的关系。Swap是磁盘上的交换分区内存不足时把不常用的内存页换到磁盘。它只是“急救包”性能远不如物理内存。如果发现系统大量使用swap应用响应变慢那是内存告急的信号不是swap越大越好。第三云主机查内存要加上容器视角。你买了8G内存的云主机但里面跑了很多容器每个容器占用一部分。宿主机内存够不代表容器内够。排查的时候一层层看宿主机free、容器free、进程top缺一不可。第四total这个数值在虚拟化环境里可以变得很虚。有些超卖严重的云平台宿主机内存不足时会开启内存气球balloon机制动态调整虚拟机可用内存。你会发现free里的total并不稳定甚至会变化。遇到这种情况直接找云厂商确认资源规格比自查更靠谱。4. 硬盘容量df与lsblk各有侧重4.1 df命令从文件系统角度看可用空间说到硬盘容量大家最先想到的是df。df -h输出Filesystem Size Used Avail Use% Mounted on /dev/vda1 99G 56G 38G 60% / tmpfs 3.8G 0 3.8G 0% /dev/shm /dev/vdb1 492G 120G 347G 26% /datadf反映的是文件系统的容量和使用率。这里的Size是文件系统总容量Used是已用Avail是可用Use%是使用率。这个命令解决的是“我的磁盘还够不够用”的问题是运维日常最常用的。有个细节需要注意df的Size是文件系统层面的不完全是物理磁盘的大小。比如LVM逻辑卷、RAID磁盘阵列、云盘经过文件系统格式化后都会有一些元数据开销。所以Size通常比对应的块设备容量略小。100GB的磁盘文件系统大小可能是99GB左右这是正常的。-h选项是human-readable自动选择合适的单位。也可以用-T查看文件系统类型df -Th输出会多一列Type显示ext4、xfs、overlay等文件系统类型。这个信息在后续排障时很有用比如overlay是Docker容器典型的文件系统挂载方式。4.2 lsblk命令从块设备角度看物理盘容量如果说df是“文件系统的视图”那lsblk就是“块设备的视图”。它列出的是系统中所有的磁盘和分区以及它们之间的挂载关系。lsblk输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 100G 0 disk └─vda1 253:1 0 100G 0 part / vdb 253:16 0 500G 0 disk └─vdb1 253:17 0 500G 0 part /dataTYPE为disk的是物理磁盘part是分区。SIZE显示的是块设备大小这里是十进制的GB。lsblk能让你一眼看出机器挂了几块盘、每块盘多大、分成了几个区、分别挂载到哪里。如果想看更详细的信息包括磁盘型号、序列号、传输类型可以加-d参数lsblk -d -o NAME,SIZE,MODEL,SERIAL,TRAN这在资产管理时很有用能直接列出物理盘信息。那为什么df看到的和lsblk看到的不一样因为层不一样。lsblk看到的是磁盘和分区df看到的是建立在分区之上的文件系统。中间还可能隔着LVM、RAID、加密层。所以两块盘做了RAID 1lsblk看到两块都是1TB但实际可用空间只有1TBdf看到的总容量也是1TB。看物理硬盘总容量和逻辑可用容量的区别就在这里。4.3 查看硬盘总容量的正确姿势如果问题是“这台机器物理硬盘总共多大”答案是所有disk类型设备的SIZE之和。lsblk就能直接回答。如果问题是“我能用的存储空间有多少”答案是df里各自挂载点的Size之和排除tmpfs、loop设备这类虚拟文件系统。这里有个很常见的坑很多服务器会用LVM做逻辑卷管理。lsblk输出里会有lvm类型的设备比如NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part └─vg_data-lv_root 253:0 0 99G 0 lvm /这种情况下物理盘是sda100GB被分成两个分区其中一个分区用作LVM物理卷再划给逻辑卷lv_root挂载到根目录。df看到的就是逻辑卷的容量lsblk能看到LVM的层级关系。4.4 为什么df显示的和厂商标注的容量差很多还有一类高频疑问买了500GB云盘lsblk显示容量不足500Gdf显示更小。原因有几层最外层是单位差异。操作系统通常用二进制单位显示GiB云厂商和硬盘厂商用十进制GB。500GB的标称容量在lsblk里显示为465.7G这很正常任何硬盘都这样。中间层是文件系统元数据。创建文件系统时会预留一部分空间给inode、文件系统日志、块位图等。ext4一般默认预留5%给root用户用于防止磁盘写满导致系统无法启动。这部分可以从tune2fs -l /dev/vdb1里查看到。最内层是备份和快照。云盘做快照时快照也会占用存储池空间但一般不会影响你看到的块设备容量。不过如果你用的是本地盘某些RAID级别如RAID 5、RAID 6会用一部分容量做校验可用容量会进一步缩水。所以查看硬盘总容量用lsblk看块设备查看实际可用空间用df两者结合才能对存储状况有完整认知。4.5 查看硬盘容量的避坑经验第一别在根目录挂载点一查就说“磁盘满了”。df -h看到/满了先看是不是有东西在被删除文件仍被进程占用。lsof | grep deleted能看到这类情况。系统不会自动释放但很多时候重启进程就好。第二云盘扩容后别忘记扩文件系统。云平台面板上把云盘从100G扩到200G系统里lsblk看到的是200G了但df看到的还是原来的大小。因为分区表和文件系统还没扩展。需要依次执行growpart如果分区也需要扩和resize2fsext4或xfs_growfsxfs。这个顺序反了会直接报错。第三虚拟机里df可能看到虚拟磁盘小但lsblk里能看到物理机直通的整块盘。在虚拟化环境里可能存在“磁盘直通”或“虚拟磁盘”两种方式。前者能看到整块物理盘后者只是一个文件。如果发现容量差异极大先确认虚拟化层的磁盘类型不要盲目判断物理磁盘出问题。第四区分个人电脑和服务器。个人电脑里/home和/往往在同一个分区df显示的就是整块硬盘。服务器上可能把数据盘单独挂载到/data、/optdf输出会有多行。统计总容量时把所有挂载点加起来才是合理的逻辑容量总和。5. 把三项信息串起来一条命令与脚本化方案前面把CPU、内存、硬盘分开讲了。但实际工作中我经常要在一分钟之内把一台服务器的大致配置摸清楚有没有一条命令或者脚本能把这三样信息一次性展示出来有。5.1 一条命令快速查看整体配置最简单的做法lscpu | egrep 型号名称|CPU\(s\)|Core\(s\) per socket|Socket\(s\) ; free -h | head -2 ; df -h | grep -v tmpfs把三组命令串在一起执行完基本信息就都出来了。但是这样输出比较粗糙字段名称也不统一。我可以给你一个更完整的组合命令echo CPU ; lscpu | grep -E ^CPU\(s\)|^Model name|^Core\(s\) per socket|^Socket\(s\)|^Thread\(s\) per core; echo; echo MEMORY ; free -h; echo; echo DISK ; df -h -x tmpfs -x devtmpfsdf -h -x tmpfs -x devtmpfs的作用是排除tmpfs和devtmpfs这两类虚拟文件系统只看真实的磁盘挂载点。这是查磁盘容量时的小技巧。不过这样的命令每次都要敲一遍很累。更推荐的做法是写成一个脚本放在服务器上随时用。5.2 写一个sysinfo.sh小脚本这是我个人长期使用的一个简化版本你可以直接抄也可以按需改#!/bin/bash # sysinfo.sh - 快速查看服务器CPU、内存、硬盘配置 echo 主机信息 hostname uname -r echo echo CPU lscpu | grep -E ^CPU\(s\)|^Model name|^Core\(s\) per socket|^Socket\(s\)|^Thread\(s\) per core echo 物理核总数: $(lscpu | awk -F: /^Core\(s\) per socket/{cores$2} /^Socket\(s\)/{sockets$2} END{print cores*sockets}) echo echo 内存 free -h echo echo 硬盘 lsblk -d -o NAME,SIZE,MODEL,TRAN echo df -h -x tmpfs -x devtmpfs保存后加执行权限chmod x sysinfo.sh sudo ./sysinfo.sh这个脚本的价值在于每次初始化新服务器时把输出保存下来作为资产记录的一部分。后面再做配置变更也有据可查。5.3 脚本化解决了什么问题我为什么强调脚本化因为人肉敲命令有两个问题一是容易漏看字段二是输出不统一无法对比。比如你有一批机器都是“8核16G 500G”的规格。怎么验证如果一台台登录敲命令不仅慢而且每个人的命令还不一样有人说“8核”指逻辑核有人说指物理核。写脚本统一输出格式所有机器跑同一个脚本结果才能放在一起比较。配合ssh批量执行的效果更佳for host in 192.168.1.10 192.168.1.11 192.168.1.12; do echo $host ssh $host bash -s sysinfo.sh done这样一轮下来整批服务器的配置一目了然。虽然现在有一些自动化运维平台能做到类似的事但掌握这个基本功在你手头只有几台机器、没有现成平台的时候非常管用。5.4 进阶把信息输出为JSON方便程序处理如果你稍微懂一点脚本可以尝试把信息转成JSON格式方便后续接入监控系统或自建的资产管理平台。简单示例如下#!/bin/bash # sysinfo-json.sh cpu_info$(lscpu -J | jq -c .lscpu | map({(.field): .data}) | add) mem_total$(free -b | awk /Mem:/{print $2}) disk_info$(lsblk -J -d -o NAME,SIZE,MODEL | jq -c .blockdevices) echo {\cpu\: $cpu_info, \mem_total_b\: $mem_total, \disks\: $disk_info}实际使用中建议用Python写更规范毕竟JSON拼接容易出错。这里只是给一个有编程基础的朋友一个思路方向和示例。核心逻辑不变从系统文件或标准命令中读取数据再按需格式化。6. 几个容易翻车的细节服务器信息查看答疑汇总最后这部分我把这些年遇到的高频问题集中回答一下。有些问题看着简单但真到关键时候卡壳了就很耽误事。6.1 processor编号是连续的物理核数就一定是这个数吗不一定。上面已经详细解释过processor是逻辑CPU的编号不是物理核编号。在开了超线程或者NUMA拓扑复杂的机器上物理核数少于processor的最大编号加1是常有的事。判断物理核可以用lscpu那才是正规渠道。如果非要看/proc/cpuinfo就看每个CPU条目里的physical id和core id组合统计唯一组合数。6.2 内存的GB和GiB到底差多少1GB 1000 × 1000 × 1000 字节 10^9 字节 1GiB 1024 × 1024 × 1024 字节 2^30 字节换算关系GB GiB × 1.073741824也就是说1 GiB约等于1.074 GB。标称8GB的内存换算过来是7.45 GiB。再加上硬件保留free -h显示7.6Gi甚至7.4Gi都是正常的。不要看到这个数字比标称小就疑神疑鬼换算一下心里就有数了。6.3 df显示根目录快满了但lsblk里磁盘还有空间为什么要么是根目录所在的分区比较小其余空间分给了别的分区要么是同一个卷组里逻辑卷分配不均。先用df -h找到各个挂载点的使用率再用lsblk看分区结构。最常见的场景是数据盘和系统盘分开买根目录50G数据盘100G/快满了但数据盘空着。这种情况不是空间不够是布局不合理。处理方式是把数据迁移到数据盘上或者用LVM重新分配空间。6.4 云主机上查到的信息能用吗能用但要理解云主机的特殊性。云主机看到的CPU和内存是宿主机分配给你的虚拟化资源它的值和你在云平台控制台上看到的规格一定是对应的。如果发现lscpu显示的物理核数和买的不一样先别急着质疑厂家——虚拟化层本来就会做资源抽象。比如你买了4核虚拟机上看到的可能是1个Socket、1个Core per socket、4个Threads per core。这种情况在云环境中很常见代表的是1个vCPU对应宿主机上一个物理核心的超线程不影响正常使用。磁盘方面云盘通常以网络块设备的形式挂载lsblk里的设备名可能是vda、vdb、sda、sdb。容量以控制台显示的为准系统里看到的会比标称值小一点点单位换算导致。如果扩容后系统里没生效参考前面说的growpart和文件系统扩容流程。6.5 查看这些信息时哪个命令必须rootdf、lsblk、free、lscpu都不需要root普通用户就能看。dmidecode需要root或者sudo因为它读取的是BIOS/DMI信息属于底层硬件数据。fdisk -l也需要root。如果你权限不够优先用lsblk和cat /proc/meminfo这两个是无权限压力的查询方式。6.6 排查问题时CPU、内存、硬盘应该按什么顺序看我的习惯是先看负载再看资源瓶颈最后才看配置。具体来说先用uptime看load average判断系统整体忙不忙再用top或htop看CPU使用率、内存使用率最高的进程然后用df -h看磁盘空间最后用iostat看磁盘IO。配置信息并不是第一步就要查的除非你明确知道要评估容量、升级配置。很多人一上来就用lscpu、free、df查看配置结果配置没问题问题出在满跑的进程上。顺序反了排查效率低很多。把基础命令用熟配合正确的排查思路才能事半功倍。回到开头说的那个故障案例。那年我最后是怎么处理的先确认了CPU、内存、硬盘的真实情况发现配置并不低再看进程发现有个定时任务脚本异常把CPU打满了。砍掉异常任务系统立马恢复正常。整个过程如果缺少第一步对配置的准确判断很可能就误判成“资源不足”不仅问题没解决还白白花了一笔扩容的钱。Linux系统里的这些查看命令看起来基础但每一个都对应着真实场景里可能出现的坑。把命令敲出来是门槛最低的一步搞清楚输出背后的含义才是真正有用的技能。希望这篇内容能帮你少踩几个坑。