香香甜甜圈接手一台陌生的Linux服务器，第一件事往往不是急着部署服务，而是先搞清楚这台机器“到底什么配置、什么系统、什么状态”。这组查看系统与硬件信息的常用命令，是所有Linux运维基本功里最容易被轻视、又最离不开的一块。无论是判断CPU核数够不够、内存是否吃紧、磁盘快满时该清哪里，还是排查系统突然变慢的原因，最终都要落到这些命令上。这篇文章就把我日常用得最频繁的信息查看命令整理一遍，从输出含义到背后原理，再到实际排错场景，尽量写得能直接照着用。
我自己刚入行时也吃过不少亏，比如刚拿到一台物理机用 nproc 看了个“6”，以为只有6个核，后来一查才发现是12线程的CPU；又比如 free 显示内存 used 很高，差点直接加内存，结果其实是文件缓存占着没释放。这些坑踩过之后才明白，查信息不只是敲几行命令，关键得看懂输出到底在说什么。
1. 先理清思路：为什么“查看系统信息”值得单独写一篇
很多新手觉得，查系统信息不就是 uname -a、free -h、df -h 这几条命令吗？其实这组命令分布在系统不同的信息源上，面对不同问题要组合使用。理解它们的逻辑，比死记命令本身更重要。
1.1 这组命令解决的三个核心场景
第一个场景是环境摸底。新接手一台服务器，或者从同事手里交接一个系统，第一步一定是确认操作系统发行版、内核版本、CPU 架构、内存大小、磁盘分区。部署软件前不看这些，后面大概率会踩到兼容性的坑：比如在 CentOS 6 上装了个需要 glibc 2.17 以上的软件，折腾半天才发现系统根本满足不了。
第二个场景是故障定位。系统卡了、服务挂了、内存爆了，这类问题没有固定的排查命令，而是沿着“系统资源 → 进程 → 日志”这条线逐步缩小范围。此时 top、free、df、dmesg 就是最顺手的工具，通过它们先回答“是不是资源不够”这个问题。
第三个场景是性能基线记录。上线前把关键指标记录下来，比如空闲时内存占用、CPU 负载、磁盘 IO 延迟，后续系统变慢时才有对比参照。没有基线，性能问题排查就像没有地图找路。
1.2 所有命令的背后：信息究竟从哪里来
Linux 下查看系统信息，底层数据来源无非就几个地方：/proc 虚拟文件系统、/sys 设备文件系统，以及内核直接提供的系统调用。/proc/cpuinfo、/proc/meminfo、/proc/diskstats 这些文件，都是内核实时动态生成的，不是磁盘上的真实文件。
很多命令本质上是这些文件的“格式化展示工具”。比如 lscpu 会读取 /proc/cpuinfo 和 /sys/devices/system/cpu/ 下的内容；free 的数据来自 /proc/meminfo；df 则会轮询各个挂载点。明白这层关系，就懂了为什么有时直接 cat /proc/cpuinfo 会比 lscpu 看到更多原始字段，也理解了为什么某些命令需要 root 权限——因为它们除了读文件，还要访问硬件寄存器或者需要 CAP_SYS_ADMIN 等内核权限，比如 dmidecode 读取 SMBIOS 信息时就需要提权。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统整体信息：发行版、内核、主机名与运行时间
先看系统层面的基本信息。这类命令是日常用得最多、输出也最容易读懂的。
2.1 系统发行版与内核版本
第一件事永远是确认系统是什么发行版、什么版本。现在很多服务器是 CentOS、Ubuntu、Debian，国内还有不少基于 openEuler、统信 UOS 的场景。不同发行版的包管理方式不一样，排查问题时的思路也有差异。
bash复制# 查看内核版本
uname -a
# 或者只看内核版本
uname -r
# 查看发行版信息（现代系统通用）
cat /etc/os-release
uname -a 的输出里，内核版本号和硬件架构是重点。比如 Linux host01 5.14.0-284.11.1.el9_2.x86_64，其中 5.14.0 是内核主版本，el9_2 说明是 RHEL 9.2 衍生系统，x86_64 是架构。判断软件安装包选 x86_64 还是 aarch64，靠的就是这段信息。
/etc/os-release 是 systemd 时代的标准文件，字段很规范。比如 NAME="Ubuntu"、VERSION_ID="22.04"、ID=ubuntu，脚本里写判断时就可以直接 source /etc/os-release 然后用 $ID、$VERSION_ID 做判断。早期的 CentOS 6 上这个文件还不存在，只能看 /etc/redhat-release，接手老系统时这两个地方都得会看。
2.2 主机名与运行时长
主机名和服务器身份有关，云服务器、物理机都会用到。
bash复制hostname # 查看主机名
hostnamectl # 查看主机名及系统详细信息
hostnamectl set-hostname web-server-01 # 修改主机名
hostnamectl 输出里还包含操作系统、内核版本、虚拟化类型等，这是我平时交接服务器时最爱看的命令，一条就能把系统基础信息扫完。改主机名时要注意，/etc/hosts 里也要同步修改，不然部分服务解析本机名会出问题。
运行时长和负载信息主要靠 uptime：
bash复制uptime
# 输出示例： 10:23:45 up 120 days, 4:20, 2 users, load average: 0.15, 0.20, 0.18
中间那段 up 120 days 代表系统已连续运行120天。负载的三个数字分别表示过去 1 分钟、5 分钟、15 分钟的平均负载。负载值只有结合 CPU 核数才有意义：单核 CPU 负载 1.0 算满，而 16 核 CPU 负载 1.0 说明非常闲。判断系统是否繁忙，不能只看负载绝对值，要看它相对于核数是否持续偏高。
想知道系统历史上什么时候重启过，可以看 who -b 或 last reboot：
bash复制who -b # 显示上次系统启动时间
last reboot # 查看历史重启记录
排查“为什么服务器又重启了”这种问题时，last reboot 能直接列出重启时间点，再配合 /var/log/messages 或 journalctl 看重启前的日志，能快速判断是人为重启、内核 panic 还是断电导致。
3. CPU 信息：看懂逻辑核、物理核与使用率
CPU 相关的信息查看，最大的坑在于“线程不代表核心”。下面这些知识点在采购机器、排查性能问题时都是高频考点。
3.1 lscpu 输出详解
bash复制lscpu
lscpu 输出了一整个 CPU 信息面板，其中几个字段最需要关注：
| 字段 | 含义 | 说明 |
|---|---|---|
| Architecture | CPU 架构 | x86_64 还是 aarch64 |
| CPU(s) | 逻辑 CPU 数量 | 包括超线程 |
| On-line CPU(s) list | 在线 CPU 编号 | 有些核可能被隔离或下线 |
| Thread(s) per core | 每核心线程数 | 2 代表开了超线程 |
| Core(s) per socket | 每颗 CPU 物理核数 | 物理核心数量 |
| Socket(s) | CPU 颗数 | 物理 CPU 数量 |
| NUMA node(s) | NUMA 节点数 | 多路服务器常见 |
| Model name | CPU 型号 | 如 Intel Xeon Gold 6330 |
有个常用公式：CPU(s) = Socket(s) * Core(s) per socket * Thread(s) per core。比如一台服务器的 Core(s) per socket 是 8，Socket(s) 是 2，Thread(s) per core 是 2，那么逻辑 CPU 数就是 32。如果只看了 CPU(s) 那一行，就把 32 当物理核数，后续做性能评估会偏差很大。
3.2 手工查 /proc/cpuinfo 判断物理核心
没有 lscpu 的极简系统上，可以手工查看：
bash复制cat /proc/cpuinfo
输出里每个 processor 字段代表一个逻辑 CPU。判断物理核数的方法是统计 core id 和 physical id 的组合：
bash复制grep -E "physical id|core id" /proc/cpuinfo | sort -u
physical id 表示第几颗物理 CPU，core id 表示该 CPU 内的物理核心编号。两列组合去重后统计数量，就是物理核总数。这个脚本在脚本部署场景里比 lscpu 更通用，因为老内核老系统上不一定装 util-linux 的新版本。
另外 /proc/cpuinfo 中 processor 编号不连续是正常的。如果某个 CPU 在运行时被 echo 0 > /sys/devices/system/cpu/cpuX/online 下线，编号就会跳过去，不要以此判断硬件损坏。
3.3 实时 CPU 使用率怎么查
静态配置看 lscpu，实时负载就要靠下面几个命令：
bash复制top
htop # 新机器上可能没有，需要安装
mpstat -P ALL 1 3 # 每秒刷一次，显示所有核的使用率，共显示3次
top 默认显示的是所有 CPU 的汇总值，按数字键 1 可以展开每个逻辑核的使用率。排查多线程程序负载不均时，这个展开视图特别有用——总 CPU 不高但某个核 100%，说明程序没有充分利用多核。
mpstat 来自 sysstat 包，更偏脚本化和定时采集。其中 %usr、%sys、%iowait、%idle 几列能区分用户态、内核态和 IO 等待。判断 CPU 是不是拖慢了服务，关键是看 %iowait 高不高——如果 CPU 大量时间在等磁盘 IO，加 CPU 核数是没用的，瓶颈在存储而不是计算。
4. 内存信息：free 输出背后的小知识
内存是最容易误读的资源指标。free -h 的输出看起来简单，但很多人都会看错。
4.1 free 命令字段逐列拆解
先看典型输出：
bash复制free -h
text复制 total used free shared buff/cache available
Mem: 62G 5.1G 47G 110M 9.8G 56G
Swap: 8G 0B 8G
total 是物理内存总量，不是所有都能用，内核和硬件会保留一部分。used 是已被进程占用的内存。free 是完全没有被使用的内存。但要注意 used + free + buff/cache 才等于 total 的近似值——因为 Linux 会尽量把空闲内存用作文件缓存，所以上面这个例子里 free 看着是 47G，其实 buff/cache 里还有 9.8G 可以被回收。
最需要关注的是最后一列 available，它表示“在不触发大量交换的情况下，还能分配给新进程的内存估算值”。有些系统为了优化读写性能，会一直维持较高的 buff/cache，此时看 free 这一列会觉得内存吃紧，但实际 available 还有一大半。
作为参考经验：判断内存是否紧张，优先看 available 是否持续接近 0，而不是看 used 占比。buff/cache 内存不是“泄漏”，它是页缓存（page cache）和块缓存，需要时内核会回收优先级较低的缓存。如果 available 持续很低且 swap 使用量上涨，才是真正的内存压力。
4.2 深入 /proc/meminfo 和 vmstat
free 的数据来源是 /proc/meminfo，想拿到更详细的内存分类信息，直接看它：
bash复制cat /proc/meminfo | head -30
其中 MemTotal、MemFree、MemAvailable 几个字段含义和 free 汇总一致。另外 Slab 是内核数据结构占用的内存，SReclaimable 是可以回收的部分。排查“内核内存泄漏”类问题，通常要观察 Slab 是否持续增长不回落。
动态观察内存变化，用 vmstat：
bash复制vmstat 1 5
输出里 si（swap in）和 so（swap out）两列值得特别注意。如果这两列持续非零，说明物理内存已经不够用，系统正在内存和交换分区之间来回搬数据，此时服务响应会明显变慢。这种现象俗称“抖动”，出现时优先考虑增加物理内存、减少单机服务数量，或者检查是否有进程故意申请大量内存。
内存模块的硬件信息用 dmidecode 查看：
bash复制dmidecode -t memory | grep -E "Size|Type|Speed|Locator" | head -40
加内存条之前，先看现有内存条类型是 DDR4 还是 DDR5、频率多少、插在哪个槽位、有几个空槽，避免买错内存。dmidecode 需要 root 权限，而且有些虚拟机上看到的型号信息是虚拟化层模拟的，物理机上则能看清品牌和序列号。
5. 磁盘、网络与硬件设备信息
系统跑得慢、空间不够、网卡速率不对，这些问题的排查都依赖磁盘和硬件信息。这节把磁盘容量、分区结构、文件系统类型、网卡状态和常见硬件识别命令串一遍。
5.1 磁盘容量与文件系统使用率
磁盘信息最经典的组合命令就是 df 和 du：
bash复制df -hT
df -i
df -hT 中的 -h 是人性化单位显示，-T 是显示文件系统类型。输出里的 /dev/sda1 ext4 表示根分区用的是 ext4，后面 Use% 是分区使用率。df -i 则显示 inode 使用率——inode 用满的情况在文件数量极多的小文件场景下很常见，此时 df -h 看着还有空间，但文件已经创建不出来了，这也是新手最容易忽略的坑。
du 用于统计目录占用的实际大小。最常见用法是排查磁盘空间被谁占满：
bash复制du -h --max-depth=1 /home
du -sh /* 2>/dev/null
du -sh /* 会统计根目录下每个一级目录的总大小，是最快的排障入口。统计一个目录下哪些子目录最占空间用 du -h --max-depth=1 再 sort 一下，就能定位到具体目录。
这里有一个经典问题：df 显示磁盘已满，但 du 把所有文件加起来却没有那么大。最常见的原因是某个进程把一个大文件删除后仍然保持文件句柄，导致空间没有真正释放。排查命令是：
bash复制lsof | grep deleted
输出里如果有 (deleted) 标记的文件句柄，那就是占用空间的元凶。处理时可以确认进程后重启该服务，空间就会立刻释放。这条经验在日志文件被 rm 之后服务还在写的老场景里特别常见，写脚本轮转日志时也要记得用 > log 而非 rm 后重建，否则句柄悬空，日志空间会持续被占用。
5.2 块设备与分区信息
查询磁盘本身的结构，用 lsblk：
bash复制lsblk
lsblk -f
lsblk 输出是一棵倒挂的树，sda 作为整块磁盘，下面是 sda1、sda2 这些分区，上面是挂载点。lsblk -f 会多显示文件系统类型和 UUID，这比 fdisk 直观很多。
需要查看是否存在未分区未使用的“裸盘”，lsblk 有最好的全局视角。比如新增了一块 2T 数据盘但看了半天找不到，输入 lsblk 就会发现一个没有子分区的 sdb，这样就是要手动分区或做 LVM、RAID 的后续操作。
分区级操作常规用 fdisk -l，但只能 root 查看。UUID 和文件系统类型可以用 blkid：
bash复制blkid
blkid 输出每个分区的 UUID、文件系统类型，写 /etc/fstab 时最有用。初始化新数据盘时，先用 lsblk 确认设备名，再 mkfs.xfs /dev/sdb1 或 mkfs.ext4，随后 blkid 查到 UUID 写入 fstab，最后 mount -a 验证挂载。这套流程里的每一步几乎都能靠前面的查询命令确认前置状态。
5.3 网络与 PCI/USB 设备信息
网络信息涉及的面很广，这里只挑最常用的几个查看命令：
bash复制ip addr # 查看 IP 地址
ip link # 查看所有网卡状态
ethtool eth0 # 查看 eth0 的速率、双工模式、链路状态
ip addr 里重点关注 state UP 的接口以及 inet 行的 IP 地址。ethtool 查看的是协商速率和链接状态，排查“网卡明明插着线却不通”这类问题时，如果 ethtool eth0 里 Link detected: no，说明物理链路没通，问题在网线、交换机端口或对端设备，而不是系统配置。
硬件层面的总览命令：
bash复制lspci -tv # 以树状查看 PCI 设备，网卡、显卡、RAID 卡都在这里面
lsusb # 查看 USB 设备
dmidecode -t system # 查看整机厂商、序列号、BIOS 版本
服务器加装显卡、网卡时，lspci 可以快速确认硬件是否被系统识别。常见的 NVIDIA 显卡在 lspci | grep -i nvidia 下能看到型号和厂商信息。如果插了新卡但 lspci 里看不到，通常是设备未被 PCI 枚举识别，需要重新插拔或升级 BIOS；如果是新硬件在旧系统下显示 unknown，可以先执行 update-pciids 更新 PCI ID 数据库，再查一次。
dmidecode 还有一个很实用的用途：远程接手物理机时，通过 dmidecode -t system 查出厂序列号，配合厂商的保修查询页面，可以直接定位设备的保修期和配置批号，这在资产盘点时能省不少事。
6. 常见问题与排查技巧实录
很多人查系统信息时，对命令本身不那么容易出问题，真正出问题的是看懂输出和判断下一步。这一节把这些年在实际环境中踩过的几个坑和对应的排查思路整理出来，做成清单，方便对照。
6.1 CPU 使用率显示超过 100%，是坏了吗
top 里某个进程 CPU 占用 120%、300%，不是系统显示错误。Linux 的 CPU 占用率是按逻辑 CPU 核数计算的，单核满载是 100%，多线程进程可以同时占用多个核，所以理论上限是 核数 * 100%。看到 300% 的占用，说明这个进程用了大约 3 个完整逻辑核，在 8 核机器上仍在健康范围内，但如果 32 核的机器上一个进程占满 3000%，那就确实有问题了。
补充一点：top 默认的 %CPU 是累计值，刷新间隔越大，数值可能越不能反映瞬时状态。要看瞬时占用，按 1 展开看各核状态，或者用 top -p <pid> 加 -d 1 把刷新间隔设为 1 秒。
6.2 free 显示 used 很高，但却找不到占内存的进程
这个问题几乎每个运维都遇到过。系统内存 used 占了 90% 以上，top 按内存排序找半天却没发现哪个进程特别大。这时不要急着加内存，先分清 used 里有多少是 buff/cache。
bash复制free -h
如果 buff/cache 一列明显偏高，说明是文件缓存导致，不是进程在“吃内存”。Linux 的设计就是用空闲内存做缓存来提升性能，available 才是新进程真实可用的内存。只有 available 持续很低，且用 vmstat 看到 si/so 频繁换页，才是真正意义上的内存不足。
6.3 磁盘没写文件，空间却越来越少
遇到过一个案例：一台机器每天都产生大量监控日志，日志轮转脚本把 *.log.2025010* 这类文件删了，但磁盘空间还是持续下降。最后定位发现，服务进程一直持有已删除文件句柄，日志实际还在“被写入”已经删除的文件中，空间无法释放。
排查这类问题统一走三步：df -h 确认使用率，du -h --max-depth=1 从根目录逐层往下找大目录，再 lsof | grep deleted 找占用文件句柄的进程。确认是哪个进程后，优雅重启该服务即可释放空间。现在写日志轮转我都会用 logrotate 默认配置里的 copytruncate 而不是简单 rm，避免句柄悬空。
6.4 速查表：从现象到命令
| 现象 | 可能原因 | 优先排查命令 |
|---|---|---|
| 系统卡顿，负载高 | CPU 或 IO 瓶颈 | top、mpstat、iostat |
| 内存不足/OOM | 内存泄漏或配置不足 | free -h、vmstat 1、dmesg |
| 磁盘空间满 | 大文件或删除未释放 | df -h、du -sh /*、lsof | grep deleted |
| inode 耗尽 | 小文件过多 | df -i、find / -type f | wc -l |
| 网卡不通 | 链路或配置问题 | ip link、ethtool eth0、ping |
| 新加硬件不识别 | 接触不良或驱动问题 | lspci -tv、lsusb、dmesg |
| 重启原因不明 | 人为、断电或内核问题 | last reboot、journalctl -b -1 |
这张表是单机排障时的最快入口。先把“资源层面”的问题排除掉，再往系统日志、应用日志深入，通常能找到根因。
6.5 一个模拟排查过程
举个实际例子。某天服务响应变慢，告警显示机器负载升高。登录后的排查顺序大概是：
bash复制uptime
# 显示 load average: 8.50, 6.20, 3.10，而机器只有 4 核，负载明显偏高且持续上涨
负载和核数一对比，基本确定系统过载，但不知道是 CPU 计算密集还是 IO 等待。继续看：
bash复制top
发现某个 java 进程 CPU 300%，同时 %iowait 很高。再查内存：
bash复制free -h
内存不够导致开始使用 swap，进程频繁换页，所以既消耗 CPU 又表现出 IO 等待。最后看系统日志确认：
bash复制dmesg -T | grep -i -E "oom|killed"
journalctl -k | grep -i oom
如果看到 OOM killer 杀过进程的记录，问题基本就清楚了：内存不足引发连锁反应。这时候先停掉部分非核心服务或扩大内存，然后从该进程入手查内存泄漏。整个排查过程十来分钟，靠的全是上面这些基础命令，不需要额外安装任何高级工具。
最后再分享一个日常习惯：我会把每台服务器的基础配置和关键命令输出保存一份到本地笔记，包括 lscpu、free -h、df -hT、ip addr 的结果。别看这习惯简单，等哪天机器起不来、只能通过救援模式到另一台机器上分析时，手头有这份基线信息，做对比判断会从容很多。查系统信息这件事，真正值钱的不是记住多少命令，而是每条输出都能看懂背后的含义，知道下一步该往哪儿查。把这篇文章里的命令跑一遍，再对照输出说清楚每个数字是什么含义，这个基本功就算真正的过关了。