计算机硬件测试这行，真正上手的第一道坎，往往不是测试软件怎么用，而是你连被测服务器都"看不明白"。我带过不少新人，第一天进机房对着机器发懵太常见了：电源灯是绿的，系统却进不去；IP明明配了，远程死活连不上；让人去查配置，只会开设备管理器。服务器测试的起点，不是跑压力软件，而是先学会用Linux把一台机器的家底盘清楚。这也是我做"服务器测试百日学习计划"的原因——用一百天，把测试工程师真正吃饭的Linux基本功、硬件认知、性能分析工具链一点点啃下来。今天先发Day1：Linux基础与硬件查看，把这台机器到底什么配置、什么状态，用命令一条条问明白。

这个计划适合谁？准备入行服务器测试、运维、硬件测试的应届生，也适合做客户端测试想转服务端方向的工程师。你不需要有Linux基础，但需要有一颗愿意敲命令、看报错、查文档的心。Day1我们不聊虚的，直接讲三件事：Linux操作的基本体感、硬件信息的查看命令怎么用、以及怎么把零散命令组合成一套可复用的巡检思路。

1. 服务器测试为什么非Linux不可：先把动机搞明白

很多刚接触服务器的人会有个疑问：Windows也能跑测试工具，为什么服务器厂商、数据中心、云厂商出来的测试报告清一色Linux？这不是行业惯性，而是由服务器的工作环境决定的。

1.1 被测对象本身就是Linux环境

你测的服务器，最终交付给客户跑的是什么系统？绝大多数是Linux发行版，比如CentOS、Ubuntu Server、Debian，或是基于这些定制的商业发行版。客户部署的数据库、容器、虚拟化平台，也基本都跑在Linux上。测试的意义是尽可能还原真实使用场景，如果你在Windows下测出来的CPU性能数据，和客户在Linux下跑的结果差异很大，那这份报告的价值就打了折扣。所以服务器测试不是"会不会Linux"的问题，而是"你测的东西就在Linux里跑着"，你不会Linux，连门都摸不着。

1.2 命令行比图形界面更接近硬件本身

Windows的设备管理器、任务管理器确实直观，但说实话，它对硬件细节的暴露程度很低，而且自动化能力基本为零。服务器的硬件查看，本质上是从操作系统层面去"询问"总线上的设备、注册的驱动、固件暴露的信息。Linux的命令行生态在这方面极其丰富：lscpu看处理器信息，free看内存状态，lsblk看块设备拓扑，lspci枚举PCI设备。这些命令输出的信息密度、可解析性、可脚本化程度，远非图形界面能比。

1.3 测试本身就是一堆命令的组合

做性能测试的时候，你会用fio测磁盘、用stress或sysbench压CPU和内存、用iperf3测网络吞吐。这些工具绝大多数只有命令行版本。你能不能在测试前确认机器配置符合预期，能不能在测试中快速定位瓶颈，能不能在测试后收集完整的环境信息存档，全靠Linux基本功。 从这个角度看，Day1的"硬件查看"其实是在为后面几十天的性能测试打地基——配置信息都搞不准，后面测出来的数据没有任何说服力。

2. 环境准备与第一天必须练熟的基本功

磨刀不误砍柴工。开始敲命令之前，你得有一个能用的Linux环境，也得搞明白终端和远程连接的基本套路。这一段我按自己带人的习惯，把第一天最该练的东西过一次。

2.1 三种环境怎么选：物理机、虚拟机、云主机

学Linux基础，你至少得有一个可以随意折腾的环境。我的建议是分场景：

• 如果你手头有淘汰的旧服务器或高性能台式机，直接装一个Ubuntu Server或CentOS Stream，体验最接近真实服务器。
• 如果手头没有物理机，用VMware或VirtualBox装虚拟机完全够用，注意分配2核CPU、4GB以上内存就行。
• 如果你有云主机，也可以直接拿来练，好处是随时能开能删，坏处是云主机经过虚拟化，部分硬件信息（比如磁盘型号、PCI设备）看不全。

我个人倾向于让新人优先用虚拟机起步，零成本、随便折腾、不怕搞坏。等后面学到硬件测试，再去找物理机实操。Day1的内容在虚拟机里基本都能练。

2.2 SSH远程连接与终端操作习惯

服务器大多放在机房，你不可能天天蹲在机房动显示器，日常操作全走SSH。Windows下我常用的是系统自带的OpenSSH客户端，或者用FinalShell这类带文件管理的工具；Mac下直接用终端就行。连接命令是：

ssh 用户名@IP地址

这里提醒几个实际工作中天天踩的坑：

• 默认端口不是22的时候，要用ssh -p 端口号 用户名@IP地址指定。
• 第一次连接会提示确认主机指纹，输入yes回车就行。
• 如果连不上，先ping一下IP通不通，再检查目标机器的sshd服务是否启动，最后确认防火墙有没有放行端口。

进入系统后，第一件事是看一眼命令提示符。形如root@localhost:~#的提示符，root表示当前用户，localhost是主机名，~表示当前在用户家目录，最后的#表示你是root权限，普通用户则是$。这个细节很多人不注意，结果在root下敲了破坏性命令，后悔都来不及。

2.3 目录结构与文件操作：不用背，但要形成本能

Linux目录结构是服务器测试经常要打交道的东西。我不主张大家死记硬背，但以下几个目录必须形成条件反射：

• /proc：虚拟文件系统，内核和进程信息的窗口。CPU信息、内存信息、中断信息都在这里，后面查硬件很多命令其实就是在读这个目录下的文件。
• /sys：另一个虚拟文件系统，更多是设备、驱动、内核参数相关的接口。
• /dev：设备文件目录。/dev/sda、/dev/nvme0n1这些块设备节点都在这里。
• /var/log：日志目录。系统出问题，第一反应就是来看/var/log/messages或/var/log/syslog。
• /etc：配置文件集中地。网络配置、软件源、服务配置都在这里。

文件操作命令没那么玄乎，cd切换目录、ls列出文件、cp复制、mv移动、rm删除、cat查看内容、vim编辑文件。第一天不要求熟练，但要能看懂命令的含义。我的经验是，与其抄一堆命令列表，不如直接上手在系统里翻目录，比如用ls /proc看看里面有什么，再用cat /proc/version看看内核版本——这种"即时反馈"的学习效率比背命令高得多。

2.4 文本编辑：测试工程师至少要会一种编辑器

服务器测试中，改配置、写脚本、看日志都需要编辑文件。vi/vim是Linux发行版自带的，你躲不掉。第一天不用学花哨操作，只需要记住三个模式切换：默认是普通模式，按i进入编辑模式，编辑完按Esc回到普通模式，再输入:wq保存退出，输入:q!不保存退出。真的，刚开始用vim会觉得很蹩脚，但用一周就顺手了，因为所有服务器都有vim，你不可能到客户现场还装个别的编辑器。

3. 服务器硬件查看命令实战：CPU、内存、硬盘、RAID、网卡逐个过

现在到了Day1的重头戏。我按硬件类别拆开讲，每类都给出最常用的命令、关键字段解读、和实际测试场景中的使用心得。以下命令默认在root权限下执行。

3.1 CPU信息：lscpu为主，dmidecode为辅

查看CPU信息，lscpu是使用频率最高的命令，因为它把CPU的架构、型号、核数、线程数、缓存都汇总得明明白白：

lscpu

输出里的关键字段要会看：

• Architecture，架构类型，服务器上最常见的是x86_64，ARM服务器会显示aarch64。
• CPU(s)，逻辑CPU总数。注意，这里包含超线程后的逻辑核数。
• On-line CPU(s) list，在线运行的CPU列表，如果某些核被隔离或下线，这里会体现。
• Thread(s) per core，每核心的线程数，通常为2说明开了超线程。
• Core(s) per socket，每颗物理CPU的核心数。
• Socket(s)，服务器插了几颗物理CPU。
• Model name，CPU型号，比如Intel Xeon Gold 6330或者AMD EPYC 7742。
• CPU MHz，当前频率，实际会随负载动态变化。
• NUMA node(s)，NUMA节点数，多路服务器尤其要关注，后面性能测试里NUMA的影响非常大。

只看逻辑核数不够，很多时候我们要确认物理CPU的详细信息，比如步进版本、最大功耗。这时用：

dmidecode -t processor

这个命令会输出每一颗物理CPU的详细信息，包括制造商、型号、ID、步进、核心数量、线程数量、最大速度、缓存大小，甚至处理器版本字符串。做测试的时候，登记的CPU信息以这个输出为准，因为lscpu在某些虚拟化环境下可能只显示虚拟CPU的信息。

还要补充一个所有测试工程师都会用的东西：/proc/cpuinfo。它逐个逻辑CPU展示信息，做CPU亲和性绑定、确认每颗物理CPU对应哪些逻辑CPU时非常有用。

3.2 内存信息：free看状态，dmidecode看配置

内存查看分两个层面：一是系统当前可用多少内存，二是物理上插了几根什么规格的内存条。

当前内存使用状态，用free -h：

free -h

输出里有total、used、free、shared、buff/cache、available这几列。最容易让人困惑的是free和available的区别：free是真正没被用的内存，available是估算的"还可以分配给新进程的内存"，因为buff/cache在需要时可以回收。所以判断系统内存是否紧张，主要看available，不是看free。做服务器测试时，跑内存带宽测试之前，一定要先确认free内存充足，不然测试进程可能被系统OOM杀死。

物理内存条配置信息，用：

dmidecode -t memory

这个命令输出很长，但关键的几个点一定要会抓：

• Number Of Devices：主板上内存槽位总数。
• Locator：内存插槽位置，比如CPU0_DIMM1，方便你定位到具体是哪根槽。
• Size：单根内存容量，如果显示No Module Installed，说明这个槽位是空的。
• Type：内存类型，DDR4、DDR5之类。
• Speed：额定速率，比如3200 MT/s。
• Configured Memory Speed：实际运行速率。如果这条低于额定速率，说明可能没跑在最高档。
• Manufacturer 和 Part Number：内存颗粒厂商和型号，做兼容性测试时必看。
• Rank：单面还是双面，对某些测试场景有影响。

实际工作中，内存配置核对的标准动作是：先看free -h确认系统识别总量，再看dmidecode -t memory逐槽确认物理配置，两者一对比，就能发现有没有内存条没被识别、有没有频率降档之类的问题。

3.3 硬盘与块设备：lsblk、fdisk、smartctl、df组合

硬盘这块是服务器测试的重头戏，也是新人最容易搞混的地方。第一步是看清系统里有几块盘、什么类型、什么拓扑：

lsblk

这命令以树状结构显示所有块设备。输出里NAME是设备名，sda、sdb这类是SATA/SAS盘，nvme0n1这类是NVMe SSD；SIZE是容量；TYPE是设备类型，disk表示物理盘，part表示分区；MOUNTPOINT是挂载点。lsblk还支持lsblk -d -o name,model,serial直接查看磁盘型号和序列号——这个在核对送测硬件时特别有用。

想看得更详细，用fdisk：

fdisk -l

它会列出所有磁盘及其分区表信息。注意，不带-l直接运行fdisk会进入交互式操作界面，新手误操作可能把分区表弄坏，所以只学习阶段务必加-l。

磁盘健康状态和详细信息，用smartctl。这个命令需要smartmontools包支持：

smartctl -i /dev/sda

-i显示设备信息（型号、序列号、固件版本、接口类型），-a显示完整SMART健康数据。做硬盘测试前后各跑一次，对比关键属性值的变化，是非常重要的标准动作。

磁盘空间使用情况，用df：

df -h

-h表示以人类可读方式显示容量。这个命令主要看文件系统空间，不是直接看物理盘。测试过程中数据写满了、日志把根分区塞爆，都靠它发现。

3.4 RAID卡与阵列信息：常用的工具命令

服务器配RAID卡时，系统层面看到的是虚拟磁盘，而不是物理硬盘，所以查RAID信息必须用阵列卡厂商的工具。这里区分两条主流路线：

• 博通/LSI芯片的RAID卡，对应工具是MegaCli或新的storcli。
• 国产服务器常配的某系列SAS卡，对应工具是sas3ircu。

阵列信息查看的典型命令是（示例性写法，不同工具版本略有差异）：

storcli /c0 show

这条命令会显示控制器信息、RAID级别、虚拟磁盘状态。查看物理磁盘状态可以用：

storcli /c0/e0/s0 show all

它显示的是某个物理盘的全部信息，包括SMART状态、温度和错误计数。判断RAID健康状态的核心几个点：虚拟磁盘的状态是不是Optimal、物理盘的SMART状态是否正常、有没有盘处于Rebuild或Degraded状态。

这里必须提醒一点：查RAID信息之前，先确认服务器装没装对应管理工具。很多新到的服务器默认没装。没有工具的时候，临时办法是看系统日志里的RAID相关报错，但要拿到完整配置还是得装官方工具。我自己的习惯是把常用RAID工具都提前准备好，放到一个固定目录，省得到现场抓瞎。

3.5 网卡与网络信息：lspci先认设备，ethtool再看速率

服务器上的网卡可能是板载的，也可能是PCIe插槽上的独立网卡。第一步先用lspci确认网卡型号：

lspci | grep -i ethernet

或者更宽泛一点看网络设备：

lspci | grep -i network

这会列出网卡的PCI地址、厂商、型号。比如某服务器输出里有一行Ethernet controller: Intel Corporation Ethernet Controller 10G X550T，说明板载万兆电口网卡用的是Intel X550芯片。

确认系统识别到的网络接口名称，用：

ip link

或者传统一点的ifconfig -a。注意，服务器网卡数量多时，接口名和物理位置的对应关系要格外小心。我在测试中就遇到过配置错网口的情况——ip link看到的eth0实际是板载管理口，而业务口是eth2，搞错之后业务全断。

查看网卡协商速率、双工模式、驱动信息，用ethtool：

ethtool eth0

输出中Speed字段显示协商速率，比如10000Mb/s表示万兆；Duplex显示Full全双工。还有个非常有用的参数：

ethtool -i eth0

它显示driver、firmware-version等驱动信息。排查网卡丢包、速率不达标问题的时候，这些信息是判断依据。

3.6 整机与系统信息：uname、dmidecode -t system、uptime

整机信息查看，很多时候决定了测试报告的"环境描述"章节写什么。

系统版本和内核：

uname -a cat /etc/os-release

第一行看内核版本、主机名、架构，第二行看发行版名称和版本号。测试报告里必须记录这两项，因为内核版本不同，性能表现会有差异。

整机型号、序列号、BIOS版本，用：

dmidecode -t system dmidecode -t bios

第一组命令输出制造商、产品名称、序列号；第二组输出BIOS厂商和版本。做测试前的硬件信息登记，这两条命令是最快的方式。

系统运行时间和负载，用：

uptime

它显示当前时间、已运行时间、登录用户数、1/5/15分钟平均负载。负载这个指标要结合CPU核数看，不是越低越好也不是越高越糟，而是看相对值。比如16核的机器，负载15说明CPU基本满了，但4核机器负载15就是严重过载。服务器测试开始前，先看uptime确认系统是干净启动的，避免上一轮测试残留进程影响结果。

4. 把命令串起来：搭建你自己的环境巡检与基线快照

单个命令谁都会敲，难的是把命令组织成一套能重复执行、方便对比的操作方法。搞测试的都知道，测试结论要能复现，环境信息必须前后一致。所以我建议Day1就养成一个习惯：做任何测试前，先采集一次环境基线快照。

4.1 为什么需要"基线快照"而非手抄配置

手动拷贝lscpu输出贴到文档里，这事我也干过，但效率太低还容易漏。更关键的是，测试过程中硬件状态可能发生变化——内存使用率涨了、磁盘SMART属性变了、网卡协商速率掉档了。如果没有基线，后面出了问题你根本不知道"是什么时候变的、从什么值开始变的"。基线快照就是把初始状态完整记录下来，作为后续对比的参考系。

就拿磁盘来说，SMART属性里有一个项叫通电时间，测试前后通电时间本来就该增加，但如果你没记基线，就无法确认测试期间盘有没有意外断电。再比如内存，测试前记录total和available，测试后对比available，就能判断内存泄漏是否存在。这些对比都依赖基线。

4.2 一个可落地的巡检脚本思路

脚本不需要一上来就写得很复杂，核心是把前面讲的命令输出重定向到文件里。我提供一个思路框架，你完全可以在此基础上扩展：

#!/bin/bash # 环境基线快照脚本思路示例 BASE_DIR=/root/env_baseline mkdir -p ${BASE_DIR} # 系统基本信息 uname -a > ${BASE_DIR}/uname.txt cat /etc/os-release > ${BASE_DIR}/os_release.txt uptime > ${BASE_DIR}/uptime.txt date > ${BASE_DIR}/datetime.txt # CPU lscpu > ${BASE_DIR}/lscpu.txt dmidecode -t processor > ${BASE_DIR}/dmidecode_processor.txt # 内存 free -h > ${BASE_DIR}/free_h.txt dmidecode -t memory > ${BASE_DIR}/dmidecode_memory.txt # 块设备与磁盘 lsblk > ${BASE_DIR}/lsblk.txt fdisk -l > ${BASE_DIR}/fdisk_l.txt df -h > ${BASE_DIR}/df_h.txt # 网络 ip link > ${BASE_DIR}/ip_link.txt lspci | grep -i ethernet > ${BASE_DIR}/pci_ethernet.txt # PCI设备全量 lspci > ${BASE_DIR}/lspci.txt

思路就是一条命令对应一个文件，统一放在带日期的目录下。后续做第二轮测试前再跑一次，用diff对比前后差异：

diff /root/env_baseline/lscpu.txt /root/env_baseline_20250106/lscpu.txt

有差异的地方，就是要重点排查的地方。

4.3 从信息采集到测试报告的环境章节

测试报告里的"测试环境"部分，直接把这些文件内容整理成表格即可。CPU型号、核数、内存容量与频率、硬盘型号与固件、RAID级别、网卡型号与速率、操作系统版本、内核版本、BIOS版本，这些都是评审人员最关心的信息。你提前养成了采集习惯，写报告时就不会缺胳膊少腿，也不会出现"环境信息不详"这种让报告掉价的话。

5. 新手Day1最容易踩的坑，我替你提前踩过

最后这部分全文背诵。以下每一条都是我实际带人时见过的问题，也是自己刚入行时犯过的错。写出来，是希望大家别在同一堆坑里反复打滚。

5.1 dmidecode输出的信息不一定百分之百可信

服务器厂商的固件实现质量参差不齐，尤其是一些白牌或定制机器，dmidecode输出的内存频率、CPU最大速度有可能不准。我遇到过一台机器，dmidecode显示内存支持3200MT/s，实际跑在2666MT/s，但Configured Memory Speed显示的又是3200，最后用内存带宽测试工具实测才发现频率根本没跑满。所以我的习惯是：dmidecode信息作为参考，运行时的真实状态以系统实际识别和实测结果为准。

5.2 别在root下乱敲rm和fdisk

这个强调多少次都不为过。rm -rf /这类事故网上案例一堆，fdisk误操作把整块盘分区表清空的也有。刚入门的新人，建议使用普通用户登录，需要root权限时再用sudo提权。测试机虽然可以重装，但数据丢了影响进度，得不偿失。

5.3 注意区分逻辑CPU、物理核心和NUMA节点

举个例子，一台2路服务器，每颗CPU是32核64线程，那么逻辑CPU总数是128（2×64），物理核心总数是64（2×32），Socket数是2。后面做性能测试时，绑定核心数、设置并发数都必须清楚自己用的是哪个口径。如果只说"128核"，没人知道你指的是逻辑核还是物理核。跑fio或sysbench的时候，并发线程数设置通常参考逻辑CPU数量，但判断CPU算力规格时看物理核心更合理。NUMA节点的影响也很大：跨NUMA访问内存在某些负载下性能损失可达20%以上，所以性能测试工具通常都提供NUMA绑定的参数。

5.4 iostat的%util高并不一定代表磁盘饱和

这里提前剧透一个后面会细讲的知识点。很多人看到iostat里磁盘%util到100%，就断定磁盘成瓶颈了。但在NVMe SSD上，%util的计算方式容易造成误导，高%util不一定等于高吞吐，还要结合IOPS、吞吐量、平均延迟一起看。测试结论不能只看单一指标，Day1先记住这个原则。

5.5 先确认内核版本和驱动，再谈性能数据

不同内核版本对同一款网卡、同一款RAID卡的驱动支持力度不同，性能差异可能很大。测试中遇到数据异常，不要急着怀疑硬件，先检查驱动版本和固件版本是否为厂商推荐版本。我之前遇到过一次网卡吞吐上不去，折腾了半天，最后发现是内核自带的驱动版本太旧，换了厂商提供的新驱动立刻恢复。这个排查思路，从一开始看硬件信息的时候就要植入脑子。

写在第一天结束的话

Day1的内容就到这里。你在终端里敲一遍这些命令，大概一小时就能完成；但如果只是看文章不动手，明天就会忘掉一大半。我的建议是，现在就打开终端，登录你的Linux环境，把lscpu、free -h、dmidecode、lsblk、lspci这几条命令全部执行一遍，然后把输出内容和本文的字段解读对着看一遍。遇到看不懂的输出，就用man 命令名查帮助，或者去查命令的详细说明文档——这个查文档的习惯，比记住任何具体命令都重要。

服务器测试这条路，头一个月是最劝退的阶段，因为要补的东西太多：Linux要熟，硬件要懂，测试工具要会，性能数据要会分析。但这些东西不是孤立的，而是环环相扣的。Day1的硬件查看是地基中的地基，你花在这一小时上的时间，后面会在几十天的测试任务里成倍地省回来。明天Day2，我会带大家深入CPU性能和内存带宽的测试方法，到那时你会发现，今天记下的CPU型号、内存频率、NUMA拓扑，全都会派上用场。