尧图网站建设 
接手服务器第一件事是什么不是急着装系统、跑业务而是先把它看懂。在运维一线摸爬滚打这么多年我几乎每次遇到硬件故障、容量评估、机房搬迁都得靠一套固定的命令组合把服务器从里到外摸一遍。很多刚入行的同事喜欢先打开监控面板点来点去就几张图表真到了抢修现场还是命令行最顶用。这篇文章就把 Linux 下查硬件信息最高频、最实用的一组命令完整梳理一遍覆盖整机信息、CPU、内存、磁盘、网卡、扩展设备以及日志排查适合刚接手服务器的新手也适合想把速查手册整理得更系统一点的老运维。所有命令我都以 x86 平台为主同时兼顾 ARM鲲鹏、飞腾等国产平台的区别给出的参数和判断方法都是可以直接抄作业的。1. 整机与平台信息速查先把服务器“验明正身”1.1 三件套命令uname、hostnamectl、dmidecode拿到一台陌生服务器第一步不是跑业务而是先确认这台机器是什么厂商、什么型号、什么架构、跑了什么系统。这三条命令可以解决大部分问题。先说uname -a这是最基础的一条。它能输出内核名称、主机名、内核版本、硬件架构等信息。在实际使用中我最常看的其实是uname -r后面的内核版本号因为很多驱动、内核参数优化都和版本强相关。比如你装了某个网卡厂商的驱动结果发现编译不过先看一眼内核版本往往问题就出在版本不匹配上。[rootlocalhost ~]# uname -a Linux localhost 4.18.0-80.el8.x86_64 #1 SMP Tue Jun 4 12:41:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux再来看hostnamectl这条命令比 uname 更“懂事”一些直接以结构化方式展示操作系统、内核、架构、虚拟化类型等信息。它最大的优势是能看出虚拟化类型比如输出里出现Virtualization: kvm那基本可以判断这是一台虚拟机而不是物理机这直接决定了后续硬件排查的方向。[rootlocalhost ~]# hostnamectl Static hostname: localhost Icon name: computer-server Chassis: server Machine ID: 4c9c7d9c449a4c0ca4052cb9c5fa6f31 Boot ID: 6e2e622bd4d94de4aa929e0aa858ddd8 Virtualization: kvm Operating System: CentOS Linux 8 (Core) CPE OS Name: cpe:/o:centos:centos:8 Kernel: Linux 4.18.0-80.el8.x86_64 Architecture: x86-64最后是硬件信息查询的大杀器dmidecode。它从 SMBIOS 接口读取硬件信息能查到厂商、产品名称、序列号、BIOS 版本、内存插槽详情等。查整机信息用dmidecode -t system查主板用dmidecode -t baseboard查 BIOS 用dmidecode -t bios。这三者组合起来基本就能把一台服务器的身份信息完整录入资产台账了。[rootlocalhost ~]# dmidecode -t system # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.2.0 present. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: PowerEdge R740 Version: 01 Serial Number: 8K5H3D2 UUID: 4C4C4544-0036-3710-8051-B6C04F353432 Wake-up Type: Power Switch SKU Number: SKU-NotProvided Family: PowerEdge这里要特别提醒dmidecode需要 root 权限才能完整读取普通用户执行经常只看到一部分信息。另外在云服务器或虚拟机里dmidecode输出的厂商和序列号常常是虚拟化平台伪造的比如 KVM 的默认厂商就是QEMU、Alibaba Cloud之类看到这种情况别慌不代表物理机坏了只是说明你看到的层不对。1.2 序列号、固件版本与资产台账这些细节别忽略很多运维把服务器信息查出来就完事了序列号、固件版本却不记录等到要报修、要升级 BIOS 的时候才发现还得重新登录机器查一遍效率很低。我的习惯是新服务器上架第一件事就跑一遍硬件采集把输出重定向到一个文件里然后统一维护。比如dmidecode -t system /root/hardware_info/system.txt dmidecode -t baseboard /root/hardware_info/system.txt dmidecode -t bios /root/hardware_info/system.txt序列号Serial Number尤其重要。Dell、浪潮、华为这些厂商的售后维修都必须提供序列号才给报修没有序列号基本就得按过保处理。固件版本则是排查某些硬件 bug 的关键线索比如某些批次的 Intel CPU 存在微码问题固件版本一核对就知道该不该升级。实操中还有一个容易踩的坑批量管理几十台服务器时不能光靠记忆区分机器一定要把dmidecode -t system的输出配合主机名一起存档。我见过不止一次同事把 A 机器的序列号当成 B 机器报修结果维修工程师白跑一趟。建议统一用服务器名 序列号 厂商型号 位置这种格式维护台账字段越规范后续自动化采集越省事。用 Ansible 做批量采集也很简单一条命令就能把所有机器的硬件信息拉到控制端ansible all -m shell -a dmidecode -t system | grep -E Manufacturer|Product Name|Serial Number /root/hardware_inventory.txt2. CPU 信息解析物理核、逻辑核、超线程一次看懂2.1 lscpu 输出逐项解读CPU 信息里最容易混淆的就是“核数”。很多新手跑一条lscpu看到CPU(s): 48就以为机器有 48 个核心这个理解只有在没有超线程、且单核单线程时才成立。真实情况要结合Socket、Core、Thread三个字段一起看。[rootlocalhost ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 2 Core(s) per socket: 12 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6134 CPU 3.20GHz Stepping: 4 CPU MHz: 3690.000 BogoMIPS: 6400.00 Virtualization: VT-x L1d cache: 32K L2 cache: 1024K L3 cache: 28160K NUMA node0 CPU(s): 0-11,24-35 NUMA node1 CPU(s): 12-23,36-47这条输出很有代表性2 个物理 CPUSocket每个 CPU 12 个物理核心Core/socket每个核心 2 个线程Thread/core所以逻辑 CPU 数 2 × 12 × 2 48也就是CPU(s)字段的值。我判断一台机器“核数”的时候习惯直接看Core(s) per socket × Socket(s)也就是物理核数。因为对于 License 计费、资源配额这些场景物理核数才是硬指标逻辑核数只是操作系统看到的执行单元。2.2 /proc/cpuinfo 怎么用才能算出准确核数相比 lscpu 的“汇总式”输出/proc/cpuinfo更适合写脚本批量处理。这个文件会按逻辑 CPU 为单位列出一大段信息每个逻辑 CPU 一个 block。[rootlocalhost ~]# grep -c processor /proc/cpuinfo 48grep -c processor统计的是逻辑 CPU 总数。想算物理 CPU 数量和物理核心数量就不能只数 processor 了要看physical id和core id这两个字段。# 物理 CPU 数量 grep physical id /proc/cpuinfo | sort -u | wc -l # 物理核心数量按 physical id core id 去重 grep -E physical id|core id /proc/cpuinfo | paste - - | sort -u | wc -l关于超线程核心判断点在siblings和cpu cores的关系。siblings表示一个物理 CPU 内所有逻辑 CPU 数cpu cores表示一个物理 CPU 内的物理核数。如果siblings是cpu cores的两倍说明开启了超线程相等则说明没有。[rootlocalhost ~]# grep -E siblings|cpu cores /proc/cpuinfo | sort -u cpu cores : 12 siblings : 24到这里就能确定这台机器开启了超线程每个物理核被操作系统识别为 2 个逻辑 CPU。对于性能调优来说如果跑的是数据库这类计算密集型业务我通常建议在 BIOS 里关掉超线程可以减少上下文切换带来的性能抖动如果跑的是虚化场景开超线程反而能提升虚拟机密度。2.3 压力测试与温度别等宕机才发现 CPU 有问题查 CPU 信息不只是看型号和核数还要确认 CPU 的实际工作状态。我处理过不少“性能差但查不出原因”的工单最后发现都是 CPU 过热降频导致的。检查当前频率和温度第一梯队命令是lscpu里的CPU MHz字段但是这个值是动态的准确性一般。更实用的是sensors命令它能直接输出每个核心的温度。[rootlocalhost ~]# sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: 55.0°C (high 92.0°C, crit 100.0°C) Core 0: 53.0°C (high 92.0°C, crit 100.0°C) Core 1: 55.0°C (high 92.0°C, crit 100.0°C) Core 2: 53.0°C (high 92.0°C, crit 100.0°C)如果sensors报No sensors found先确认是不是没装lm_sensors装完后执行sensors-detect初始化即可。做压力测试我用得比较多的是stress-ng。比如压满 16 个线程、持续 60 秒stress-ng --cpu 16 --timeout 60s压测的同时用mpstat -P ALL 1观察每个逻辑 CPU 的使用率再配合sensors看温度变化。如果发现某个核心频率上不去或者温度一路飙到 90°C 以上还不降频说明散热系统有问题大概率是硅脂干了、风扇转速异常或者机箱风道受阻。这里要特别强调一个经验服务器 CPU 长期超过 92°C 运行寿命会肉眼可见地缩短而且会引发随机性的计算错误。我在生产环境见过一台机器反复出现数据库进程崩溃查了半个月最后发现是 CPU 过热导致的内存校验错误。所以新机器上架务必先跑一轮 stress-ng 记录温度和频率基线这个数据以后排查性能问题就是最有力的对照。3. 内存信息查询容量、频率、插槽与故障定位3.1 free -h 到底该看哪一行内存排查是所有硬件故障里最隐蔽的因为操作系统本身有缓存机制单看数值很容易误判。free -h是必查命令但很多人不会看。[rootlocalhost ~]# free -h total used free shared buff/cache available Mem: 187G 107G 9.8G 4.6G 70G 74G Swap: 8.0G 2.0G 6.0G这里最容易犯的错是把free当成“剩余可用内存”。实际上buff/cache里的内存是内核用来缓存磁盘数据的当应用程序需要更多内存时这些缓存可以立刻释放。真正应该关注的是available字段它表示“在不触发 swap 的情况下还能分配给应用程序的内存大小”。我在项目里也见过不少监控告警规则还在用free做阈值结果动不动就报内存不足实际业务一点问题没有这就是用错了指标。正确的做法是监控available比如低于总内存的 10% 才需要告警。判断内存是否吃紧还有一个关键指标是 swap 的使用情况。如果free显示 swap 使用率持续增长说明内存真的不够了系统开始把进程数据换到磁盘上这会导致性能断崖式下跌。此时优先排查应用内存泄漏而不是急着加内存条。3.2 dmidecode 查内存条详情容量、频率、厂商、插槽位置free只能看总量要查看每根内存条的具体信息还得靠dmidecode -t memory。这条命令输出很长但信息很全。[rootlocalhost ~]# dmidecode -t memory | grep -E Size|Type:|Speed|Manufacturer|Part Number|Serial Number|Locator | head -40 Size: 32 GB Type: DDR4 Speed: 2933 MT/s Manufacturer: Samsung Part Number: M393A4K40CB1-CRC Serial Number: 1537D8A3 Locator: DIMM_A1 Size: No Module Installed Locator: DIMM_A2这里有个细节Size: No Module Installed表示对应插槽是空的。排查内存问题时插槽位置信息至关重要。比如服务器报告某个内存通道有故障你要能在现场快速定位是哪根内存条、拔哪一根而不是拆开机箱瞎找。判断内存是否组成双通道看Locator的命名规则。一般 A1、B1、C1、D1 这类跨通道对齐的内存槽位成对插上相同型号的内存就能组成多通道。如果两根容量、频率完全一致的内存条插在了同一通道的两个槽位上带宽只能翻一半性能损失在实际的高并发场景里非常明显。还有一个容易忽略的点内存频率。DDR4 内存标称 2933 MT/s如果实际跑在 2133 MT/s通常是 CPU 或主板不支持这么高的频率或者 BIOS 里没开 XMP 对应的内存配置。买内存条前一定先查 CPU 规格表支持的最高频率否则白白多花钱。3.3 内存故障排查dmesg、Machine Check 与 ECC内存故障是最难排查的硬件问题之一因为它出问题时不像磁盘那样有直接的 I/O 报错而是表现为随机性的进程崩溃、系统重启、文件校验失败。这类问题有一个相对集中的排查入口dmesg中的 Machine Check 日志。当内存出现不可纠正错误时内核会记录类似mce: [Hardware Error]: Machine check events logged的信息配合mcelog服务能解析出更详细的报错地址和内存槽位。[rootlocalhost ~]# grep -i mce\|machine check /var/log/messages Jun 10 03:22:17 localhost kernel: mce: [Hardware Error]: Machine check events logged在排查场景中我总结了一套比较实用的流程先看dmesg | grep -i error\|fail确认是否存在内存控制器相关的报错。用dmidecode -t memory确认每根内存条是否支持 ECC以及 ECC 功能是否开启。用memtester或mcelog做内存压力测试定位出问题的具体内存条。服务器支持内存隔离的可以在 BIOS 里禁用一个通道继续跑同时联系厂商更换。ECC 内存的好处是能纠正单比特错误但双比特或多比特错误还是会触发 Machine Check。如果日志里频繁出现 ECC 纠错记录不要心存侥幸大概率是内存颗粒开始老化尽早换掉比到时候数据损坏划算得多。4. 磁盘与文件系统从识别硬件到判断健康状态4.1 lsblk、df、blkid 三板斧磁盘信息查询我最常用的三条命令是lsblk、df和blkid。它们解决的问题各不相同lsblk看块设备结构df看文件系统使用率blkid看文件系统类型和 UUID。[rootlocalhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 1.8T 0 part └─centos-root 253:0 0 1.8T 0 lvm /这里lsblk最实用的参数是-d只显示磁盘不显示分区-o MODEL,SERIAL,SIZE可以直接查看磁盘型号和序列号写资产台账的时候特别好用。[rootlocalhost ~]# lsblk -d -o NAME,MODEL,SERIAL,SIZE NAME MODEL SERIAL SIZE sda Samsung SSD 870 EVO S3Z7NB0K123456 1.8Tdf -hT用来查文件系统使用率参数-T会显示文件系统类型这个很重要。比如同样是根分区xfs 和 ext4 的扩容、修复命令完全不同必须先看清类型再动手。[rootlocalhost ~]# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/centos-root xfs 1.8T 135G 1.7T 8% /blkid查看 UUID 和文件系统类型这个在配置 fstab 自动挂载和扩容操作时必须用到。注意永远不要在 fstab 里写 /dev/sda1 这种设备名因为重启后设备名可能变化尤其是多块磁盘的机器强烈建议用 UUID。4.2 SMART 健康检测与性能基线磁盘健康状态靠文件系统使用率是看不出来的。一块硬盘可能文件系统使用率才 20%但坏块已经开始出现了。判断磁盘健康状态要用smartctl。[rootlocalhost ~]# smartctl -a /dev/sda START OF INFORMATION SECTION Device Model: Samsung SSD 870 EVO Serial Number: S3Z7NB0K123456 Firmware Version: 2B6Q SMART support is: Enabled START OF READ SMART DATA SECTION SMART overall-health self-assessment test result: PASSED ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 857 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 32 177 Wear_Leveling_Count 0x0013 099 099 005 Pre-fail Always - 14 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0我最关注的几个属性Reallocated_Sector_Ct重映射扇区数只要这个值开始增长说明磁盘物理坏道正在出现必须尽快备份数据并更换。Power_On_Hours机械硬盘的标准寿命一般按 3-5 万小时算超过这个数就算没坏也不建议承载关键业务。Wear_Leveling_Count磨损均衡次数这个是 SSD 专属的健康指标数值接近阈值说明闪存寿命快到了。Program_Fail_Cnt和Runtime_Bad_Block出现非零值基本可以直接判定 SSD 内部出错。机械硬盘还可以用smartctl -t short做一个短时间自检一般几分钟内出结果。注意短期自检虽然不打断正常业务但长时间自检期间磁盘性能会明显下降不要在生产高峰跑长测。对于 NVMe 固态硬盘查健康状态的命令略有不同需要加-d nvme参数或者用nvme smart-log。很多新手直接在 NVMe 盘上跑smartctl -a /dev/nvme0n1报错就是少加了设备类型参数。4.3 磁盘阵列与性能监控企业级服务器很少让磁盘“裸奔”多数会组成 RAID 阵列。查看 RAID 状态时先分清楚是软件 RAID 还是硬件 RAID。软件 RAID如 mdraid用mdadm --detail /dev/md0查看[rootlocalhost ~]# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon May 8 10:00:00 2023 Raid Level : raid10 Array Size : 5860532224 (5589.05 GiB) Dev Size : 5860532224 (5589.05 GiB) Raid Devices : 8 Total Devices : 8 Persistence : Superblock is persistent Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 2 8 48 2 active sync /dev/sdd 3 8 64 3 active sync /dev/sde 4 8 80 4 active sync /dev/sdf 5 8 96 5 active sync /dev/sdg 6 8 112 6 active sync /dev/sdh 7 8 128 7 active sync /dev/sdi Resync Status : 3% complete看到Resync Status百分比在增长说明阵列正在后台重建通常是有一块盘被换掉了。这种情况业务还能继续跑但已经没有冗余能力必须尽快补充热备盘。硬件 RAID 卡LSI、Broadcom 等的命令是storcli或megacli查看逻辑盘状态storcli /c0 show all | grep -E State|Size|Level性能监控方面iostat是我日常排查磁盘性能问题的主力工具。iostat -x 1每秒输出一次详细指标重点看%util、await、svctm。[rootlocalhost ~]# iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 2.00 0.00 24.00 24.00 0.00 0.50 0.00 0.50 0.25 0.05判断磁盘性能是否成为瓶颈%util是一个参照但不是绝对标准。一块 SATA 机械盘%util长期超过 90%基本可以断定磁盘满了但如果是一块 NVMe SSD%util达到 90% 可能还有很大余量因为 SSD 的并发处理能力远强于机械盘。更准确的判断是看await如果应用平均每次 I/O 等待超过几十毫秒且业务侧响应变慢磁盘性能才是真瓶颈。5. 网卡与扩展设备链路速率、驱动与吞吐瓶颈5.1 lspci ethtool 确认网卡能力网络是运维排查里最让人头疼的环节之一因为问题可能出在网卡、驱动、交换机、光纤、配置等多个层面。查硬件信息时先用lspci确认当前机器有什么样的网络控制器。[rootlocalhost ~]# lspci | grep -i ethernet 02:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01) 02:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01)lspci输出的第一列是 PCI 设备地址后面能看到设备名和厂商。这里要注意云主机或虚拟机上执行lspci看到的往往是虚拟网卡如 Virtio和物理机型号没有对应关系这时候以云平台控制台信息为准。确认物理网卡实际协商速率用ethtool[rootlocalhost ~]# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 1000baseT/Full 10000baseT/Full Supported pause frame use: No Advertised link modes: 1000baseT/Full 10000baseT/Full Speed: 10000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: onSpeed字段就是实际协商出来的速率。我处理过不少“带宽买够了但速度上不去”的工单多数是网线质量差或者网口接触不良导致 10G 网卡协商成了 1G 甚至 100M。排查思路很简单ethtool eth0看协商速率再检查日志里是否有链路反复 up/down 的记录。5.2 驱动、队列与中断检查网卡性能瓶颈经常不在带宽本身而在中断处理和队列配置。ethtool -i eth0可以查驱动版本和固件版本[rootlocalhost ~]# ethtool -i eth0 driver: ixgbe version: 5.8.0 firmware-version: 0x80000933对于多队列网卡ethtool -l eth0可以查看当前支持的队列数。如果Combined的队列数为 1说明 RSSReceive Side Scaling没有正确启用十个网卡核心打满时只能用一个 CPU 处理中断性能会断崖式下跌。[rootlocalhost ~]# ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: RX: 0 TX: 0 Other: 1 Combined: 16 Current hardware settings: RX: 0 TX: 0 Other: 1 Combined: 16不过在现代系统里内核已经默认会给每个队列绑定一个 CPU通常不需要手动设置。真正需要人工介入的场景是业务流量很大但发现某个 CPU 的软中断si占比接近 100%其他 CPU 却很闲。这时候需要检查 irqbalance 是否把中断均匀分配到了各个 CPU或者直接调整网卡队列绑定。5.3 GPU 与 PCIe 设备速查除了网卡GPU 也是现在服务器里最常见的扩展设备。查 GPU 信息第一命令是lspci | grep -i vga[rootlocalhost ~]# lspci | grep -i vga 01:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)NVIDIA 显卡还可以用nvidia-smi查看更完整的信息包括显存、驱动版本、温度、利用率[rootlocalhost ~]# nvidia-smi ----------------------------------------------------------------------------- | NVIDIA-SMI 470.57.02 Driver Version: 470.57.02 CUDA Version: 11.4 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | || | 0 GeForce RTX 3090 On | 00000000:01:00.0 Off | N/A | | 30% 48C P0 52W / 350W| 0MiB / 24576MiB | 0% Default | ---------------------------------------------------------------------------很多基于 GPU 的推理任务出问题第一步就是看nvidia-smi里显存是否被占满、GPU 利用率是否异常、温度是否过高。如果显存占用很高但利用率很低大概率是显存碎片化或者 CUDA 上下文没有被正确释放而不是硬件坏了。6. 硬件故障排查实录从系统日志到实战思路6.1 dmesg 与 journalctl 的用法硬件出问题时Linux 内核会在环形缓冲区里记录大量信息dmesg就是查看这些信息的入口。对于一台已经跑了很久的服务器dmesg输出的内容非常多需要配合过滤条件使用。# 查看硬件错误相关日志 dmesg | grep -iE error|fail|warn # 查看硬盘、ATA、SATA相关日志 dmesg | grep -iE ata|sda|sd|cache # 查看 PCIe 相关错误 dmesg | grep -iE pcie|aer对于系统重启后的日志我更推荐用journalctl。journalctl -k -b -1查看上一次启动的内核日志这个参数在排查“重启后业务异常”的场景时非常有用。# 查看当前启动的内核日志 journalctl -k -b # 查看上一次启动的内核日志系统重启后想确认之前崩溃的原因 journalctl -k -b -1有一点要注意dmesg的环形缓冲区是有限大小的新日志会覆盖旧日志。如果系统已经运行很久很多问题痕迹会被冲掉。所以在排查硬件问题时我习惯先做一次dmesg -T /root/dmesg_$(date %Y%m%d).log把现场保存下来再开始分析。6.2 三个典型的硬件故障排查案例案例一随机内存错误导致数据库进程崩溃。现象是数据库每隔几天就 crash 一次应用日志里没有明显异常系统也没有宕机。通过dmesg | grep -i mce看到大量 Machine Check 记录再用mcelog --client解析出错地址定位到 DIMM_B1 插槽的一根内存条替换后故障消失。这类问题最坑的地方在于错误是间歇性的不加日志留存很难抓住现场。案例二SSD 磨损导致写入性能骤降。现象是某台监控服务器磁盘写入变慢df显示使用率只有 40%看起来一切正常。但iostat -x 1显示%util持续 100%smartctl -a发现Wear_Leveling_Count已经到阈值。这块 SSD 表面没有坏块但闪存寿命已经耗尽写入时内部要做大量垃圾回收所以性能断崖。处理方案是立刻迁移业务并更换磁盘。案例三网卡降速引发业务超时。现象是某业务集群响应时快时慢网络流量并不大。用ethtool eth0发现 Speed 是 100Mb/s但网卡明明支持 10Gb/s。重新插拔网线后恢复正常后来排查发现是网线头松动导致的协商降速。这个案例提醒我查网络问题一定要先看物理层协商速率再做协议层抓包顺序不能反。6.3 排查硬件故障的方法论我把硬件故障排查思路总结成四个步骤按优先级排序日志优先先通过dmesg、journalctl查看内核日志确认是否有明确的硬件错误记录。状态速查用smartctl、sensors、ethtool检查磁盘健康、CPU 温度、网卡协商状态。性能对照用iostat、mpstat看资源利用率是否异常和健康状态时的基线数据做对比。替换验证如果定位到具体硬件设备且具备冗余条件如双网卡、RAID 阵列可以先让业务切换到备用设备再验证故障是否消失。这套方法看起来简单但很多运维在实际处理时会跳过第 1、2 步直接做第 4 步结果东换西换了一堆硬件问题还在浪费时间也容易引发业务风险。7. 命令速查表与避坑指南7.1 按场景整理的常用命令速查表把本文提到的命令整理成速查表贴在手边随时查阅。查询目标命令关键输出字段适用场景操作系统/内核uname -a内核版本、架构驱动安装、内核升级系统及虚拟化信息hostnamectlOS、Kernel、Virtualization判断物理机/虚拟机厂商型号序列号dmidecode -t systemManufacturer、Product、Serial资产台账、报修BIOS 信息dmidecode -t biosVersion、Release Date固件升级排查CPU 汇总信息lscpuSocket、Core、Thread、MHz核数确认、超线程判断CPU 明细grep processor /proc/cpuinfoprocessor id脚本批量采集CPU 实时温度sensorsCore0 温度、crit 阈值散热排查内存总量和可用量free -htotal、available内存不足告警内存条详情dmidecode -t memorySize、Speed、Locator扩容、故障定位磁盘设备结构lsblkNAME、TYPE、MOUNTPOINT查看盘符对应关系文件系统使用率df -hT文件系统、Use%磁盘满告警磁盘健康状态smartctl -a /dev/sdaReallocated_Sector_Ct、Power_On_Hours坏盘预判磁盘性能iostat -x 1%util、await、svctm性能瓶颈排查网卡型号lspci | grep -i ethernetEthernet controller确认硬件型号网卡速率协商ethtool eth0Speed、Duplex链路降速排查网卡驱动信息ethtool -i eth0driver、version驱动版本确认GPU 信息nvidia-smi显存、温度、利用率GPU 推理、训练环境内核错误日志dmesg | grep -i error报错上下文硬件故障定位上次启动日志journalctl -k -b -1内核报错重启原因排查7.2 我的几条实操避坑经验第一别在虚拟化平台上迷信 dmidecode。云主机和虚拟机里dmidecode返回的几乎都是虚拟化层伪装的信息不能代表物理硬件。这在日常排查中最容易把人带偏我见过有人对着云服务器查“主板序列号”查了半天最后发现是 KVM 虚拟出来的。判断物理机和虚拟机优先看hostnamectl的Virtualization字段。第二新机器上架先建基线。我在入职运维团队后养成了一个习惯任何新服务器上架先跑一遍完整的硬件信息采集把 CPU 型号、内存条数、磁盘型号、SMART 状态、网卡协商速率、工作温度全部记录下来存成基线文档。后面出任何硬件问题拿当前数据和基线一对照排查速度快好几倍。第三不能只看 df 判断磁盘空间。df显示的是文件系统使用率磁盘可能存在大量已删除但仍被进程占用的文件导致空间不释放。这时候用lsof | grep deleted能找到占用文件的进程重启对应服务才能释放空间。如果df显示 inode 满了但空间没满则是小文件过多需要检查目录里的文件数量。第四SMART 信息不是所有盘都能查。RAID 卡直通的磁盘操作系统往往看不到 SMART 信息这时要用smartctl -d scsi或者 RAID 卡厂商的专用工具。NVMe 盘则需要指定-d nvme。看到smartctl报错时先检查设备和控制器类型再判断是不是命令格式问题。第五日志留存的优先级高于一切。排查硬件问题最怕没有现场数据。我的做法是给所有服务器配置内核日志转发journalctl的日志持久化开启同时定期把dmesg快照保存到独立分区。这样即使系统彻底挂掉也能拿到故障前最后时刻的日志记录。最后再分享一个小技巧把所有硬件信息采集命令封装成一个脚本输出成 JSON 格式存入 CMDB。这样后续无论是监控平台展示、容量规划还是巡检报告都能直接拿数据说话不用每次查命令重新敲一遍。我在实际运维中把整套采集脚本放到了纳管的几百台服务器上效果非常稳定也省掉了大量重复沟通成本。硬件信息速查这件事说到底不是背多少命令的问题而是形成一套自己的排查流程并持续把流程固化下来。 Linux服务器硬件信息查询命令全指南
接手服务器第一件事是什么不是急着装系统、跑业务而是先把它看懂。在运维一线摸爬滚打这么多年我几乎每次遇到硬件故障、容量评估、机房搬迁都得靠一套固定的命令组合把服务器从里到外摸一遍。很多刚入行的同事喜欢先打开监控面板点来点去就几张图表真到了抢修现场还是命令行最顶用。这篇文章就把 Linux 下查硬件信息最高频、最实用的一组命令完整梳理一遍覆盖整机信息、CPU、内存、磁盘、网卡、扩展设备以及日志排查适合刚接手服务器的新手也适合想把速查手册整理得更系统一点的老运维。所有命令我都以 x86 平台为主同时兼顾 ARM鲲鹏、飞腾等国产平台的区别给出的参数和判断方法都是可以直接抄作业的。1. 整机与平台信息速查先把服务器“验明正身”1.1 三件套命令uname、hostnamectl、dmidecode拿到一台陌生服务器第一步不是跑业务而是先确认这台机器是什么厂商、什么型号、什么架构、跑了什么系统。这三条命令可以解决大部分问题。先说uname -a这是最基础的一条。它能输出内核名称、主机名、内核版本、硬件架构等信息。在实际使用中我最常看的其实是uname -r后面的内核版本号因为很多驱动、内核参数优化都和版本强相关。比如你装了某个网卡厂商的驱动结果发现编译不过先看一眼内核版本往往问题就出在版本不匹配上。[rootlocalhost ~]# uname -a Linux localhost 4.18.0-80.el8.x86_64 #1 SMP Tue Jun 4 12:41:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux再来看hostnamectl这条命令比 uname 更“懂事”一些直接以结构化方式展示操作系统、内核、架构、虚拟化类型等信息。它最大的优势是能看出虚拟化类型比如输出里出现Virtualization: kvm那基本可以判断这是一台虚拟机而不是物理机这直接决定了后续硬件排查的方向。[rootlocalhost ~]# hostnamectl Static hostname: localhost Icon name: computer-server Chassis: server Machine ID: 4c9c7d9c449a4c0ca4052cb9c5fa6f31 Boot ID: 6e2e622bd4d94de4aa929e0aa858ddd8 Virtualization: kvm Operating System: CentOS Linux 8 (Core) CPE OS Name: cpe:/o:centos:centos:8 Kernel: Linux 4.18.0-80.el8.x86_64 Architecture: x86-64最后是硬件信息查询的大杀器dmidecode。它从 SMBIOS 接口读取硬件信息能查到厂商、产品名称、序列号、BIOS 版本、内存插槽详情等。查整机信息用dmidecode -t system查主板用dmidecode -t baseboard查 BIOS 用dmidecode -t bios。这三者组合起来基本就能把一台服务器的身份信息完整录入资产台账了。[rootlocalhost ~]# dmidecode -t system # dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 3.2.0 present. Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: PowerEdge R740 Version: 01 Serial Number: 8K5H3D2 UUID: 4C4C4544-0036-3710-8051-B6C04F353432 Wake-up Type: Power Switch SKU Number: SKU-NotProvided Family: PowerEdge这里要特别提醒dmidecode需要 root 权限才能完整读取普通用户执行经常只看到一部分信息。另外在云服务器或虚拟机里dmidecode输出的厂商和序列号常常是虚拟化平台伪造的比如 KVM 的默认厂商就是QEMU、Alibaba Cloud之类看到这种情况别慌不代表物理机坏了只是说明你看到的层不对。1.2 序列号、固件版本与资产台账这些细节别忽略很多运维把服务器信息查出来就完事了序列号、固件版本却不记录等到要报修、要升级 BIOS 的时候才发现还得重新登录机器查一遍效率很低。我的习惯是新服务器上架第一件事就跑一遍硬件采集把输出重定向到一个文件里然后统一维护。比如dmidecode -t system /root/hardware_info/system.txt dmidecode -t baseboard /root/hardware_info/system.txt dmidecode -t bios /root/hardware_info/system.txt序列号Serial Number尤其重要。Dell、浪潮、华为这些厂商的售后维修都必须提供序列号才给报修没有序列号基本就得按过保处理。固件版本则是排查某些硬件 bug 的关键线索比如某些批次的 Intel CPU 存在微码问题固件版本一核对就知道该不该升级。实操中还有一个容易踩的坑批量管理几十台服务器时不能光靠记忆区分机器一定要把dmidecode -t system的输出配合主机名一起存档。我见过不止一次同事把 A 机器的序列号当成 B 机器报修结果维修工程师白跑一趟。建议统一用服务器名 序列号 厂商型号 位置这种格式维护台账字段越规范后续自动化采集越省事。用 Ansible 做批量采集也很简单一条命令就能把所有机器的硬件信息拉到控制端ansible all -m shell -a dmidecode -t system | grep -E Manufacturer|Product Name|Serial Number /root/hardware_inventory.txt2. CPU 信息解析物理核、逻辑核、超线程一次看懂2.1 lscpu 输出逐项解读CPU 信息里最容易混淆的就是“核数”。很多新手跑一条lscpu看到CPU(s): 48就以为机器有 48 个核心这个理解只有在没有超线程、且单核单线程时才成立。真实情况要结合Socket、Core、Thread三个字段一起看。[rootlocalhost ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 2 Core(s) per socket: 12 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6134 CPU 3.20GHz Stepping: 4 CPU MHz: 3690.000 BogoMIPS: 6400.00 Virtualization: VT-x L1d cache: 32K L2 cache: 1024K L3 cache: 28160K NUMA node0 CPU(s): 0-11,24-35 NUMA node1 CPU(s): 12-23,36-47这条输出很有代表性2 个物理 CPUSocket每个 CPU 12 个物理核心Core/socket每个核心 2 个线程Thread/core所以逻辑 CPU 数 2 × 12 × 2 48也就是CPU(s)字段的值。我判断一台机器“核数”的时候习惯直接看Core(s) per socket × Socket(s)也就是物理核数。因为对于 License 计费、资源配额这些场景物理核数才是硬指标逻辑核数只是操作系统看到的执行单元。2.2 /proc/cpuinfo 怎么用才能算出准确核数相比 lscpu 的“汇总式”输出/proc/cpuinfo更适合写脚本批量处理。这个文件会按逻辑 CPU 为单位列出一大段信息每个逻辑 CPU 一个 block。[rootlocalhost ~]# grep -c processor /proc/cpuinfo 48grep -c processor统计的是逻辑 CPU 总数。想算物理 CPU 数量和物理核心数量就不能只数 processor 了要看physical id和core id这两个字段。# 物理 CPU 数量 grep physical id /proc/cpuinfo | sort -u | wc -l # 物理核心数量按 physical id core id 去重 grep -E physical id|core id /proc/cpuinfo | paste - - | sort -u | wc -l关于超线程核心判断点在siblings和cpu cores的关系。siblings表示一个物理 CPU 内所有逻辑 CPU 数cpu cores表示一个物理 CPU 内的物理核数。如果siblings是cpu cores的两倍说明开启了超线程相等则说明没有。[rootlocalhost ~]# grep -E siblings|cpu cores /proc/cpuinfo | sort -u cpu cores : 12 siblings : 24到这里就能确定这台机器开启了超线程每个物理核被操作系统识别为 2 个逻辑 CPU。对于性能调优来说如果跑的是数据库这类计算密集型业务我通常建议在 BIOS 里关掉超线程可以减少上下文切换带来的性能抖动如果跑的是虚化场景开超线程反而能提升虚拟机密度。2.3 压力测试与温度别等宕机才发现 CPU 有问题查 CPU 信息不只是看型号和核数还要确认 CPU 的实际工作状态。我处理过不少“性能差但查不出原因”的工单最后发现都是 CPU 过热降频导致的。检查当前频率和温度第一梯队命令是lscpu里的CPU MHz字段但是这个值是动态的准确性一般。更实用的是sensors命令它能直接输出每个核心的温度。[rootlocalhost ~]# sensors coretemp-isa-0000 Adapter: ISA adapter Package id 0: 55.0°C (high 92.0°C, crit 100.0°C) Core 0: 53.0°C (high 92.0°C, crit 100.0°C) Core 1: 55.0°C (high 92.0°C, crit 100.0°C) Core 2: 53.0°C (high 92.0°C, crit 100.0°C)如果sensors报No sensors found先确认是不是没装lm_sensors装完后执行sensors-detect初始化即可。做压力测试我用得比较多的是stress-ng。比如压满 16 个线程、持续 60 秒stress-ng --cpu 16 --timeout 60s压测的同时用mpstat -P ALL 1观察每个逻辑 CPU 的使用率再配合sensors看温度变化。如果发现某个核心频率上不去或者温度一路飙到 90°C 以上还不降频说明散热系统有问题大概率是硅脂干了、风扇转速异常或者机箱风道受阻。这里要特别强调一个经验服务器 CPU 长期超过 92°C 运行寿命会肉眼可见地缩短而且会引发随机性的计算错误。我在生产环境见过一台机器反复出现数据库进程崩溃查了半个月最后发现是 CPU 过热导致的内存校验错误。所以新机器上架务必先跑一轮 stress-ng 记录温度和频率基线这个数据以后排查性能问题就是最有力的对照。3. 内存信息查询容量、频率、插槽与故障定位3.1 free -h 到底该看哪一行内存排查是所有硬件故障里最隐蔽的因为操作系统本身有缓存机制单看数值很容易误判。free -h是必查命令但很多人不会看。[rootlocalhost ~]# free -h total used free shared buff/cache available Mem: 187G 107G 9.8G 4.6G 70G 74G Swap: 8.0G 2.0G 6.0G这里最容易犯的错是把free当成“剩余可用内存”。实际上buff/cache里的内存是内核用来缓存磁盘数据的当应用程序需要更多内存时这些缓存可以立刻释放。真正应该关注的是available字段它表示“在不触发 swap 的情况下还能分配给应用程序的内存大小”。我在项目里也见过不少监控告警规则还在用free做阈值结果动不动就报内存不足实际业务一点问题没有这就是用错了指标。正确的做法是监控available比如低于总内存的 10% 才需要告警。判断内存是否吃紧还有一个关键指标是 swap 的使用情况。如果free显示 swap 使用率持续增长说明内存真的不够了系统开始把进程数据换到磁盘上这会导致性能断崖式下跌。此时优先排查应用内存泄漏而不是急着加内存条。3.2 dmidecode 查内存条详情容量、频率、厂商、插槽位置free只能看总量要查看每根内存条的具体信息还得靠dmidecode -t memory。这条命令输出很长但信息很全。[rootlocalhost ~]# dmidecode -t memory | grep -E Size|Type:|Speed|Manufacturer|Part Number|Serial Number|Locator | head -40 Size: 32 GB Type: DDR4 Speed: 2933 MT/s Manufacturer: Samsung Part Number: M393A4K40CB1-CRC Serial Number: 1537D8A3 Locator: DIMM_A1 Size: No Module Installed Locator: DIMM_A2这里有个细节Size: No Module Installed表示对应插槽是空的。排查内存问题时插槽位置信息至关重要。比如服务器报告某个内存通道有故障你要能在现场快速定位是哪根内存条、拔哪一根而不是拆开机箱瞎找。判断内存是否组成双通道看Locator的命名规则。一般 A1、B1、C1、D1 这类跨通道对齐的内存槽位成对插上相同型号的内存就能组成多通道。如果两根容量、频率完全一致的内存条插在了同一通道的两个槽位上带宽只能翻一半性能损失在实际的高并发场景里非常明显。还有一个容易忽略的点内存频率。DDR4 内存标称 2933 MT/s如果实际跑在 2133 MT/s通常是 CPU 或主板不支持这么高的频率或者 BIOS 里没开 XMP 对应的内存配置。买内存条前一定先查 CPU 规格表支持的最高频率否则白白多花钱。3.3 内存故障排查dmesg、Machine Check 与 ECC内存故障是最难排查的硬件问题之一因为它出问题时不像磁盘那样有直接的 I/O 报错而是表现为随机性的进程崩溃、系统重启、文件校验失败。这类问题有一个相对集中的排查入口dmesg中的 Machine Check 日志。当内存出现不可纠正错误时内核会记录类似mce: [Hardware Error]: Machine check events logged的信息配合mcelog服务能解析出更详细的报错地址和内存槽位。[rootlocalhost ~]# grep -i mce\|machine check /var/log/messages Jun 10 03:22:17 localhost kernel: mce: [Hardware Error]: Machine check events logged在排查场景中我总结了一套比较实用的流程先看dmesg | grep -i error\|fail确认是否存在内存控制器相关的报错。用dmidecode -t memory确认每根内存条是否支持 ECC以及 ECC 功能是否开启。用memtester或mcelog做内存压力测试定位出问题的具体内存条。服务器支持内存隔离的可以在 BIOS 里禁用一个通道继续跑同时联系厂商更换。ECC 内存的好处是能纠正单比特错误但双比特或多比特错误还是会触发 Machine Check。如果日志里频繁出现 ECC 纠错记录不要心存侥幸大概率是内存颗粒开始老化尽早换掉比到时候数据损坏划算得多。4. 磁盘与文件系统从识别硬件到判断健康状态4.1 lsblk、df、blkid 三板斧磁盘信息查询我最常用的三条命令是lsblk、df和blkid。它们解决的问题各不相同lsblk看块设备结构df看文件系统使用率blkid看文件系统类型和 UUID。[rootlocalhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 1.8T 0 part └─centos-root 253:0 0 1.8T 0 lvm /这里lsblk最实用的参数是-d只显示磁盘不显示分区-o MODEL,SERIAL,SIZE可以直接查看磁盘型号和序列号写资产台账的时候特别好用。[rootlocalhost ~]# lsblk -d -o NAME,MODEL,SERIAL,SIZE NAME MODEL SERIAL SIZE sda Samsung SSD 870 EVO S3Z7NB0K123456 1.8Tdf -hT用来查文件系统使用率参数-T会显示文件系统类型这个很重要。比如同样是根分区xfs 和 ext4 的扩容、修复命令完全不同必须先看清类型再动手。[rootlocalhost ~]# df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/centos-root xfs 1.8T 135G 1.7T 8% /blkid查看 UUID 和文件系统类型这个在配置 fstab 自动挂载和扩容操作时必须用到。注意永远不要在 fstab 里写 /dev/sda1 这种设备名因为重启后设备名可能变化尤其是多块磁盘的机器强烈建议用 UUID。4.2 SMART 健康检测与性能基线磁盘健康状态靠文件系统使用率是看不出来的。一块硬盘可能文件系统使用率才 20%但坏块已经开始出现了。判断磁盘健康状态要用smartctl。[rootlocalhost ~]# smartctl -a /dev/sda START OF INFORMATION SECTION Device Model: Samsung SSD 870 EVO Serial Number: S3Z7NB0K123456 Firmware Version: 2B6Q SMART support is: Enabled START OF READ SMART DATA SECTION SMART overall-health self-assessment test result: PASSED ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 857 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 32 177 Wear_Leveling_Count 0x0013 099 099 005 Pre-fail Always - 14 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0我最关注的几个属性Reallocated_Sector_Ct重映射扇区数只要这个值开始增长说明磁盘物理坏道正在出现必须尽快备份数据并更换。Power_On_Hours机械硬盘的标准寿命一般按 3-5 万小时算超过这个数就算没坏也不建议承载关键业务。Wear_Leveling_Count磨损均衡次数这个是 SSD 专属的健康指标数值接近阈值说明闪存寿命快到了。Program_Fail_Cnt和Runtime_Bad_Block出现非零值基本可以直接判定 SSD 内部出错。机械硬盘还可以用smartctl -t short做一个短时间自检一般几分钟内出结果。注意短期自检虽然不打断正常业务但长时间自检期间磁盘性能会明显下降不要在生产高峰跑长测。对于 NVMe 固态硬盘查健康状态的命令略有不同需要加-d nvme参数或者用nvme smart-log。很多新手直接在 NVMe 盘上跑smartctl -a /dev/nvme0n1报错就是少加了设备类型参数。4.3 磁盘阵列与性能监控企业级服务器很少让磁盘“裸奔”多数会组成 RAID 阵列。查看 RAID 状态时先分清楚是软件 RAID 还是硬件 RAID。软件 RAID如 mdraid用mdadm --detail /dev/md0查看[rootlocalhost ~]# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon May 8 10:00:00 2023 Raid Level : raid10 Array Size : 5860532224 (5589.05 GiB) Dev Size : 5860532224 (5589.05 GiB) Raid Devices : 8 Total Devices : 8 Persistence : Superblock is persistent Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 2 8 48 2 active sync /dev/sdd 3 8 64 3 active sync /dev/sde 4 8 80 4 active sync /dev/sdf 5 8 96 5 active sync /dev/sdg 6 8 112 6 active sync /dev/sdh 7 8 128 7 active sync /dev/sdi Resync Status : 3% complete看到Resync Status百分比在增长说明阵列正在后台重建通常是有一块盘被换掉了。这种情况业务还能继续跑但已经没有冗余能力必须尽快补充热备盘。硬件 RAID 卡LSI、Broadcom 等的命令是storcli或megacli查看逻辑盘状态storcli /c0 show all | grep -E State|Size|Level性能监控方面iostat是我日常排查磁盘性能问题的主力工具。iostat -x 1每秒输出一次详细指标重点看%util、await、svctm。[rootlocalhost ~]# iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.00 0.00 2.00 0.00 24.00 24.00 0.00 0.50 0.00 0.50 0.25 0.05判断磁盘性能是否成为瓶颈%util是一个参照但不是绝对标准。一块 SATA 机械盘%util长期超过 90%基本可以断定磁盘满了但如果是一块 NVMe SSD%util达到 90% 可能还有很大余量因为 SSD 的并发处理能力远强于机械盘。更准确的判断是看await如果应用平均每次 I/O 等待超过几十毫秒且业务侧响应变慢磁盘性能才是真瓶颈。5. 网卡与扩展设备链路速率、驱动与吞吐瓶颈5.1 lspci ethtool 确认网卡能力网络是运维排查里最让人头疼的环节之一因为问题可能出在网卡、驱动、交换机、光纤、配置等多个层面。查硬件信息时先用lspci确认当前机器有什么样的网络控制器。[rootlocalhost ~]# lspci | grep -i ethernet 02:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01) 02:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10G X550T (rev 01)lspci输出的第一列是 PCI 设备地址后面能看到设备名和厂商。这里要注意云主机或虚拟机上执行lspci看到的往往是虚拟网卡如 Virtio和物理机型号没有对应关系这时候以云平台控制台信息为准。确认物理网卡实际协商速率用ethtool[rootlocalhost ~]# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 1000baseT/Full 10000baseT/Full Supported pause frame use: No Advertised link modes: 1000baseT/Full 10000baseT/Full Speed: 10000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: onSpeed字段就是实际协商出来的速率。我处理过不少“带宽买够了但速度上不去”的工单多数是网线质量差或者网口接触不良导致 10G 网卡协商成了 1G 甚至 100M。排查思路很简单ethtool eth0看协商速率再检查日志里是否有链路反复 up/down 的记录。5.2 驱动、队列与中断检查网卡性能瓶颈经常不在带宽本身而在中断处理和队列配置。ethtool -i eth0可以查驱动版本和固件版本[rootlocalhost ~]# ethtool -i eth0 driver: ixgbe version: 5.8.0 firmware-version: 0x80000933对于多队列网卡ethtool -l eth0可以查看当前支持的队列数。如果Combined的队列数为 1说明 RSSReceive Side Scaling没有正确启用十个网卡核心打满时只能用一个 CPU 处理中断性能会断崖式下跌。[rootlocalhost ~]# ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: RX: 0 TX: 0 Other: 1 Combined: 16 Current hardware settings: RX: 0 TX: 0 Other: 1 Combined: 16不过在现代系统里内核已经默认会给每个队列绑定一个 CPU通常不需要手动设置。真正需要人工介入的场景是业务流量很大但发现某个 CPU 的软中断si占比接近 100%其他 CPU 却很闲。这时候需要检查 irqbalance 是否把中断均匀分配到了各个 CPU或者直接调整网卡队列绑定。5.3 GPU 与 PCIe 设备速查除了网卡GPU 也是现在服务器里最常见的扩展设备。查 GPU 信息第一命令是lspci | grep -i vga[rootlocalhost ~]# lspci | grep -i vga 01:00.0 VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)NVIDIA 显卡还可以用nvidia-smi查看更完整的信息包括显存、驱动版本、温度、利用率[rootlocalhost ~]# nvidia-smi ----------------------------------------------------------------------------- | NVIDIA-SMI 470.57.02 Driver Version: 470.57.02 CUDA Version: 11.4 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | || | 0 GeForce RTX 3090 On | 00000000:01:00.0 Off | N/A | | 30% 48C P0 52W / 350W| 0MiB / 24576MiB | 0% Default | ---------------------------------------------------------------------------很多基于 GPU 的推理任务出问题第一步就是看nvidia-smi里显存是否被占满、GPU 利用率是否异常、温度是否过高。如果显存占用很高但利用率很低大概率是显存碎片化或者 CUDA 上下文没有被正确释放而不是硬件坏了。6. 硬件故障排查实录从系统日志到实战思路6.1 dmesg 与 journalctl 的用法硬件出问题时Linux 内核会在环形缓冲区里记录大量信息dmesg就是查看这些信息的入口。对于一台已经跑了很久的服务器dmesg输出的内容非常多需要配合过滤条件使用。# 查看硬件错误相关日志 dmesg | grep -iE error|fail|warn # 查看硬盘、ATA、SATA相关日志 dmesg | grep -iE ata|sda|sd|cache # 查看 PCIe 相关错误 dmesg | grep -iE pcie|aer对于系统重启后的日志我更推荐用journalctl。journalctl -k -b -1查看上一次启动的内核日志这个参数在排查“重启后业务异常”的场景时非常有用。# 查看当前启动的内核日志 journalctl -k -b # 查看上一次启动的内核日志系统重启后想确认之前崩溃的原因 journalctl -k -b -1有一点要注意dmesg的环形缓冲区是有限大小的新日志会覆盖旧日志。如果系统已经运行很久很多问题痕迹会被冲掉。所以在排查硬件问题时我习惯先做一次dmesg -T /root/dmesg_$(date %Y%m%d).log把现场保存下来再开始分析。6.2 三个典型的硬件故障排查案例案例一随机内存错误导致数据库进程崩溃。现象是数据库每隔几天就 crash 一次应用日志里没有明显异常系统也没有宕机。通过dmesg | grep -i mce看到大量 Machine Check 记录再用mcelog --client解析出错地址定位到 DIMM_B1 插槽的一根内存条替换后故障消失。这类问题最坑的地方在于错误是间歇性的不加日志留存很难抓住现场。案例二SSD 磨损导致写入性能骤降。现象是某台监控服务器磁盘写入变慢df显示使用率只有 40%看起来一切正常。但iostat -x 1显示%util持续 100%smartctl -a发现Wear_Leveling_Count已经到阈值。这块 SSD 表面没有坏块但闪存寿命已经耗尽写入时内部要做大量垃圾回收所以性能断崖。处理方案是立刻迁移业务并更换磁盘。案例三网卡降速引发业务超时。现象是某业务集群响应时快时慢网络流量并不大。用ethtool eth0发现 Speed 是 100Mb/s但网卡明明支持 10Gb/s。重新插拔网线后恢复正常后来排查发现是网线头松动导致的协商降速。这个案例提醒我查网络问题一定要先看物理层协商速率再做协议层抓包顺序不能反。6.3 排查硬件故障的方法论我把硬件故障排查思路总结成四个步骤按优先级排序日志优先先通过dmesg、journalctl查看内核日志确认是否有明确的硬件错误记录。状态速查用smartctl、sensors、ethtool检查磁盘健康、CPU 温度、网卡协商状态。性能对照用iostat、mpstat看资源利用率是否异常和健康状态时的基线数据做对比。替换验证如果定位到具体硬件设备且具备冗余条件如双网卡、RAID 阵列可以先让业务切换到备用设备再验证故障是否消失。这套方法看起来简单但很多运维在实际处理时会跳过第 1、2 步直接做第 4 步结果东换西换了一堆硬件问题还在浪费时间也容易引发业务风险。7. 命令速查表与避坑指南7.1 按场景整理的常用命令速查表把本文提到的命令整理成速查表贴在手边随时查阅。查询目标命令关键输出字段适用场景操作系统/内核uname -a内核版本、架构驱动安装、内核升级系统及虚拟化信息hostnamectlOS、Kernel、Virtualization判断物理机/虚拟机厂商型号序列号dmidecode -t systemManufacturer、Product、Serial资产台账、报修BIOS 信息dmidecode -t biosVersion、Release Date固件升级排查CPU 汇总信息lscpuSocket、Core、Thread、MHz核数确认、超线程判断CPU 明细grep processor /proc/cpuinfoprocessor id脚本批量采集CPU 实时温度sensorsCore0 温度、crit 阈值散热排查内存总量和可用量free -htotal、available内存不足告警内存条详情dmidecode -t memorySize、Speed、Locator扩容、故障定位磁盘设备结构lsblkNAME、TYPE、MOUNTPOINT查看盘符对应关系文件系统使用率df -hT文件系统、Use%磁盘满告警磁盘健康状态smartctl -a /dev/sdaReallocated_Sector_Ct、Power_On_Hours坏盘预判磁盘性能iostat -x 1%util、await、svctm性能瓶颈排查网卡型号lspci | grep -i ethernetEthernet controller确认硬件型号网卡速率协商ethtool eth0Speed、Duplex链路降速排查网卡驱动信息ethtool -i eth0driver、version驱动版本确认GPU 信息nvidia-smi显存、温度、利用率GPU 推理、训练环境内核错误日志dmesg | grep -i error报错上下文硬件故障定位上次启动日志journalctl -k -b -1内核报错重启原因排查7.2 我的几条实操避坑经验第一别在虚拟化平台上迷信 dmidecode。云主机和虚拟机里dmidecode返回的几乎都是虚拟化层伪装的信息不能代表物理硬件。这在日常排查中最容易把人带偏我见过有人对着云服务器查“主板序列号”查了半天最后发现是 KVM 虚拟出来的。判断物理机和虚拟机优先看hostnamectl的Virtualization字段。第二新机器上架先建基线。我在入职运维团队后养成了一个习惯任何新服务器上架先跑一遍完整的硬件信息采集把 CPU 型号、内存条数、磁盘型号、SMART 状态、网卡协商速率、工作温度全部记录下来存成基线文档。后面出任何硬件问题拿当前数据和基线一对照排查速度快好几倍。第三不能只看 df 判断磁盘空间。df显示的是文件系统使用率磁盘可能存在大量已删除但仍被进程占用的文件导致空间不释放。这时候用lsof | grep deleted能找到占用文件的进程重启对应服务才能释放空间。如果df显示 inode 满了但空间没满则是小文件过多需要检查目录里的文件数量。第四SMART 信息不是所有盘都能查。RAID 卡直通的磁盘操作系统往往看不到 SMART 信息这时要用smartctl -d scsi或者 RAID 卡厂商的专用工具。NVMe 盘则需要指定-d nvme。看到smartctl报错时先检查设备和控制器类型再判断是不是命令格式问题。第五日志留存的优先级高于一切。排查硬件问题最怕没有现场数据。我的做法是给所有服务器配置内核日志转发journalctl的日志持久化开启同时定期把dmesg快照保存到独立分区。这样即使系统彻底挂掉也能拿到故障前最后时刻的日志记录。最后再分享一个小技巧把所有硬件信息采集命令封装成一个脚本输出成 JSON 格式存入 CMDB。这样后续无论是监控平台展示、容量规划还是巡检报告都能直接拿数据说话不用每次查命令重新敲一遍。我在实际运维中把整套采集脚本放到了纳管的几百台服务器上效果非常稳定也省掉了大量重复沟通成本。硬件信息速查这件事说到底不是背多少命令的问题而是形成一套自己的排查流程并持续把流程固化下来。