Linux硬件信息查看全攻略：CPU、内存、磁盘、网络排查命令详解

1. 为什么要把“查看硬件信息”当成一项基本功来练先讲个我自己的经历。早几年在一家小公司做运维有一天凌晨三点被值班电话叫醒说某台数据库服务器报警CPU温度直逼85度风扇转速拉满机房噪音大得像飞机起飞。我远程登上去第一件事就是用lscpu看型号sensors看温度dmidecode查机器是不是该清灰了再配合top确认到底是哪个进程把CPU顶满的。十几分钟定位完问题天还没亮。后来越来越觉得Linux下查看硬件信息这些命令平时看起来不起眼真正出事的时候是救命的底牌。很多人觉得“看硬件信息”不就是lscpu加free -h嘛网上教程一抓一大把。但实际工作里远没有这么简单你新增了一台服务器要确认CPU型号是否一致你要扩内存但不知道还有几个插槽空着、支持什么频率你的数据库突然慢了得判断是磁盘IO瓶颈还是内存不够你怀疑网卡在做流控但不知道驱动版本你甚至要在一台没有显示器、没有外设的裸机上远程判断硬件健康状况——这些都是“查看硬件信息”的范畴绝不是一条lscpu能覆盖的。我见过不少同事干了三五年用lspci还要现场查参数。这不算丢人知识量确实大。但如果能把这条线梳理清楚形成一套自己的排查套路那效率完全不一样。这篇文章我想换一种写法不做成菜单式的“命令大全清单”而是按硬件类别拆开把 Linux 下查看信息的原理讲明白每个命令的输出重点在哪里哪些关键字段要读懂真实场景中怎么组合使用。内容覆盖 CPU、内存、磁盘、网络、显卡这几个主要维度最后再用一个完整的故障排查案例把这些命令串起来。你可以照着文章去敲一遍命令花上一个小时把这些输出跟自己的电脑对应上以后遇到硬件问题心里就有谱了。这套东西适合谁刚入行的运维、偶尔要给服务器做体检的后端开发、折腾自己的Linux桌面但总搞不清硬件参数的小白以及准备Linux面试的求职者。面试题里“如何查看CPU信息”“如何查看内存信息”看似送分但问深一层比如“怎么看物理CPU颗数”“怎么看内存插槽是否还有空余”“怎么判断磁盘是SSD还是机械盘”很多人就卡壳了。这篇文章把这些坑都填上。2. CPU信息查看从型号参数到实时负载的完整读法2.1 lscpu一条命令看懂CPU全局信息lscpu是 util-linux 包提供的命令几乎所有主流发行版都自带。它的数据来源是/proc/cpuinfo和 sysfs但整理得比直接看 cpuinfo 友好得多。你执行一下会看到类似下面的输出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: 800.062 CPU max MHz: 3800.0000 CPU min MHz: 800.0000 BogoMIPS: 5616.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K NUMA node0 CPU(s): 0-7这里最关键的几行我来拆解一下CPU(s): 8表示操作系统看到的逻辑CPU总数也就是线程数。Thread(s) per core: 2代表每颗物理核心开了超线程。Core(s) per socket: 4代表每个CPU插槽上的物理核心数。Socket(s): 1代表主板上插了几颗物理CPU。这三行数据可以交叉验证8 1 × 4 × 2。逻辑CPU数 插槽数 × 单插槽物理核心数 × 每核心线程数。很多人记不住这个公式我教你一个笨办法直接看Model name联想配合同事之间“这台机器是几U几核几线程”的说法去理解。比如“双路服务器”就是 Socket(s): 2一颗CPU 16核32线程就是 Core(s) per socket: 16、Thread(s) per core: 2。2.2 直接读 /proc/cpuinfo判断物理颗数和超线程为什么有了lscpu还要会读/proc/cpuinfo因为有些老旧系统 util-linux 版本太低lscpu输出不完整或者你在做脚本自动化需要从 cpuinfo 里提取字段。cat /proc/cpuinfo的输出是按逻辑CPU分块的每个逻辑CPU一个区块。一台8逻辑CPU的机器你会看到从processor : 0到processor : 7一共8块。每块里有几个字段值得注意physical id这个逻辑CPU属于哪颗物理CPU。如果最大值加1等于2说明机器是双路。core id这颗物理CPU上的哪个物理核心。cpu cores每颗物理CPU有多少个物理核心注意所有区块里这个值应该一致。siblings每颗物理CPU上一共有多少个逻辑CPU。判断是否开启超线程的技巧如果siblings是cpu cores的两倍说明开了超线程。比如siblings : 8、cpu cores : 4那就基本可以断定每个物理核心提供了两个线程。这个文件还有个隐藏用途查看 CPU 支持的指令集也就是flags那一行。你在 flags 里能看到avx2、sse4_2、aes、nx等。判断 CPU 是否支持虚拟化看有没有vmxIntel或svmAMD判断是否可以跑某些科学计算库看有没有avx系列。有一回我排查某台机器跑深度学习框架特别慢对比 flags 才发现那台 CPU 是低功耗版的连 AVX2 都不支持很多东西走了软实现。这种问题不查 flags 真的想不到。2.3 实时负载与温度top、mpstat、sensors的配合硬件参数看完了得看它“现在跑得怎么样”。top里的 %Cpu(s) 是全局平均负载但单看这个不够最好用mpstat -P ALL 1刷出每一颗逻辑CPU的使用率定位是不是某颗核心被打满常见于单线程程序。mpstat来自 sysstat 包没有就装一下它是性能排查的主要工具之一。CPU温度读取依赖传感器驱动一般用sensors命令lm-sensors 包。很多笔记本上老款CPU温度读不出来因为传感器驱动没有完全加载需要执行sensors-detect并一路回车等它探测硬件再重启加载模块。服务器一般没问题。温度这个指标平时不起眼但机房夏天出过几次空调故障就是靠sensors发现的。还有一个容易忽略的指标/proc/loadavg。它显示的是 1分钟、5分钟、15分钟的平均负载。关于负载的误读非常多——它不是CPU使用率而是处于可运行状态和不可中断睡眠状态的进程数平均值。我曾经在一台明明CPU很空闲的机器上看到负载高达30排查了半天发现是一个程序在做不可中断的磁盘IO阻塞在D状态把负载顶上去了。所以看到负载高别急着下“CPU不够用”的结论先看D状态的进程和IO情况。3. 内存信息free、dmidecode与内存条“体检”3.1 free -h不是看used而是看availablefree -h的输出大家应该很熟悉total used free shared buff/cache available Mem: 31Gi 8.2Gi 15Gi 243Mi 7.4Gi 21Gi Swap: 15Gi 0B 15Gi我对内存命令的建议是优先看available而不是used。为什么因为 Linux 的内存策略是“能用就用”大多数空闲内存都被用作了 page cache也就是 buff/cache这在used里没有体现但真正有程序需要内存时内核会把这些 cache 回收释放出来。used8.2Gi 看着不高available21Gi 才是真正可分配给新程序的大小。早期有些监控系统只看used百分比得出“内存告警”的错误结论白折腾一场。3.2 /proc/meminfo脚本采集内存的权威来源做监控脚本的时候用free解析文本不是不行但更标准的是直接读/proc/meminfo。关键字段MemTotal物理内存总量。MemFree完全没有被使用的内存。MemAvailable估算的可用内存包括可回收的cache这个值和free里的 available 对应。Buffers块设备缓冲。Cachedpage cache主要是文件缓存。SwapTotal / SwapFree交换分区总量和剩余。在写监控脚本时我一般用MemAvailable / MemTotal计算可用率而不是用MemFree。因为MemFree在系统运行一段时间后通常会变得很小而 MemAvailable 才是真实可用于分配的量这样能减少很多误报。3.3 dmidecode -t memory物理内存条的“体检报告”这块内容我觉得是很多人最陌生的。日常工作里经常遇到一种情况机器内存满了想去扩容结果不知道这台机器有几个内存插槽、还剩几个空余、支持多大频率。free和 meminfo 都回答不了这时候就要请出dmidecode -t memory。这个命令要 root 权限输出的信息比较多我平时最关心的是Locator插槽位置、Size容量、TypeDDR3还是DDR4、Speed运行频率、Manufacturer厂商和Part Number料号。如果某个插槽显示Size: No Module Installed说明这个槽位是空的可以加内存。需要注意Speed显示的不一定是内存条的标称频率而是当前实际协商出来的运行频率。曾经有个同事加了一根 DDR4 3200 的内存条插上去后发现系统只识别为 2133差点以为是假条。查了主板说明书才发现那个插槽和原内存条组合后必须降频运行。这种问题靠dmidecode看一眼当前频率就能定位不用拆机箱。3.4 内存硬件错误的线索dmesg与EDC查看内存相关的硬件错误最直接的路径是dmesg -T | grep -i error结合关键字Memory、EDAC、CE、UE筛选。EDAC是内核的内存错误检测框架能报告可纠正错误CECorrectable Error和不可纠正错误UEUncorrectable Error。CE 错误如果持续增长说明内存条处于“亚健康”状态虽然还能用但建议尽早更换免得以后超频负载上来直接挂掉。另外mcelog如果有安装会记录机器检查异常是判断硬件故障的重要日志来源。我个人体会内存问题在Linux下的表现千奇百怪有随机进程段错误崩溃的有文件系统随机损坏的有程序跑着跑着被kill掉的。看到这些莫名其妙的现象时间充裕就先跑一遍内存测试很多“玄学问题”最后都落在内存上。4. 磁盘与块设备lsblk、df、du与smartctl的组合打法4.1 lsblk看清磁盘拓扑和挂载关系lsblk的l是 listblk是 block device。它输出的树状结构非常直观能看出物理磁盘下面分了哪些分区、每个分区挂载到哪个目录、有没有 LVM 或 RAID 层。我个人最常用的是lsblk -f加-f后会多出文件系统类型和 UUID 两列lsblk -d -o NAME,ROTA,SIZE,MODEL可以快速列出每块磁盘是机械盘还是固态盘——ROTA列是 1 表示旋转盘机械0 是 SSD。判断 SSD 和 HDD 这件事很多人的第一反应是看型号字符串里有没有“SSD”字样但服务器上很多企业级盘的型号是不带关键词的用ROTA最靠谱。另外它还能看出这块盘是不是虚拟化出来的比如云主机里常见的vda其 MODEL 列通常显示Virtual disk之类的字样。4.2 df与du容量查的是文件系统不是磁盘磁盘分区被格式化后我们先看到的是文件系统而不是裸设备。df -hT是看文件系统容量最常用的命令-T显示文件系统类型ext4、xfs、btrfs等。真正容易出问题的是 inode 耗尽有的小文件特别多的目录明明空间还剩几十G却报“No space left on device”这时候跑df -i才能看到 inode 已经用完了。这类故障处理起来不难但排查思路要清晰——先分清楚是空间不足还是inode不足再决定清理方向。du命令用来从文件系统层面统计目录占用。找大文件的通用链路是du -h --max-depth1 /path | sort -hr | head -20。如果系统有ncdu交互式体验更好可以像逛文件管理器一样一层层看哪个目录大。我一般在处理“磁盘满了”的告警时前三板斧就是 df、du、ncdu大部分情况十分钟内能找出占用大户。4.3 fdisk -l、blkid与parted分区表和UUID查看分区表fdisk -l /dev/sda能列出磁盘的分区结构但遇到 GPT 分区建议用parted /dev/sda print对超过2T的大盘支持更好。blkid则用来查看分区或文件系统的 UUID、类型、LABEL。为什么要关注 UUID因为/etc/fstab里挂载配置一般用的就是 UUID如果你要做磁盘迁移或者重挂载得对照这个信息操作写错 UUID 会导致系统重启后挂载失败。一个实际例子有一次我给一台服务器加数据盘想做成开机自动挂载需要知道新分区的类型和 UUID。我直接插上盘、分区、格式化然后blkid /dev/sdb1拿到 UUID 写进 fstab。看起来很简单但如果提前不确认 UUID直接写/dev/sdb1这种设备名一旦下次重启时内核枚举顺序变了设备名可能会变挂载就出问题了。4.4 smartctl硬盘健康状态自检“磁盘什么时候会坏”是运维圈最像玄学的问题但 SMART 信息至少能帮你提前看到一些征兆。smartctl -a /dev/sda查看健康状态重点看Reallocated_Sector_Ct重映射扇区计数、Pending_Sector等待重映射的扇区、UDMA_CRC_Error_Count传输错误计数。这几个关键计数如果持续增长就说明盘在走下坡路建议在它彻底罢工前把数据迁走。这里有个注意事项NVMe 固态硬盘的 SMART 字段和 SATA 盘不太一样smartctl -a同样适用但关键指标是Percentage Used寿命使用百分比和Data Units Written总写入量。另外很多虚拟化环境中的云硬盘并不支持 smartctl 查询因为根本不存在物理 SMART 数据读出来的结果没有参考意义搞清环境再下结论。4.5 性能视角iostat与iotop补上最后一块硬件健康不等于性能达标。怀疑磁盘慢用iostat -x 1看%util、await、svctm。其中%util表示设备忙的时间比例接近100%说明磁盘可能已经成为瓶颈。await是IO请求的平均耗时机械盘在几毫秒到几十毫秒如果几百毫秒甚至一秒以上大概率有问题。定位是哪个进程在疯狂读写则用iotop需要 root 权限。这个工具和top类似但展示的是进程级别的磁盘IO。曾经排查过一台文件服务器访问卡顿iostat显示磁盘繁忙iotop一开就看到一个日志清理程序在反复删除再写日志文件属于应用层设计问题而不是硬件故障。5. 网络硬件与显卡lspci、ethtool、nvidia-smi的配合5.1 lspci先看整机设备树lspci列出所有PCI设备信息源来自内核枚举。不加参数输出很精简但搭配-vverbose可以看到驱动、内核模块等详情。我在排查“网卡为什么不工作”时第一步就是lspci | grep -i ethernet确认网卡设备有没有被识别。第二步用lspci -s 02:00.0 -vvv把设备总线地址填上看驱动名和内核模块是否加载成功。如果设备出现在 lspci 里但驱动没加载内核日志里通常有报错两个信息一对照问题方向就清楚了。5.2 ethtool网卡速率、型号与驱动的“万能钥匙”很多人以为看网卡型号只能开箱看硬件标签其实ethtool可以回答很多问题。先说最常见的ethtool eth0输出里有Speed: 1000Mb/s和Duplex: Full能判断链路协商是否正常。网线老化、对端交换机端口配置错误都可能让你从万兆掉到千兆甚至百兆这个命令看最直观。看网卡硬件型号和驱动用ethtool -i eth0输出包含driver、firmware-version、bus-info等信息。我遇到过一次网卡丢包率高的问题查ethtool -S eth0看到rx_crc_errors计数器狂涨再配合dmesg发现网卡驱动在频繁 reset最后定位是网卡固件太老升级固件解决。网卡统计计数器这种信息平时看没什么排障时价值极大。5.3 ip link与无线网卡信息ip link show能看所有网络接口的MAC地址、状态和MTU。经常有人在多个网卡之间分不清哪个是哪个最基本的办法是看MAC地址但要更直观可以用ethtool -p eth0让对应网卡指示灯闪烁物理上直接确认位置。无线网卡用iw dev查看iw dev wlan0 link查看连接状态和信号强度iwlist wlan0 scan扫描附近WiFi。这些都是非常成熟的排查工具。5.4 GPU信息不只是nvidia-smi搞机器学习的同学对nvidia-smi应该很熟它能查看NVIDIA显卡的型号、驱动版本、显存占用、温度、功耗、利用率。但注意nvidia-smi是NVIDIA驱动装好后才有的工具。在没有NVIDIA驱动的阶段用lspci | grep -i vga或lspci | grep -i nvidia也能识别显卡设备型号。AMD显卡则通常用rocm-smi或clinfoOpenCL信息查看。Intel集成显卡可以看/sys/class/drm下的信息不过日常很少用到。对于显示器分辨率信息xrandr是常用的图形化查询工具但在纯命令行或SSH环境下可以直接读系统日志如/var/log/Xorg.0.log来确认驱动加载情况也能达到排障目的。此外有些服务器的GPU解码芯片比如视频编码卡并不挂在PCIe常规位置lspci看不到需要用专门的厂商工具这个以后有机会单独写。6. 汇总工具与实战排查思路6.1 lshw与hwinfo两个“一站式”汇总命令如果你不想分开跑 CPU、内存、磁盘命令想快速生成一份整机硬件清单可以用lshw。它的-short模式输出简洁能一眼列出整机的硬件树。注意lshw需要 root 权限才能看到最全的信息普通用户只能看到部分设备。hwinfo是另一个汇总工具在 openSUSE 系发行版里比较常见它的输出更详细也支持按类别查询比如hwinfo --cpu、hwinfo --memory。但这里我想多说一句汇总工具适合“摸清家底”真正出问题的时候最好还是回到专门的命令去精确定位。比如lshw告诉你有个硬盘型号但判断它是否健康你还得看smartctl它告诉你网卡型号但驱动加载正不正常还得看dmesg和ethtool。汇总工具是起点不是终点。6.2 实战案例从“机器变慢”到定位内存故障的完整链路写到这里我把这些命令串进一个我真实处理过的故障里你跟着过一遍就理解了。某天下午一台应用服务器突然响应变慢用户反馈“打开页面要卡好几秒”。我登上去后的排查顺序是这样的uptime看负载发现 load average 已经到了 8.5而机器只有 4 个逻辑CPU。负载明显偏高。top看进程CPU排序结果发现没有任何进程CPU使用率突出最高也就 20%。这说明问题大概率不在计算密集。free -h看内存available 还剩得很多内存也排除了。iostat -x 1看磁盘发现%util稳定在95%以上await到了 400 多毫秒。瓶颈在磁盘。iotop看哪个进程在读写看到的是 MySQL 在持续写 binlog但写入量并不大所以不是应用造成的IO压力。这个时候我开始怀疑磁盘硬件本身有问题跑smartctl -a /dev/sdb发现Reallocated_Sector_Ct数值比上个月多了不少而且Current_Pending_Sector也有增长。进一步看dmesg -T | grep -i error发现一堆I/O error设备名指向 sdb。最终结论这块盘正在慢慢坏掉SMART 指标的持续增长和 dmesg 里的 IO 错误互相印证。后来我给这块盘做了数据迁移并报修更换问题解决。整个过程中单独任何一条命令都不足以定性但组合起来证据链就完整了。我特别想强调这个过程查硬件问题不能只靠一条命令拍板信息交叉验证非常重要。负载高可能是CPU、内存、磁盘、网络任一方面引起你一层层排除最后才敢下结论。6.3 一个小监控脚本思路把硬件信息变成日常巡检项硬件问题最怕的是“平时没问题突然出大事”。所以把这些命令变成定时巡检项是我的习惯做法。比如写一个简单的 bash 脚本定期把 CPU 温度、内存可用率、磁盘 SMART 关键计数、网卡错误计数追加到日志文件并配合告警。不需要用什么重型监控系统一个 cron 任务加几行命令就能跑起来。脚本逻辑大致是这样的用sensors读 CPU 温度超过阈值就报警。用/proc/meminfo算可用率低于 10% 就报警。用smartctl -a /dev/sda抓Reallocated_Sector_Ct如果和上次读数比有明显变话说明盘在恶化报警。用ethtool -S eth0抓rx_crc_errors和tx_dropped如果持续增加说明链路或网卡有问题。这些巡检项不需要多复杂的工具但长期积累下来是你了解机器“性格”最好的资料。哪台机器温度常年偏高、哪块盘的重映射扇区在慢慢涨你心里有数真正出问题时就能快速判断。6.4 几个真实场景下的经验补充最后补充几个零散但很重要的经验都是我在实际环境里踩过的云主机和物理机查出来的信息含义完全不同。云主机里lscpu看到的型号可能是虚拟化透传的free看到的内存大小也未必等于宿主机分配给你的物理内存smartctl基本不可用。所以拿到一台机器先分清楚是物理机还是虚拟化环境再看命令输出才有意义。不同发行版命令包名不一样。lm-sensors 在 Debian/Ubuntu 叫lm-sensors在 RHEL/CentOS 叫lm_sensorssysstat在两者也有细微差别。装不上命令先检查是不是包名写错了不是系统坏了。Linux 系统的硬件信息是动态变化的。比如你加了内存条free可能马上能看到新容量但有些信息比如固件版本、BIOS设置要重启才生效。遇到硬件信息对不上先重启试试很多问题就是没重启导致的。命令输出看不懂时用man查文档别硬猜。我见过有人把lscpu里的CPU MHz当成CPU当前实际频率来定位性能问题实际上那只是当前频率性能问题要看CPU max MHz和实时负载。类似这种误读会把人带偏。这就是我想分享的全部内容了。硬件信息查看这条路我走了很多年吃过不少亏但这些命令和思路沉淀下来后它成了我最可靠的排查工具。你现在敲一遍命令可能觉得不过如此但等哪天真遇到半夜三更的故障告警你会感谢今天认真看完的这份清单。