ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

一文摸清Linux服务器配置:CPU核数、内存与硬盘容量查询全解

一文摸清Linux服务器配置:CPU核数、内存与硬盘容量查询全解 刚接触Linux的朋友十个里有九个第一句话会问“这台机器到底啥配置”尤其是你刚接手一台服务器、准备做扩容评估、或者排查某个服务为什么卡顿第一步都得先把CPU核数、内存总容量、硬盘总容量这几个家底摸清楚。这三个数字可以说是Linux运维里最基础、也最高频的“体检指标”几乎所有的性能分析和容量规划都是从它们开始的。我记得自己第一次做服务器交接时候对着屏幕一头雾水。网上给的答案特别多——有说用lscpu的有说看/proc/cpuinfo的还有说free -m、df -h、fdisk -l的。但真正用起来就会发现工具之间显示的结果经常对不上比如free显示的内存比标称少一截df看到的容量又和硬盘标称差一大块。这篇文章不打算只丢给你几条命令完事而是想把“为什么看”“看哪个”“怎么解读连带坑”一次讲透让你以后在任何发行版上都能快速摸清一台Linux机器的底细。1. 为什么要先摸清这三个数字以及它们彼此之间的坑1.1 这三项参数决定了什么CPU核数、内存总容量、硬盘总容量这三个数字基本勾勒出了一台机器的“体力上限”。CPU核数决定的是并行处理能力核数越多同时能跑的线程就越多Web服务并发、编译任务、数据处理这类场景都会直接受益内存总容量决定的是“能同时装多少活儿”因为进程运行需要把代码和数据加载进内存内存不够就会触发Swap整个系统慢得像爬硬盘总容量则决定“能留下多少东西”这也是所有数据落盘和日志保存的基础。对于运维和开发者来说这三项不只是“了解一下”的静态数字它们还是更高级操作的前提。比如你打算给这台机器部署Kubernetes节点节点建议配置通常直接对标CPU核数和内存大小你写定时任务时内存不足的机器要考虑曲线策略你规划日志清理周期和备份策略也要先明确硬盘总容量才能定阈值。可以说这三个数字就是一台Linux机器的“入场券”拿到手之后后续所有性能评估、故障排查和容量规划才有依据。另外一个容易被忽略的点是这三项参数直接影响软件许可证和计费逻辑。很多商业软件按CPU核数或物理CPU颗数授权云服务器也是按vCPU核数和内存GB数结算硬盘容量更是按GB或TB直接出账。所以不管是自建机房还是云上环境把这些数字查准不只是技术需求也关乎预算评价。这也是为什么“看清楚”比“大致知道”重要得多。1.2 别把“看见”当成“看全”命令选型的基本盘有个很常见的误区就是以为只有一条“万能命令”能搞定所有查询。其实Linux里每个命令的设计视角都不太一样。拿硬盘来说df看到的是“文件系统视角”lsblk看到的是“块设备视角”fdisk -l看到的是“分区表视角”三者数据来源不同输出口径也不同。把它们混为一谈势必越查越糊涂。我用下来比较受用的思路是先定位问题的“层次”再选工具。CPU层的核数查询最常用的是lscpu和/proc/cpuinfo一个偏概要、一个偏明细内存层的总容量查询free和/proc/meminfo最直观dmidecode能追加硬件物理信息硬盘层的容量查询lsblk、fdisk -l和df各有分工分别对应设备绑定关系、分区表和文件系统已用空间。这篇文章的节奏也按照这个分层来走先是CPU再是内存最后是硬盘。每一层我都把高频命令、输出解读和容易掉进去的坑一起讲清楚最后再给一个能直接落地的一键巡检脚本。这样你以后遇到任何一台陌生机器都能用一套固定的“套路”快速出结果。2. CPU核数物理核、逻辑核和超线程的握手2.1 先搞懂物理核、逻辑核和超线程的关系查CPU核数的时候最让人头疼的就是“核数”这个词到底指什么。我们日常听到的“8核16线程”说的是物理核心为8个、逻辑处理器为16个。物理核心是CPU硬件上真实存在的计算单元逻辑处理器则是操作系统调度时看到的可并行执行单位。这里面的关键是超线程Hyper-Threading技术——它让每个物理核心可以同时维护两个线程上下文操作系统于是“看到”两倍于物理核心的逻辑处理器。所以如果你用不同命令去查得到的结果可能是4、8、16这样的不同数字这并不代表哪个命令错了而是它报告的维度不同。比如lscpu里的“CPU(s)”默认是逻辑处理器总数而“Core(s) per socket”是每个插槽上的物理核心数。搞清楚自己到底需要哪个数字、该怎么换算比背命令重要得多。对于容量评估场景我个人的习惯是物理核数决定硬性算力逻辑核数决定并发调度能力。如果是纯计算密集型的程序逻辑核比物理核翻倍并不能带来线性性能提升如果是IO密集或多线程混跑场景逻辑核能帮上大忙。所以报告配置时最好把“物理核x线程”都写清楚比如“16核32线程”别人一听就明白。2.2 一条lscpu命令看清全貌查CPU核数我首推lscpu。这个命令在几乎所有主流发行版里都预装了输出是整理过的键值对看起来不累。最常用的场景就是直接执行lscpu然后抓几个关键字段lscpu在一台典型服务器上输出大概长这样Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Platinum 8269CY CPU 2.50GHz Stepping: 7 CPU MHz: 2500.000 BogoMIPS: 4999.99 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 33792K NUMA node0 CPU(s): 0-15这里有几行需要重点看。首先是“CPU(s): 16”这一行是逻辑处理器总数也就是我们常说的“线程数”。其次是“Thread(s) per core: 2”它说明每个物理核心跑两个线程也就是说超线程是开着的。再次是“Core(s) per socket: 8”这是每个CPU插槽上的物理核数。最后是“Socket(s): 1”代表机器里有1颗物理CPU。把最后三行乘一下Socket(s) × Core(s) per socket × Thread(s) per core 1 × 8 × 2 16正好等于“CPU(s)”说明这台机器的逻辑核数就是16。如果“Thread(s) per core”显示为1那逻辑核数就等于物理核数说明超线程没有开。这个换算关系是查核数时最核心的公式建议直接记在脑子里。2.3 其他常用查看方式nproc、proc文件与top除了lscpu还有几个命令也经常被用来查核数各有适用场景。nproc这个命令特别简洁不加参数时输出逻辑处理器数量只有一行数字非常适合在脚本里直接引用。比如在Shell脚本里我经常写max_parallel$(nproc)然后拿这个变量控制编译任务的并行度。需要限定某任务的并行数低于逻辑核数时还可以用nproc --ignore4来排除一定数量的处理器。/proc/cpuinfo则是很多人喜欢直接cat的文件里面记录了每一颗逻辑处理器的完整信息。查总核数最经典的做法是grep -c processor /proc/cpuinfo统计“processor”这一项出现的次数得到的就是逻辑核总数。如果还想看物理核数可以按physical id分组去重再用core id统计不过这些操作在lscpu出现之后显得有点繁琐。总的来说日常快速确认就用nproc要详细解读硬件能力用lscpu要确认特别底层的信息再用/proc/cpuinfo。top或htop也值得一提。你运行top之后按数字“1”屏幕上方会展开每个CPU核心的负载行这些核心条目其实就是逻辑处理器。当超线程开启时这里会看到双倍于物理核的条目。这个方法适合“眼见为实”地感受核数尤其在确认运行状态时特别直观。2.4 实操心得怎么判断超线程是否真的开启有时候只给一个“核数”指标是不够的尤其是排查性能问题时你要知道超线程到底有没有发挥出来。这时候最直接的判断方式就是看lscpu里Thread(s) per core的值。如果这个值是2那就说明开启了超线程如果是1那就是关闭状态。另一种验证办法是查看/proc/cpuinfo里siblings和cpu cores这两项。siblings表示同一物理核心上的兄弟线程数cpu cores表示物理核心数。如果两者相等说明没超线程如果siblings是cpu cores的两倍则说明超线程开启。举个例子某个CPU条目里siblings是16、cpu cores是8那明显就是8核16线程。实际运维中还有个小坑有些云服务器供应商会在虚拟化层面对CPU信息做“阉割”或伪装lscpu里可能只看到逻辑核数Threads per core显示为1。这不代表超线程被关闭只是虚拟机没有透传相关特性。遇到这种情况不要慌按“可用逻辑核”来看待即可因为容器或虚拟机里你真正能调度的就是显示出来的这些核。3. 内存总容量free -h背后的四种数字3.1 free -h输出逐列拆解查内存总容量首选的命令是free而且我习惯加上-h参数让输出变成人类友好的单位。命令如下free -h输出样例total used free shared buff/cache available Mem: 7.6Gi 1.1Gi 986Mi 12Mi 5.5Gi 6.2Gi Swap: 2.0Gi 0B 2.0Gi这里第一行“Mem”下面的total就是当前系统能使用的内存总容量。它和物理内存标称值之间通常有差异。比如买的是8GB内存的机器free显示可能是7.6Gi左右这是因为系统启动后有一部分被内核、硬件保留区占用以及一部分被显卡等设备映射掉。这个偏差在内存总容量报告里属于正常现象。第二行“Swap”下面的total是交换分区总容量。Swap是硬盘上划出来当“溢出内存”用的区域如果内存不够系统会把暂时不用的数据挪到Swap里。查询内存总容量时最好把Mem total和Swap total一起看因为它们共同决定系统的“可用内存水位”。很多新人只盯Mem不看Swap结果内存吃紧时根本不知道还有Swap在兜底。3.2 /proc/meminfofree命令的数据源头如果你想知道free的数据是从哪里“读”来的可以看一眼/proc/meminfo。free的本质就是解析这个虚拟文件。执行cat /proc/meminfo输出里最关键的一行是MemTotal它就是free工具里total的来源。比如MemTotal: 7973312 kB换算一下约7.6GB正好对应free -h里的7.6Gi。/proc/meminfo的价值在于它保存的是内核最原始的内存统计视角字段比free丰富得多。比如MemAvailable表示“在不触发Swap的情况下还能给新程序分配多少内存”这个数字对于判断系统还能不能扛住新负载特别有价值。free -h里的available列就来自于这里。在排查内存泄漏、缓存回收等问题时直接看/proc/meminfo里的MemFree、Buffers、Cached、Slab等字段会比看free更有抓手。3.3 补充视角dmidecode与物理内存条信息free看到的只是“操作系统视角”如果你连物理内存条的品牌、频率、插槽数量也要知道那就需要另一个工具——dmidecode。它直接读取主板的DMI信息能告诉你每个内存插槽上插了多大容量的条子、运行频率是多少。命令是sudo dmidecode -t memory在输出里重点看Type: DDR4、Speed: 2666 MT/s以及每个Memory Device下的Size字段。比如Size: 8 GB连看几条就能拼出整机物理内存的组成比如“两条8GB共16GB”。这个信息在做硬件故障排查和扩容采购时非常有用。不过要注意dmidecode需要root权限而且虚拟机环境里能读到的信息有限。云主机里往往会直接屏蔽掉这些物理硬件信息所以如果你在ECS上执行发现内容很少很正常不是你的命令有问题。遇到这种情况就用free和/proc/meminfo就足够了。3.4 实战为什么总显示内存比标称少我经常被问到的一个问题是明明买了16GB内存为什么free看到的只有15.6Gi其实这里有两层原因。第一层是内存单位换算的“营销坑”。内存厂商按1GB1000MB来标称容量而操作系统按1GiB1024MiB来计算所以16GB标称换算成GiB后本身就约等于14.9GiB。第二层是硬件保留和系统保留内核在启动时会占用一部分物理内存用于页表、DMA区域等核显或GPU也会划走一部分共享显存。这两层叠加结果就是free显示的数字必然小于标称容量。从经验看标称16GB实际显示在15.5GiB到15.8GiB之间都算正常。如果你看到少了一两个GB那大概率是被核显或某些硬件预留占掉了。遇到这种“缩水”不用太紧张它是Linux内存体系里的正常现象。反过来如果你从/proc/meminfo里看到MemTotal比标称还大那反而要检查是不是有内存超卖或者配置异常。4. 硬盘总容量一个容量其实有三个“面”4.1 三个命令看三个层次lsblk、fdisk -l、df -hT硬盘总容量是三个指标里最容易让人晕的。同一个“8TB硬盘”用不同命令查出来可能都是差不多的“8TB”但用df看已用空间时数字又会少一截。这背后的原因很简单硬盘容量有块设备层、分区表和文件系统层三层视角。我最推荐的一线入门命令是lsblk。它显示的是所有块设备的树状结构能清楚地看到硬盘、分区以及它们之间的从属关系。执行lsblk输出通常长这样NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 447.1G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 446.1G 0 part └─centos-root 253:0 0 446.1G 0 lvm /其中sda这行就是物理硬盘SIZE显示的是块设备总容量sda1、sda2是分区下面的centos-root是LVM逻辑卷它来自sda2这个分区。lsblk的最大优点就是一眼看清“哪块盘是哪个挂载点的爹”在做磁盘规划时分外好用。fdisk -l则更偏传统它直接读取分区表。在磁盘管理的操作场景里你创建、删除分区后都需要用partprobe或重启来刷新然后通过fdisk -l来确认分区表状态。如果你只是像查容量这样的轻量需求fdisk -l的一些输出反而偏长而且部分发行版里查看非root用户需要加sudo不如lsblk清爽。df -hT则是“文件系统视角”的容量查询工具它看的是已经格式化并挂载的文件系统还有多大空间、用了多少。执行df -hT输出的第一列Filesystem、第二列Type是文件系统类型第三列Size是总容量第四列Used是已用空间第五列Avail是剩余空间最后一列Mounted on是挂载点。这里显示的容量是文件系统层面的总容量通常会因为文件系统元数据开销而略小于分区容量。4.2 实际容量汇总RAID、LVM、多盘和挂载点查硬盘总容量时最怕的就是只数“一块盘的标称”或者只按df的输出直接相加。在真实的生产环境里硬盘容量汇总存在好几个变数。第一个变数是RAID。硬件RAID卡或软RAID会把多块物理盘聚合成一个逻辑卷操作系统里看到的只有聚合后的总容量。比如四块4TB盘做RAID 5可用容量大约是12TB左右而不是16TB因为有一块盘的容量用来做校验了。如果底层做了RAID你在系统里用lsblk看到的盘名往往是组名或虚拟设备而不是物理盘名。第二个变数是LVM。Linux的逻辑卷管理可以把多个分区或整块盘放进卷组再按需切成多个逻辑卷。这种情况下df看到的通常是每个逻辑卷的容量而lsblk或pvdisplay才能看出整个卷组的磁盘总消耗。汇总容量时要把所有卷组、物理卷的占用都算进去不能只看某一个挂载点。第三个变数是多块盘与多个挂载点。一台Web服务器可能系统盘是80GB数据盘是2TB备份盘是1TB。如果我只执行df -hT然后把第一行Size加起来就会漏掉大量未挂载或未使用的分区容量。正确做法是先lsblk看有哪些物理盘再df -hT确认哪些文件系统已经挂载最后把未使用的裸盘或新分区也算进“总容量”里。4.3 实战新硬盘真实容量排查案例给你说一个我实际遇到过的场景。某次新接手一台存储服务器管理员交接文档上写的是“4TB总容量”。但现场df -hT看到根分区只有不到200GB数据盘也只有2TB。初步一看觉得像是“低配机器”。后来我用lsblk检查才发现机器上实际插了两块4TB的硬盘其中一块被做了LVM物理卷卷组里还有大量未分配空间另一块甚至还没有分区。那次排查给我的教训很深判断一台机器的硬盘总容量一定要按“物理块设备层”去盘点也就是先lsblk再看分区和逻辑卷最后看文件系统挂载情况。为了快速得到完整容量我习惯用lsblk -do NAME,SIZE看所有磁盘的原始总容量再用lsblk看分区和挂载点对应关系。这样既能拿到“总家底”又能知道每块盘的“钱花在哪儿了”。如果你需要给领导或客户报告我建议最终只给两个数物理总容量和可用逻辑卷总容量。前者是lsblk看到的所有磁盘SIZE之和后者是df -hT看到的各挂载点Size之和中真正可用部分。这两个数一个代表硬件投入一个代表业务可用说清楚之后就不会产生误会。5. 从查到用写一个一键巡检的极简脚本5.1 组装信息输出CPU、内存、硬盘这三部分信息每次手动敲来敲去确实有点低效。我自己后来干脆写了个极简脚本把它固化下来。这个脚本不需要安装额外依赖只要系统里有lscpu、free和lsblk就能跑。它的思路是先定义几个标题函数用来分区显示然后分别抓取CPU核数、内存总容量和硬盘总容量最后统一打印。#!/bin/bash # 一键查看 Linux 主机基础配置 echo CPU 信息 lscpu | grep -E ^CPU\(s\):|^Thread\(s\) per core:|^Core\(s\) per socket:|^Socket\(s\):|^Model name: echo echo 内存信息 free -h | awk /^Mem:/{print 内存总容量: $2} free -h | awk /^Swap:/{print Swap总容量: $2} echo echo 硬盘信息 lsblk -d -o NAME,SIZE,MODEL echo --- 分区与挂载情况 --- lsblk -o NAME,SIZE,TYPE,MOUNTPOINT5.2 脚本说明与扩展思路脚本里的lscpu部分直接抓取了几个关键字段避免输出过长free部分用awk只提取了Mem和Swap的total硬盘部分先用lsblk -d只列出物理盘、不列出分区快速看清“总家底”再打印完整的分区和挂载树状结构。这个脚本跑完后同一屏内就能看到CPU型号、物理核数、逻辑线程数、内存总容量、Swap总容量以及所有硬盘设备与挂载点。我在接手新机器时通常先跑它一遍然后再根据具体场景决定要不要进一步用dmidecode或fdisk -l深挖。你也可以在这个基础上改造比如把输出追加到日志文件、加上时间戳或者用mail命令把结果发到邮箱做成每日巡检快照。对一个“看看配置”的需求来说脚本的价值不在于炫技而在于稳定复现。每次都用同一套命令、同一个视角看同一批机器能避免因为临时记错命令、少加参数等低级失误导致的信息误判。这也是运维工作里“流程化”的价值体现——宁可机械化不要拍脑袋。6. 常见问题与排查技巧实录6.1 常见问题速查表我在整理这篇文章时把平时遇到最多的问题汇总成了一张速查表方便你有需要时快速对号入座。问题现象可能原因推荐排查命令核数显示比预期少一半超线程未开启或虚拟机限定了vCPUlscpu看Thread(s) per core内存total与标称差异大硬件保留、核显占用、单位换算free -h、/proc/meminfodf的Size总和小于硬盘标称文件系统元数据、未挂载分区、LVM未分配lsblk、pvdisplay某块盘在lsblk里看不到未通电、RAID未组、驱动未加载lspci、lsscsi、dmesg挂载点容量满了但物理盘还有空间分区规划不合理或LVM未扩展df -hT、lsblk、lvextend新装系统后Swap为0初始化时未设置swap分区free -h、swapon --show这张表里没有提到太冷门的场景都是日常最容易被问到的。拿“df的Size总和小于硬盘标称”来说我遇到最典型的场景就是数据盘做了LVM但逻辑卷只分配了一半空间df只看得到逻辑卷剩下的空间就“消失”了。解决思路是先lsblk确认物理卷再用vgs看卷组剩余空间最后执行lvextend和resize2fs扩展文件系统。整个链条如果不完整走一遍问题很难定位。6.2 排查原则与经验心得回顾这么多年的操作我最想强调的一点是永远不要只凭单个命令的输出下结论。CPU要结合lscpu和/proc/cpuinfo交叉确认内存要看free和/proc/meminfo互为补充硬盘要形成“lsblk → fdisk -l → df -hT”三层联查习惯。因为每个工具都有它的盲区只有多层数据对齐之后你才有底气断定一台机器的真实配置。再分享一个小技巧在查看配置前先确认自己用的是不是容器或虚拟机。如果是Docker容器lscpu和free显示的数据基本来自宿主机不能代表容器本身可用的资源限制如果是虚拟机lscpu里的Hypervisor vendor会明确写出来此时你看到的配置是虚拟化层“透传”出来的。带了这个前提再去看数字思路会清晰很多。最后如果你刚接触Linux不久建议你在一台自己可控的机器上把文中这些命令挨个执行一遍对照本文的字段讲解逐行看输出。这比背命令有效得多。等你能一眼看懂lscpu、free -h和lsblk的输出时你离“熟悉Linux”这个目标就已经跨过了一大步。后面再做性能分析、故障排查就会顺手很多。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进