Linux新手入门

从零开始，循序渐进学习 Linux

AD
【阿里云限时福利】领大额优惠券，新人云主机99元/年起👈

2.3 系统信息与性能查看

✍️ 作者：IOHOW · 10+ 年运维实战 📅 最后更新：2025-03-01 📚 经验·专业·可信

预计阅读时间：18 分钟

📖 目录

学习目标

学完本章后，你将能够：

  • 使用 uname、hostnamectl 查看系统基本信息
  • 使用 free、df、du 查看内存和磁盘使用
  • 使用 uptime 和 top/htop 查看系统负载
  • 从 /proc/ 虚拟文件系统读取 CPU、内存、网络等信息
  • 理解 Load Average 的含义
  • 使用 vmstat、iostat 等工具进行性能初诊

核心知识

  • uname——Unix name，查看内核名称、主机名、内核版本、架构等系统基本信息
  • /proc/——进程文件系统（虚拟），以文件形式暴露内核和进程的运行状态数据
  • Load Average——系统负载的三个数值（1分钟/5分钟/15分钟），代表等待 CPU 调度的进程平均数
  • top / htop——实时进程监控和系统概览工具
  • free——查看内存使用情况（物理内存和 swap）
  • df / du——磁盘空间使用查看（df = 文件系统级别，du = 目录级别）
  • uptime——查看系统运行时间、登录用户数和负载均值
  • vmstat / iostat / mpstat——分别查看虚拟内存、磁盘 I/O、CPU 统计的性能工具

知识关联

原理讲解

📝 为什么 Linux 把内核状态暴露为文件？

/proc 和 /sys 是 Linux"一切皆文件"哲学的极致体现。内核把 CPU 信息放在 /proc/cpuinfo、内存信息放在 /proc/meminfo、设备信息放在 /sys/class/——每个数据都对应一个"文件"。这样设计的好处：用户空间工具无需特殊 API，cat /proc/cpuinfo 就能读取 CPU 信息，和读取普通文件完全一样。内核不需要为每种信息编写专门的系统调用，而是通过虚拟文件系统（VFS）让所有数据对用户空间透明。这也是为什么这些"文件"大小显示为 0——它们不占磁盘空间，而是内核在被读取时动态生成内容。

📝 CFS 调度器如何工作？

Linux 默认的 CFS（Completely Fair Scheduler，完全公平调度器）的设计目标是"让每个进程公平地分享 CPU"。它不按优先级"排队"，而是为每个进程维护一个 vruntime（虚拟运行时间）：① 每次时钟中断（通常 1ms-10ms），CFS 给当前运行进程的 vruntime 加上一个与 nice 值相关的增量；② 调度时永远选择 vruntime 最小的进程运行；③ nice 值越高（优先级越低），vruntime 增长越快——所以高 nice 值的进程"攒"的 vruntime 更多，被调度的机会更少。这种设计让低优先级进程不会完全饿死（永远有 vruntime 最小的时候），同时保证高优先级进程获得更多 CPU 时间。CFS 用红黑树（rbtree）组织进程队列，选择最小 vruntime 进程的时间复杂度是 O(1)——即使有数千个进程，调度开销也极低。

📝 内存分页机制是什么？

Linux 通过分页（Paging）机制管理内存：每个进程看到的是连续的虚拟地址空间（如 64 位系统有 128TB 的虚拟空间），但实际的物理内存被分成固定大小的"页"（通常 4KB）。内核维护一张页表（Page Table），将虚拟地址映射到物理地址。当进程访问一个虚拟地址时，CPU 的 MMU（内存管理单元）自动查表：如果映射存在（页在物理内存中），直接访问；如果映射不存在（页被换出到磁盘），触发缺页中断（Page Fault），内核从磁盘加载该页到物理内存，再继续执行。这就是 free 显示的 buff/cache 可以被回收的原因——内核可以随时丢弃缓存页，因为它们的内容可以从磁盘重新加载。

1. 系统基本信息——uname 和 /proc/version

# 系统基本信息
uname -a              # 所有信息（内核名、主机名、版本、架构）
# 输出: Linux ubuntu-pc 6.8.0-31-generic #31-Ubuntu SMP x86_64 GNU/Linux
uname -r              # 内核版本号（如 6.8.0-31-generic）
# 输出: 6.8.0-31-generic
uname -m              # 硬件架构（x86_64 / aarch64）
# 输出: x86_64
uname -n              # 主机名（同 hostname 命令）
# 输出: ubuntu-pc

# 内核版本号解读
# 6.8.0-31-generic
# ↑ ↑   ↑  ↑
# │ │   │  └── 发行版特定（Ubuntu 的内核补丁版本）
# │ │   └── 安全补丁级别
# │ └── 次版本号
# └── 主版本号

# 查看内核编译信息
cat /proc/version
# 输出: Linux version 6.8.0-31-generic (buildd@lcy02-amd64) ...
# 包含 GCC 版本、编译时间等

2. /proc——内核的"实时状态窗口"

/proc 是一个虚拟文件系统（存在于内存中，不在磁盘上）。内核以文件的形式在这里暴露内部数据。

# CPU 信息
cat /proc/cpuinfo | head -20    # 型号、核心数、缓存
# 输出: processor       : 0
# 输出: vendor_id       : GenuineIntel
# 输出: model name      : Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
cat /proc/cpuinfo | grep "model name" | uniq
# 输出: model name      : Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
cat /proc/cpuinfo | grep -c "processor"  # CPU 线程数（逻辑核心）
# 输出: 8

# 内存信息
cat /proc/meminfo | head -15    # 总内存、可用、缓存、Swap
# 输出: MemTotal:       16357840 kB
# 输出: MemAvailable:    8912340 kB
# 输出: SwapTotal:       2097148 kB

# 系统运行信息
cat /proc/loadavg               # 负载均值
# 输出: 0.50 0.75 1.20 1/456 12345
cat /proc/uptime                # 运行秒数
# 输出: 129600.34 98765.21
cat /proc/version               # 内核版本
# 输出: Linux version 6.8.0-31-generic (buildd@lcy02-amd64) ...

# 网络统计
cat /proc/net/dev               # 网络接口流量统计
# 输出: eth0: 123456 7890    0    0    0     0          0         0
cat /proc/net/tcp               # TCP 连接状态
# 输出: sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt

# 进程信息
ls /proc/1/                     # PID=1 的进程（systemd）的详细信息
# 输出: attr   cmdline  cwd  environ  exe  fd  maps  root  status
cat /proc/1/cmdline             # 启动命令
# 输出: /sbin/init splash
cat /proc/1/status              # 状态、内存、权限
# 输出: Name:   systemd
# 输出: State:  S (sleeping)
# 输出: Pid:    1

3. Load Average——系统负载到底是多少

Load Average 是 Linux 性能监控中最常用也最容易被误解的指标。

$ uptime
10:30:00 up 15 days, 2:31, 3 users, load average: 0.50, 0.75, 1.20
                                                       ↑     ↑     ↑
                                                       │     │     └── 15 分钟平均
                                                       │     └──────── 5 分钟平均
                                                       └──────────── 1 分钟平均

Load Average = 正在运行 + 等待运行的进程数。不是 CPU 使用率！

  • Load = 0.5 在单核 CPU 上：CPU 有 50% 的空闲时间
  • Load = 2.0 在单核 CPU 上：有 1 个进程在等待 CPU 时间
  • Load = 2.0 在 4 核 CPU 上：系统还有富余——每个核心平均 0.5

判断原则：

  • Load / CPU 核心数 < 0.7：正常
  • Load / CPU 核心数 0.7 ~ 1.0：需要注意
  • Load / CPU 核心数 > 1.0：系统过载，有进程在等待 CPU

但高负载不一定等于"出问题"——如果高负载是高 CPU 密集型任务造成的（如视频转码），那只是"正常工作"。如果高负载伴随着大量进程在 D 状态（不可中断睡眠），才说明磁盘 I/O 可能有问题。

4. free——内存使用情况

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi        4.2Gi       6.8Gi       0.2Gi       4.5Gi       8.7Gi
Swap:         2.0Gi        0.0Gi       2.0Gi

关键字段：

  • total：物理内存总量
  • used：被程序使用的内存
  • free：完全未使用的内存
  • buff/cache：Linux 用空闲内存做磁盘缓存（可以回收给程序用）
  • available：真正可用的内存（free + 部分可回收的 cache）。这是你判断内存是否够用的依据
📝 Linux 吃掉了我一半内存？ 不，Linux 的哲学是"空闲内存是浪费的内存"。内核会积极使用空闲内存做磁盘缓存（buff/cache）来加速文件操作。当程序需要更多内存时，可以立即回收这些缓存。所以 free 显示很小不要慌——看 available。

5. top——实时系统监控

# 启动 top
top

# top 界面解读
top - 10:30:00 up 15 days,  2:31,  3 users,  load average: 0.50, 0.75, 1.20
Tasks: 230 total,   1 running, 229 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  2.3 sy,  0.0 ni, 91.6 id,  0.5 wa,  0.0 hi,  0.3 si,  0.2 st
MiB Mem :  15688.4 total,   6845.6 free,   4452.3 used,   4390.5 buff/cache
MiB Swap:   2048.0 total,   2047.8 free,      0.2 used.   9023.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 alice     20   0  412456  52348  28456 S   5.0   0.3   0:15.23 gnome-shell
 5678 root      20   0  183240  10248   3456 S   2.0   0.1   0:05.12 systemd-journal

# top 交互快捷键（按后立即生效）：
# P = 按 CPU 使用排序        M = 按内存使用排序
# 1 = 展开/折叠每个 CPU 核   k = 杀死进程（输入 PID）
# q = 退出                  h = 帮助
# r = 调整进程优先级（renice）

6. CPU 状态解读——top 中的 %Cpu(s) 行

# %Cpu(s):  5.1 us,  2.3 sy,  0.0 ni, 91.6 id,  0.5 wa,  0.0 hi,  0.3 si,  0.2 st
#         │      │      │      │      │      │      │      │      └── 被虚拟机偷走的时间
#         │      │      │      │      │      │      │      └──────── 软中断
#         │      │      │      │      │      │      └─────────────── 硬中断
#         │      │      │      │      │      └────────────────────── wait I/O（等磁盘）
#         │      │      │      │      └───────────────────────────── idle（空闲）
#         │      │      │      └──────────────────────────────────── nice（低优先级）
#         │      │      └─────────────────────────────────────────── system（内核态）
#         │      └────────────────────────────────────────────────── user（用户态）
#         └───────────────────────────────────────────────────────── 总 CPU 占用

关键看 wa（I/O wait）：如果 wa > 10%，说明磁盘可能是性能瓶颈。看 id（Idle）：如果 id 经常为 0，CPU 是瓶颈。

7. 其他性能工具

# vmstat —— 虚拟内存统计（每 2 秒刷新一次）
vmstat 2
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  1  0      0 6845560 123450 4390500    0    0    12    34   56   89  5  2 93  0  0
# ↑  ↑                                              ↑    ↑
# │  └── 不可中断睡眠的进程（b > 0 可能 I/O 瓶颈）    │    └── context switch（上下文切换）
# └── 等待 CPU 的进程（r > CPU 核心数 → CPU 瓶颈）     └── interrupt（中断）

# iostat —— 磁盘 I/O 统计
iostat -x 2                      # 每 2 秒显示扩展统计
# %util ≥ 70% → 磁盘可能是瓶颈

# mpstat —— 每核 CPU 统计
mpstat -P ALL 2                  # 每 2 秒显示每核 CPU 使用
# 如果某个核接近 100% 而其他核很低 → 可能是单线程瓶颈

# sar —— 历史性能数据收集（需安装 sysstat）
sar -u                           # CPU 使用历史
# 输出: Linux 6.8.0-31-generic (ubuntu-pc) 07/30/2026 _x86_64_
# 输出: 10:00:01     CPU     %user     %nice   %system   %iowait    %steal     %idle
# 输出: 10:30:01     all      5.10      0.00      2.30      0.50      0.00     92.10
sar -r                           # 内存使用历史
# 输出: 10:00:01    kbmemfree   kbavail  kbmemused  %memused  kbbuffers  kbcached
# 输出: 10:30:01      6845560   9023456    4452300     28.40     123450   4390500
sar -b                           # 磁盘 I/O 历史
# 输出: 10:00:01       tps      rtps      wtps   bread/s   bwrtn/s
# 输出: 10:30:01     12.50      3.20      9.30    256.00    512.00

8. 网络状态查看——ss 和 /proc/net

系统性能排查的最后一大块是网络。本章前面的 /proc/net/dev 给了接口总流量，而 ss 命令可以查看每一个 TCP/UDP 连接的状态——配合 top 的 si（软中断）指标，能定位"网络是不是瓶颈"。

⚠️ 废弃命令提醒 netstat（来自 net-tools 包）已被标记为过时，推荐使用 ss（来自 iproute2 包）替代。两者功能类似，但 ss 速度更快、信息更全。同样，ifconfig 也已废弃，用 ip addr 替代。
# ss 基本用法（socket statistics，替代已废弃的 netstat）
ss -t                          # 所有 TCP 连接
ss -u                          # 所有 UDP 连接
ss -l                          # 只显示监听端口
ss -tulnp                      # 监听端口 + 进程（-p 需要 root 才能看进程名）
# 输出: State   Local Address:Port   Peer Address:Port  Process
# 输出: LISTEN  0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=789,fd=3))
# 输出: LISTEN  0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=890,fd=6))

# TCP 状态统计（看 TIME_WAIT 是否堆积）
ss -s
# 输出: TCP:   891 (estab 321, closed 455, orphaned 12, synrecv 0, timewait 234)

# 结合管道做分析：统计各种状态的连接数
ss -t state all | awk '{print $1}' | sort | uniq -c | sort -rn
# 输出:     455 TIME-WAIT
# 输出:     321 ESTAB
# 输出:     120 LISTEN
# TIME-WAIT 大量堆积 → 配合 ch11 的 tcp_tw_reuse 调优

# 网络接口实时流量（现代替代已废弃的 ifconfig）
# 注意：ifconfig 已被标记为过时（net-tools 包），新系统推荐使用 ip 命令
ip -s link show eth0
# 输出: RX: bytes  packets  errors  dropped  overrun  mcast
# 输出:    1234567  12345    0       0        0        0
# 输出: TX: bytes  packets  errors  dropped  carrier  collsns
# 输出:    9876543  23456    0       0        0        0
# errors/dropped 持续增长 = 网卡或驱动有问题

# 原始数据源 /proc/net/dev
cat /proc/net/dev | awk 'NR>2 {print $1, "RX:", $2, "TX:", $10}'
# 输出: eth0: RX: 1234567 TX: 9876543

9. 磁盘 I/O 深度分析

本章前面已介绍 iostat -x，这里把字段彻底讲透，并补充实时工具 iotop 和 inode 检查。

# iostat -x 各列解读
iostat -x 2
# 输出: Device  r/s   w/s  rkB/s  wkB/s  r_await  w_await  aqu-sz  %util
# 输出: sda     12.5  9.3  256.0  512.0  15.20    20.10    2.35    55.0
#             │     │      │      │       │        │        │       └── 设备忙碌时间占比（≥70% 瓶颈）
#             │     │      │      │       │        │        └── 平均队列深度（越大排队越严重）
#             │     │      │      │       │        └── 写请求平均等待时间（毫秒，含排队）
#             │     │      │      │       └── 读请求平均等待时间（毫秒，含排队）
#             │     │      │      └── 每秒写入 KB
#             │     │      └── 每秒读取 KB
#             │     └── 每秒写请求数
#             └── 每秒读请求数
# aqu-sz 持续走高 → 请求在排队，磁盘忙不过来

# iotop —— 实时查看哪个进程在吃磁盘 I/O（需安装）
sudo apt install iotop
sudo iotop -o          # 只显示有 I/O 的进程
# 输出: TID  PRIO  USER     DISK READ  DISK WRITE  IO COMMAND
# 输出: 1234 be/4  alice    12.45 M/s    0.00 B/s   0%  rsync
# 输出: 5678 be/4  mysql     0.00 B/s    3.21 M/s   0%  mysqld

# 文件系统 inode 检查（inode 耗尽 = 磁盘没满但无法创建文件）
df -i /
# 输出: Filesystem  Inodes  IUsed  IFree  IUse%  Mounted on
# 输出: /dev/sda2   6553600 123456 6430144  2%    /
# IUse% 达到 100% → 大量小文件占满 inode，需要清理或扩容

# 定位"哪个目录占用了最多空间"的标准组合
du -x --max-depth=1 / 2>/dev/null | sort -rn | head -10
# 输出: 28000   /var
# 输出: 12000   /usr
# 输出: 8000    /home
du -sh /var/log/* 2>/dev/null | sort -rn | head -5   # 层层下钻

10. 进程级性能分析——top 深入与 pidstat

当系统整体指标异常，下一步就是锁定"哪个进程导致的"。top 的交互模式比表面看起来强大得多。

# top 进阶交互（运行 top 后按以下键）：
# f = 选择显示哪些列（上下移动、空格选中、q 返回）
# o = 按列过滤（如输入 COMMAND=nginx 只显示 nginx 进程）
# u = 按用户过滤（输入 alice）
# H = 切换线程视图（看多线程程序内部哪个线程吃 CPU）
# x = 高亮当前排序列；b = 粗体高亮
# 1 = 查看每个 CPU 核心的负载分布

# 只看某个 PID（诊断单一进程）
top -p 1234 -d 1

# pidstat —— 进程级 CPU/内存/IO 统计（sysstat 包）
pidstat 2                       # 每 2 秒所有进程的 CPU 统计
# 输出: Linux 6.8.0-31-generic (ubuntu-pc)  07/30/2026
# 输出: UID       PID    %usr %system   %guest   %CPU  CPU  Command
# 输出: 1000     1234    45.2     2.3      0.0   47.5    2  firefox
# 输出: 0        1235     1.0     0.8      0.0    1.8    5  mysqld

# 只看某个进程的完整统计
pidstat -p 1234 -r 2            # -r = 内存统计
# 输出: UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
# 输出: 1000     1234     34.50      0.00  3456789  456789   2.5  firefox
pidstat -p 1234 -d 2            # -d = 磁盘 I/O 统计

# 完整排查流程示例：
# 1. uptime 发现 load 高 → 2. vmstat 2 确认 CPU 还是 I/O
# 3. pidstat 2 锁定进程 → 4. pidstat -p PID -r -d 深挖
# 5. 用 lsof -p PID 看它打开了哪些文件，判断业务是否正常

示例代码

# 练习 1：系统基本信息
uname -a
# 输出: Linux ubuntu-pc 6.8.0-31-generic #31-Ubuntu SMP x86_64 GNU/Linux
uname -r
# 输出: 6.8.0-31-generic
uname -m
# 输出: x86_64
lscpu | head -10                 # 更方便的 CPU 信息
# 输出: Architecture:          x86_64
# 输出: CPU op-mode(s):        32-bit, 64-bit
# 输出: Model name:            Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz

# 练习 2：查看 /proc
cat /proc/loadavg
# 输出: 0.50 0.75 1.20 1/456 12345
cat /proc/uptime                 # 系统运行了多少秒
# 输出: 129600.34 98765.21
echo "系统已运行: $(awk '{print int($1/86400)"天"}' /proc/uptime)"
# 输出: 系统已运行: 1天
cat /proc/meminfo | grep -E "^(MemTotal|MemAvailable|SwapTotal)"
# 输出: MemTotal:       16357840 kB
# 输出: MemAvailable:    8912340 kB
# 输出: SwapTotal:       2097148 kB

# 练习 3：内存和磁盘
free -h
# 输出: Mem: 15Gi total, 4.2Gi used, 6.8Gi free, 8.7Gi available
df -h /                          # 根分区磁盘使用
# 输出: /dev/sda1  235G  28G  196G  13% /
du -sh ~                         # 家目录占用空间
# 输出: 1.2G    /home/admin

# 练习 4：系统负载
uptime
# 输出: 10:30:00 up 1 day, 2:31, 2 users, load average: 0.50, 0.75, 1.20
nproc                            # CPU 核心数
# 输出: 8
# 用 Python 模拟 CPU 负载（按 Ctrl+C 停止）
python3 -c "while True: pass" &
# 输出: [1] 12345
# 再跑一次 uptime 观察负载变化
kill %1                          # 停止后台任务
# 输出: [1]  + terminated  python3 -c "while True: pass"

# 练习 5：实时监控
# 运行 top，按 P 排序看 CPU 占用最高的进程
# 按 q 退出

# 练习 6：vmstat 观察
vmstat 2 5                       # 每 2 秒采样，共 5 次
# 输出: procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
# 输出:  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
# 输出:  1  0      0 6845560 123450 4390500    0    0    12    34   56   89  5  2 93  0  0

常见错误

错误/误区解决方案
"free 显示 used 很大就以为内存不够"看 available 而非 free。Linux 用空闲内存做缓存，程序需要时可以回收。
"把 Load Average 当成 CPU 使用率"Load Average 是等待调度的进程数，不是 CPU 占用百分比。单核 CPU 上 load=1 ≈ CPU 满负荷，4 核上 load=3 还有富余。
"top 中按 k 杀进程不确认"top 中按 k 后默认显示第一个进程的 PID，直接回车会杀死它。按 k → 输入正确的 PID → 输入信号编号（15 或 9）→ 回车。
"看到 /proc 中文件大小为 0 以为有问题"/proc 中的文件是虚拟的，大小不反映内容。用 cat 读取就能看到实际数据。
"用 uptime 判断系统是否稳定——只看 up 天数"uptime 长不一定好——如果系统跑了 300 天没重启，说明内核版本和系统服务可能太旧。但 uptime 短也不一定是坏事（可能刚安全更新重启过）。
"df 显示磁盘满但 du 加起来没那么多"已删除但仍被进程占用的文件不会释放空间。用 lsof | grep deleted 查找这类文件，重启占用进程即可释放。
"top 中 VIRT 很大以为内存泄漏"VIRT（虚拟内存）包含共享库、映射文件等，不等于实际物理内存占用。关注 RSS（常驻内存）和 %MEM 列才准确。

最佳实践

#建议说明
1建立"正常值基线"在系统正常运行期间记录 CPU、内存、磁盘、网络的典型值。以后出问题时才能判断"现在的异常值偏离基线多少"。
2看趋势不看瞬时值top 的瞬时 CPU 占用没有太大意义。用 vmstat 5 持续观察变化趋势。
3用 htop 替代 top（如果可以安装）sudo apt install htop。htop 有彩色界面、支持鼠标操作、更直观的树形进程视图。
4安装 sysstat 包获取历史性能数据sudo apt install sysstat 启用 sar 数据收集。出问题时可以回查"昨天 10 点的 CPU 负载是多少"。
5监控四大件：CPU、内存、磁盘 I/O、网络系统性能问题通常卡在这四个资源的某一个上。用 top（CPU+内存）、iostat（磁盘）、ss（网络）逐个排查。

练习题

  1. （概念）Load Average 的三个数值（1/5/15 分钟）分别代表什么？在 8 核 CPU 上，load average 为 6.0 意味着什么？
  2. （概念）/proc/meminfo 中的 MemAvailable 和 MemFree 有什么区别？
  3. （实操）运行 uname -a 并记录你的内核版本和系统架构。用 cat /proc/cpuinfo 找出你的 CPU 型号和逻辑核心数。
  4. （实操）运行 vmstat 2 10（每 2 秒采样，共 10 次），观察 r（运行队列）和 b（不可中断睡眠）两个值的变化。
  5. （实操）用 free -h 查看内存，然后打开几个程序（浏览器、终端），再次运行 free -h 观察 available 的变化。
  6. （探究 🔍）在终端跑 stress --cpu 4 --timeout 30（需 sudo apt install stress），同时在另一个终端用 top 和 uptime 观察 CPU 负载变化。理解"CPU 密集型任务"如何影响 Load Average。
  7. （探究 🔍）打开 htop（需安装），按 F5 切换到树形视图，观察进程的父子关系。找到 PID 1（systemd），看看它创建了哪些子进程。
点击查看答案
  1. （概念）Load Average 的三个数值分别代表过去 1/5/15 分钟的平均活跃进程数（正在运行 + 等待 CPU 的进程）。在 8 核 CPU 上 load 6.0，意味着平均有 6 个进程在竞争/使用 CPU，未超过 8 核容量，系统处于合理负载。load > 核心数说明 CPU 过载。
  2. （概念）MemFree 是完全空闲的物理内存量。MemAvailable 是应用程序实际可用的内存量——包括 MemFree + 可回收的缓存和缓冲区。MemAvailable 是比 MemFree 更准确的可用性指标，是预测"还能开多少程序"的可靠依据。
  3. （实操）`uname -a` 输出内核版本（如 6.8.0-36-generic）、主机名、架构（x86_64/arm64）。`cat /proc/cpuinfo` 输出每核心详细 CPU 信息。`nproc` 直接输出逻辑核心数。`lscpu` 提供更整洁的 CPU 汇总。
  4. （实操）`vmstat 2 10`：r 列是运行队列（正在运行+等待 CPU 的进程数），b 列是阻塞队列（等待 I/O）。如果 r 持续 > CPU 核心数 → CPU 瓶颈。如果 b 持续 > 0 → I/O 瓶颈。正常系统 r 应在核心数以下。
  5. （实操）`free -h` 先记录初始 available。打开浏览器和多个程序后再运行 free -h，观察 available 减少、buff/cache 的变化。可用内存紧张时系统会回收缓存。始终关注 available 而非 free 列。
  6. （探究 🔍）`sudo apt install stress`，然后 `stress --cpu 4 --timeout 30`。同时在另一终端运行 `top` 观察 CPU 占用率飙升，`uptime` 观察 load average 快速上升。stress 结束后负载逐渐回落。理解 CPU 密集型任务对负载的直接影响。
  7. （探究 🔍）`sudo apt install htop`，按 F5 进入树形视图。PID 1 (systemd) 是系统所有进程的祖先。观察 systemd → 各种服务子进程（如 systemd-journald、systemd-logind、sshd 等）的层级关系。树形视图直观展示了"父—子"进程链。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

检查项自测问题验证方法
概念理解能用自己的话解释 Load Average 的含义和判断标准尝试向他人讲解
命令操作能不查文档使用 free、df、du、top、vmstat 监控系统状态在终端实际执行
原理掌握能说出 /proc 虚拟文件系统的作用和内存中 buff/cache 的含义画出数据来源图
故障排查能独立使用 top 和 ps 定位占用 CPU 或内存最多的进程模拟故障并排查
最佳实践能说明为什么判断内存是否够用应该看 available 而不是 free对比不同指标

本章总结

系统性能监控是每个系统管理员的基本功。本章从 uname（系统信息）和 /proc（内核数据窗口）入手，到 free（内存）、df/du（磁盘）、uptime（负载）、top（实时监控）、vmstat/iostat（专项统计），构成了完整的系统健康状态检查工具箱。

速查表

概念一句话定义
uname -a系统基本信息（内核、主机名、架构）
/proc/虚拟文件系统，内核状态的实时窗口
Load Average1/5/15 分钟的平均等待 CPU 的进程数
free -h查看内存使用（看 available 而非 free）
top实时进程监控（P=按CPU排序，M=按内存排序）
vmstatCPU、内存、I/O 的综合统计工具

下一步：进入 2.4：进程管理「进程管理」，学习如何控制运行中的进程。

延伸阅读

  • 命令：dstat（需安装）——比 vmstat 更现代的全能性能统计工具，一次性显示 CPU、磁盘、网络、内存
  • 命令：perf——Linux 性能分析器，适合深入定位 CPU 热点
  • 书籍：《BPF Performance Tools》（Brendan Gregg）——基于 eBPF 的现代性能分析
  • 实践建议：写一个简单的 Shell 脚本，每隔 5 分钟记录 CPU、内存、磁盘使用情况到日志文件。这是你的第一个"性能监控工具"。

相关文章

Nginx Web服务器 Ansible 自动化 网络故障排查 SSH 深入

常见问题

SSH 连接速度慢怎么排查？
可能是 DNS 反向查询耗时：在 /etc/ssh/sshd_config 中设置 UseDNS no 然后重启 sshd。也可能是 GSSAPI 认证慢：设置 GSSAPIAuthentication no。客户端设置 -v 参数查看详细连接过程，找到耗时最长的步骤。
rsync 和 scp 怎么选？
一次性的少量文件传输用 scp 更简单。定期备份或大目录同步用 rsync：支持增量传输、断点续传、压缩、排除模式。推荐 rsync -avz --progress src/ user@host:/dest/ 做远程同步，加上 --delete 同步删除操作。
ping 不通就是网络不通吗？
不一定。很多服务器禁用了 ICMP（ping 的协议），或者防火墙屏蔽了 ICMP 包。ping 不通时应继续用 telnet host port 或 nc -zv host port 测试特定端口，用 traceroute/mtr 查看路由路径，用 curl -v 测试 HTTP 服务。网络排查要逐层递进。
↑ 回到顶部