Linux服务器硬件信息速查实操：CPU内存磁盘网卡命令详解

上周同事扔过来一台刚上架的机器，让我确认配置。当时没有监控平台账号，也不方便登带外管理界面，手边唯一的通道就是SSH。我在终端里敲了一串命令，几秒钟后把CPU型号、物理核数、内存插槽、磁盘介质类型、网卡速率和整机序列号全部报了回来。同事有点惊讶，问我是不是把每台设备的参数都背下来了。我说不是记性好，是这几条命令用得太熟了。

这就是服务器硬件信息速查的基本功，也是Linux运维必备命令里最容易被忽略的一块。很多人入职好几年，df、top、ps背得滚瓜烂熟，但突然被问"这台机器内存插了几根条子""网卡是不是降速到百兆了""这块盘用了多少小时"，一下子就卡住。原因不是不知道命令，而是不知道每条命令的输出里哪一列才是真正要紧的。

这篇文章我把日常干活时真正用得到的硬件速查命令捋一遍，覆盖CPU、内存、磁盘、RAID、网卡、整机信息，以及几个只有踩过坑才会注意的细节。每个命令都会解释为什么用它、输出怎么看、现场怎么用，最后还会给一个可以直接抄走的一键汇总脚本。

1. 一台新机器摆到面前，先能"报得出配置"才算接手

1.1 硬件速查不是背命令，是掌握输出里的关键字段

先说一个很多人会走偏的地方。网上搜"Linux查看硬件信息"，能搜出来几十条命令，什么inxi、hwinfo、lshw、dmidecode、lscpu、lsblk、lspci、ethtool……全列出来能写满一页。但实际运维场景里，你不需要把所有命令都装齐，也不需要把命令的所有参数都背下来。

真正要紧的是两件事：第一，知道每个硬件维度该用哪一两条命令；第二，知道命令输出里哪个字段代表什么含义。比如lscpu你只需要看CPU型号、插槽数、每插槽核数、每核线程数，再会算一个"逻辑CPU总数 = 插槽数 × 每插槽核数 × 每核线程数"，这就够了。其他一堆缓存大小、字节序、NUMA节点分布之类，用到的时候再返回来看都不迟。

我自己的习惯是：把硬件速查命令分成三类。第一类是"开口就能报"的，比如CPU和内存总量，几秒钟必须搞定。第二类是"拿工具看一下"的，比如磁盘健康、RAID物理盘状态、网卡协商速率，需要用到厂商工具或额外命令。第三类是"出故障才查"的，比如内存插槽拓扑、PCIe设备ID、固件版本，平时不用记，但排查问题时要能快速查到。

1.2 这篇文章帮你覆盖的硬件维度和判断思路

这篇文章就按这个思路组织。我会先讲CPU，因为最常见也最简单；再讲内存，容量之外还要能看插槽和ECC；然后讲磁盘和RAID，这块最容易被当作普通文件系统命令混过去；接着讲网卡和PCIe设备，这里有一个非常实用的经验：判断硬件型号不要靠"长得像"，要靠PCI ID；最后讲整机汇总和几个必须避开的坑。

无论你是刚入行的Linux小白，还是干了几年但一直没系统整理过硬件命令的运维，这套东西都能让你下次接手服务器时更有底气。尤其是当你需要做资产盘点、机器上架验收、性能瓶颈排查、扩容方案规划的时候，这些命令的价值会比查监控面板还直接——监控面板告诉你"现在状态如何"，但这些命令告诉你"这台机器到底是什么"。

2. CPU：用lscpu一次读明白型号、核数和超线程

2.1 lscpu 输出里几个决定性的字段

lscpu来自util-linux包，几乎所有主流发行版都自带，不需要额外安装。直接敲不带参数，输出已经排好版。

bash复制lscpu

我一般只看这么几行：

这里有个很实用的小公式：

text复制CPU(s) = Socket(s) × Core(s) per socket × Thread(s) per core

当你看到一台机器CPU(s)是96，Socket(s)是2，Core(s) per socket是24，Thread(s) per core是2，马上就能口算出来：两颗24核物理CPU，开了超线程，逻辑核96。如果哪天你发现这个等式不成立了，那就要警惕——要么是厂商定制型号，要么是云主机做了CPU超卖或绑核限制，后一种情况在云环境里经常遇到。

2.2 /proc/cpuinfo 的老办法和物理核/逻辑核计算

有些老系统没有lscpu，或者你需要在脚本里做判断，那就直接读/proc/cpuinfo。这个文件是内核直接生成的CPU信息视图，不依赖额外工具。

bash复制# 逻辑CPU个数
grep -c '^processor' /proc/cpuinfo

# 物理CPU颗数
grep 'physical id' /proc/cpuinfo | sort -u | wc -l

# 每颗物理CPU的核数
grep 'cpu cores' /proc/cpuinfo | uniq

# 是否开启超线程：siblings 是 cpu cores 的两倍说明开了
grep -E 'siblings|cpu cores' /proc/cpuinfo | head -4

注意cpu cores这个字段才是物理核数，siblings是一颗物理CPU上能看到的逻辑CPU数。如果siblings刚好等于cpu cores，说明没开超线程；如果等于两倍，说明开着超线程。曾经有同事拿着lscpu里96个逻辑核，非说这台机器是96核，其实物理核只有48个。采购合同上写的"核数"通常指物理核，验收的时候拿cpu cores去对，避免扯皮。

2.3 NUMA 节点与性能排查的关联

lscpu输出的最后部分会给出NUMA节点分布，格式大概是NUMA node0 CPU(s): 0-47。如果你发现应用在高负载下延迟抖动严重，而且这台机器是多路CPU，大概率跟跨NUMA访问内存有关。进程绑核的时候，优先把线程绑到同一个NUMA节点上，内存访问会快很多。

排查现场有一个很快的办法：

bash复制# 查看进程跑在哪个NUMA节点
numastat -p PID

# 查看整机numa命中情况
numastat

这些信息平时看不大出来，但做数据库、DPDK、高频交易类业务优化时，NUMA就是绕不过去的一环。硬件速查不只是报个型号，还包括让应用的部署方案贴合硬件拓扑。

3. 内存：free看的是水位，dmidecode看的是"户口"

3.1 free -h 的正确打开方式：盯available而不是free

free -h是所有人都会的命令，但很多人只看free那一列，这是不对的。Linux会把空闲内存拿去做page cache，所以free列的数字往往很小，看起来"内存快满了"，其实业务一点不卡。正确做法是看available这一列。

bash复制free -h

text复制              total        used        free      shared  buff/cache   available
Mem:           503Gi        89Gi       7.2Gi       2.0Gi       406Gi       410Gi

这台机器总量503G，free才7.2G，但available有410G，完全健康。available的含义是"在不触发大量swap的情况下，还能分给新进程多少内存"，它把可回收的page cache也算进去了。所以日常巡检写脚本，判断内存是否告警，一律用available，不要用free。

但free只解决"够不够用"的问题，解决不了"是怎么插的"这个问题。比如你想加内存，总容量是503G，那你得知道现在插了几根、每个插槽还能不能加、当前跑的是不是最高频率。这时候就得看SMBIOS信息。

3.2 dmidecode 查内存拓扑、ECC 与扩容规划

dmidecode输出的是主板和BIOS上报的SMBIOS信息，需要root权限。看内存用这个：

bash复制dmidecode -t memory

这个命令输出很长，我一般只提取关键段：

bash复制dmidecode -t memory | grep -E 'Locator|Size|Type:|Speed|Rank|Manufacturer|Part Number|Serial Number'

看几个重点：

• Maximum Capacity：整机最高支持多少内存，扩容前先确认。
• Number Of Devices：总共几个内存插槽。
• Size：每条内存的大小。No Module Installed表示插槽为空。
• Type: 和 Speed：DDR4还是DDR5，标称频率多少。
• Configured Memory Speed：实际跑在什么频率。如果比标称低，可能是插了不同频率的条子，或者CPU内存控制器限制。
• Error Correction Type：这行值如果是Single-bit ECC，说明用了ECC纠错内存；如果是None，说明是普通非ECC内存。

我第一次发现Error Correction Type这个字段是在一台旧服务器上，当时觉得奇怪，为什么同样的内存报错，那台机器能自动纠正，另一台却直接宕机。后来才意识到，ECC内存在服务器领域是底线，不是可选项。做硬件速查的时候顺手看一眼这个字段，能帮你判断这台机器适不适合跑数据库这种对数据一致性要求高的业务。

3.3 内存报错时，怎么用 dmidecode 定位具体条子

内存报错是服务器最常见的灰犀牛。Linux下内核会通过EDAC或MCE机制记录内存错误，查看方式：

bash复制dmesg | grep -i -E 'edac|mce|memory error'

如果日志里出现的是"可纠正错误"，意味着数据没崩但硬件已经不稳定了，需要准备更换。类似Windows事件查看器里的WHEA-Logger Event ID 47，类比的Linux场景也是这个思路：先确认哪条内存有问题，然后拿着条子的身份信息报修。

这时候dmidecode的价值就出来了：

bash复制dmidecode -t memory | grep -E 'Locator:|Serial Number:|Part Number:|Speed:'

报修时把Locator（插槽位置）、Serial Number（序列号）、Part Number（型号）一起截图发过去，厂商不用二次拆机就能直接发备件。没有这些信息，售后会反复要求你"确认一下是哪根内存"，一个工单拖两三天。

4. 磁盘和RAID：lsblk定拓扑，smartctl判健康

4.1 lsblk：一眼分清系统盘、数据盘和NVMe

磁盘这块最容易被忽视，因为大家平时都用df -h看使用率，但df是文件系统视角，看不到底层物理盘长什么样。要看"这台机器有几块盘、每块盘多大、是不是SSD、插在哪"，用lsblk。

bash复制lsblk

输出是一棵倒挂的树，NAME列会显示nvme0n1、sda、sdb这类名字，TYPE列会区分disk（物理盘）、part（分区）、lvm（逻辑卷）。如果只想看物理盘和关键属性：

bash复制lsblk -d -o NAME,SIZE,ROTA,MODEL,SERIAL

这里ROTA列非常关键：等于1表示机械盘（rotational），等于0表示SSD或NVMe。MODEL列能看到厂商型号，SERIAL是物理序列号，做资产盘点时这些信息比分区挂载点有用得多。

有一次我验收一批机器，厂家写的是"全部SSD"，结果ROTA列一片1。所以别信配置单，信SMART数据。硬件速查的意义就在这里——它是验收时唯一你自己能掌握的第一手证据。

4.2 smartctl：机械盘和固态盘各自盯哪些指标

磁盘健康检查用smartctl，来自smartmontools包。先扫描一下机器上有哪些盘支持SMART：

bash复制smartctl --scan

然后针对具体盘查详细信息：

bash复制smartctl -a /dev/sda

机械盘重点看这几个属性：

SSD和NVMe则要看另一组指标：

bash复制smartctl -a /dev/nvme0

重点看Percentage Used（寿命磨损百分比）、Media_Wearout_Indicator（磨损指示器）、Power_On_Hours和Temperature。NVMe的SMART字段命名和SATA盘不一样，别拿SATA盘的经验硬套。

这里有个实操经验：新盘上架前，先做一次短自检，确认出厂状态正常再进业务。

bash复制smartctl -t short /dev/sda

短自检一般几分钟到十几分钟，比跑全盘badblocks快得多。测试期间IO会有影响，生产环境别白天跑，维护窗口再说。

4.3 硬RAID环境下怎么查物理盘（storcli/MegaCli）

如果机器用了硬RAID卡，lsblk和smartctl看到的往往是虚拟磁盘/dev/sda，不是物理盘。物理盘被RAID卡接管了，得通过RAID卡工具去查。

先用lspci确认RAID卡型号：

bash复制lspci | grep -i -E 'raid|megaraid|broadcom|adaptec'

如果是Broadcom/LSI的卡，常见工具有storcli和更老的MegaCli。命令格式大概是：

bash复制storcli64 /c0 /eall /sall show

这个命令会列出RAID卡控制器、背板上的所有物理盘槽位、每个槽位磁盘的容量、介质类型、状态。现场最关心的是State列：一个Rd是正常在线，出现Rb通常是重建中，Fgn或Offline那基本是出问题了。

没有厂商工具又急着确认物理盘数量，也可以看系统日志，但信息不全。我的建议是：机器上架时就把RAID卡工具装好，把物理盘台账导出一份，后面再做硬件速查就快得多。资产盘点最怕的就是"知道有盘，不知道盘在哪块背板上"。

5. 网卡和PCIe设备：别再靠"长得像"猜型号

5.1 lspci -nn：一切PCIe设备识别的起点

服务器上除了CPU和内存，其他设备基本都挂在PCIe总线上：网卡、RAID卡、GPU、NVMe控制器，全都通过lspci看。

很多人用lspci就裸敲，输出是"Ethernet controller: Intel Corporation ..."这种文本，其实够用了，但要做精确型号判断，最好带-nn参数，让它显示厂商ID和设备ID：

bash复制lspci -nn

text复制01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G X550T [8086:1563]

[8086:1563]就是这设备的身份标识，8086是Intel的厂商ID，1563是设备ID。这个ID比商品名可靠得多。查GPU也一样：

bash复制lspci | grep -i nvidia
lspci | grep -i amd

新机器进机房、装系统、装驱动之前，先用lspci -nn把整机PCIe设备过一遍，确认网卡到底什么型号、有没有GPU、RAID卡是什么芯片。这个动作花不了30秒，但是能救你后面一整天——装错驱动版本、固件刷错型号，基本都是因为这一步偷懒了。

5.2 ethtool 和驱动/固件信息：排查降速和不稳定的关键

lspci解决"设备是什么"的问题，ethtool解决"设备现在跑得怎么样"的问题。

bash复制ethtool eth0

重点看这几行：

• Speed: 10000Mb/s：当前协商速率。
• Duplex: Full：双工模式。
• Link detected: yes：链路是否在线。
• Port: FIBRE 或 Twisted Pair：接口介质类型。

最经典的一个坑就是网卡降速。业务反馈"网络很慢"，上机器一看ethtool，速率协商到了100Mb/s，但网卡明明是万兆的。原因往往是网线质量差、接口接触不良，或者对端交换机端口配置错误。这时候别急着改业务，先换线、查两端端口配置。

再看驱动和固件：

bash复制ethtool -i eth0

输出里有driver、version、firmware-version、bus-info。排查到网卡丢包、异常重启时，先对比固件版本是不是过旧。很多网卡厂商的release note里都写着"修复了XX特定流量模式下的丢包"，这种问题靠调业务参数是绕不过去的，只能升固件。

中断队列数也可以顺手看：

bash复制ethtool -l eth0

看Combined的最大值和当前值。高并发网络场景下，队列数不够会直接拉高CPU软中断压力，这时候要么调队列数，要么做RSS（Receive Side Scaling）的CPU亲和性绑定。

5.3 同系列硬件对比：PCI ID比商品型号靠谱

曾经有朋友拿两款示波器问我，说型号只差一个字母，硬件是不是完全一样，能不能共用一套驱动。我没法隔着屏幕拆机，但告诉他一个思路：不管商品名多接近，最靠谱的做法是查设备ID和子系统ID。

Linux下看设备子系统ID的方法：

bash复制lspci -nnk -d 8086:1563
lspci -vv -s 01:00.0 | grep -E 'Subsystem|Rev'

Subsystem那行会显示子系统厂商ID和设备ID，用来区分同一主芯片的不同衍生型号。现实里很多设备主芯片相同，但外围设计、固件版本、硬件版本号（Rev字段）不一样，驱动行为也可能有差异。所以"看起来一样"在硬件层面是个危险词，一切以lspci输出为准。

这个经验放到服务器选型上也成立。采购对比型号时，别只看商品名前后缀，直接看PCI ID和固件版本，省去大量"是不是阉割版"的猜疑。

6. 一条命令汇总整机信息：lshw、dmidecode和自用脚本

6.1 系统级速查与SMBIOS信息

单条硬件信息都查得到之后，真正提升效率的是"一键汇总"。有两类命令可以担任这个角色。

第一是lshw，它能把整机硬件信息按树状结构拉通：

bash复制lshw -short

输出分成Class、Device、Description几列，CPU、内存、磁盘、网卡一眼看完。缺点是需要root，有些精简系统没装，得先apt install lshw或yum install lshw。

第二是dmidecode的系统信息：

bash复制dmidecode -t system

这里能读到Manufacturer、Product Name、Serial Number，也就是整机的厂商、型号和序列号。序列号是报修硬件的"身份证"，一定要记录在资产台账里。查BIOS版本则用：

bash复制dmidecode -t bios

固件升级前后对比一下版本号，能确认刷新是否真的生效。我记得有一次升级完BIOS，进入系统后发现dmidecode显示的版本号还是旧的，折腾了半天才意识到是刷新工具因为ACPI电源管理设置没真正执行，白忙活一场。所以"查到的版本"和"以为刷好的版本"必须单独核对。

6.2 一个可以直接抄的硬件速查脚本

把常用命令拼成一个脚本，以后交接服务器时执行一次，就能输出一份基础硬件报告。这是我长期在用的版本，你直接拿去改改就行：

bash复制#!/usr/bin/env bash

echo "===== 主机信息 ====="
hostnamectl 2>/dev/null | grep -E 'Static hostname|Operating System|Kernel|Architecture'

echo
echo "===== 整机厂商/型号/序列号 ====="
dmidecode -t system 2>/dev/null | grep -E 'Manufacturer|Product Name|Serial Number'

echo
echo "===== CPU ====="
lscpu 2>/dev/null | grep -E 'Model name|Socket\(s\)|Core\(s\) per socket|Thread\(s\) per core|CPU\(s\)|NUMA node\(s\)'

echo
echo "===== 内存 ====="
free -h | awk '/Mem:/{print "总容量: "$2", 可用: "$7}'
dmidecode -t memory 2>/dev/null | grep -E '\tSize:|Type:|Speed:|Error Correction Type:' | grep -v 'No Module' | head -20

echo
echo "===== 物理磁盘 ====="
lsblk -d -o NAME,SIZE,ROTA,MODEL,SERIAL

echo
echo "===== 网卡 ====="
for dev in $(ls /sys/class/net/ | grep -E '^(eth|enp|ens|eno)'); do
    speed=$(cat /sys/class/net/$dev/speed 2>/dev/null)
    link=$(cat /sys/class/net/$dev/carrier 2>/dev/null)
    echo "$dev: 速率 ${speed}Mb/s, 链路状态 $([ "$link" = "1" ] && echo up || echo down)"
done

echo
echo "===== PCIe关键设备 ====="
lspci -nn | grep -E 'Ethernet|RAID|VGA|Non-Volatile'

这个脚本里我特意用了/sys/class/net/$dev/speed而不是ethtool，原因是ethtool需要root权限，而sysfs下的文件在部分场景下对普通用户只读可访问，权限要求更宽松，适合给低权限账号开白名单。但注意，speed文件在某些虚拟网卡上不存在，所以脚本里用了2>/dev/null兜底。

另外提一句，dmidecode必须root，所以这个脚本整体还是建议在有root权限的维护账号下执行。如果公司安全策略严格，可以在脚本里对每个需要root的命令单独做sudo配置，而不是给整个bash开放root，安全性和实用性都能兼顾。

7. 实操中比命令本身更重要的三件事

7.1 内核版本、固件版本会改变命令输出

命令会背了，输出会看了，还不够。硬件速查最容易翻车的地方在于：同一台机器，在不同内核版本、不同固件版本下，读出来的信息可能不一样。

举一个我真实遇到的例子。某台老服务器在看CPU信息时，新内核的lscpu能识别出avx2等指令集标志，而旧内核的/proc/cpuinfo里flags字段就少几个关键标记。后来排查一个性能问题，发现应用编译时用了-march=native，在开发机上检测到了新指令集，编译出的二进制放到生产服务器上直接illegal instruction。所以查CPU信息不只是报个型号，还要对比flags，确认应用依赖的指令集在目标机器上是否存在。

固件版本同样重要。有些主板BIOS更新后，内存XMP参数、CPU微码都会变化，lscpu里Microcode字段会跟着变。所以做硬件速查时，顺手记录一下微码版本和BIOS版本，后面遇到奇怪问题能省很多排查时间。

7.2 虚拟化环境里的"假硬件信息"陷阱

云服务器和虚拟机里的硬件信息，很多是虚拟化层"模拟"出来的，不代表物理真机。比如KVM虚拟机里的dmidecode会显示Product Name: KVM，lscpu里Hypervisor vendor是KVM。这时候你看到的内存插槽、磁盘型号，都是虚拟设备，去查物理机型号反而没意义。

有个坑特别典型：云厂商的裸金属和虚拟机外观上很难区分，但性能天差地别。判断方法很简单，看lscpu输出里有没有Hypervisor vendor这一行，或者systemd-detect-virt：

bash复制systemd-detect-virt

裸金属会输出none，虚拟机输出kvm、vmware、xen之类的字符串。做资产盘点时，物理机、虚拟机必须分两套台账，不然验收、容量规划全乱套。也别拿虚拟机的dmidecode序列号去当硬件序列号报修，那是虚拟机的UUID，不是厂商的SN。

7.3 速查结果的交叉验证习惯

最后分享一个我个人的实操习惯：硬件速查的结果，永远做交叉验证。命令读到的信息，要和物理机身贴纸、带外管理界面、厂商配置单三者互相比对。

比如dmidecode读出内存是8条32G，但机器上只有4个插槽，那肯定是读错了，或者某些插槽是多列内存要仔细看Locator。再比如lspci显示网卡是万兆，但ethtool协商速率只有千兆，可能线缆或模块有问题，而不是网卡不支持万兆。交叉验证看起来很笨，但每一次都能帮你提前发现"配置单和实物不符""固件刷了一半""内存被静默降频"这类隐藏问题。

我自己的体会是：硬件速查命令本身没有多高的技术门槛，真正拉开运维差距的，是你对这些命令输出里每一个字段的理解深度，以及有没有形成一套"查到信息之后还要想一想这意味着什么"的习惯。命令只是工具，判断力才是值钱的部分。