当前位置：首页 > news >正文

零基础学习性能测试第二章-linux服务器监控：内存监控

news 2025/11/10 16:54:00

- 学习内容与快速应用路径
- - 第一阶段：理解 Linux 内存基础 (0.5天)
  - 第二阶段：掌握核心监控命令与指标 (1-2天)
  - 第三阶段：识别内存问题与瓶颈 (核心技能)
  - 第四阶段：整合到性能测试工作流程 (快速应用落地)
- 快速应用到工作中的关键策略

零基础学习 Linux 内存监控并快速应用到性能测试工作中，关键在于 理解核心概念、掌握实用命令、识别关键指标、关联分析问题。下面是一个聚焦内存监控的详细学习路径，助你快速上手：

核心目标：

理解 Linux 内存管理机制： 知道内存是如何分配、使用和回收的。
掌握核心监控命令： 熟练使用 free, vmstat, top/htop, /proc/meminfo 查看内存状态。
识别关键内存指标： 能解读 used, free, buff/cache, available, swap used/free, si/so, oom 等指标的含义和健康阈值。
定位内存瓶颈与问题： 能判断内存不足、Swap 过度使用、内存泄漏、OOM Killer 触发等问题。
整合到性能测试流程： 在压测过程中实时监控内存，并在报告中分析内存使用情况。

学习内容与快速应用路径

第一阶段：理解 Linux 内存基础 (0.5天)

物理内存 vs Swap 空间：
- 物理内存 (RAM)： CPU 直接访问的高速内存，程序运行的核心区域。快！
- Swap 空间： 硬盘上划出的一块区域，当物理内存不足时，操作系统会将不活跃的“页”移到这里。慢！频繁使用 Swap 会导致性能急剧下降（磁盘 I/O 瓶颈）。
- 快速应用认知： 性能测试的核心目标是让程序主要在物理内存中高效运行，尽量避免或最小化 Swap 的使用。
内存使用组成：
- Used： 已使用的内存总量 (包括应用程序使用的和内核缓存/缓冲)。
- Free： 完全未被使用的内存。
- Buffers： 内核用于块设备（如磁盘）I/O 的缓存（原始数据块）。目的是加速磁盘读写。
- Cached： 内核用于文件系统（已打开文件）的缓存（文件内容页）。目的是加速文件访问（如程序代码、库文件、频繁读取的数据文件）。Buffers 和 Cached 合称 buff/cache。
- Available： 最重要的指标之一！ 估算在不使用 Swap 的情况下，可用于启动新应用程序的内存量。它考虑了 Free 内存 + 部分可回收的 buff/cache。比 Free 更能反映实际可用内存。
- Swap： 已使用 (used) 和剩余 (free) 的 Swap 空间大小。
- 快速应用认知： 看到 Free 很少不要惊慌！Linux 会尽量利用内存做缓存 (buff/cache)，这是好现象。重点关注 Available 和 Swap used！
内存回收机制：
- 当内存不足 (Available 很低) 时，内核会尝试回收内存：
  - 回收 Cached 中不常用的文件页（相对容易，影响较小）。
  - 回收 Buffers。
  - 将不活跃的匿名页（应用程序堆、栈等）移动到 Swap (swapping out)。这是性能杀手！
- OOM Killer： 当内存严重不足且回收无效时，内核会强制终止占用内存多的进程来保护系统。这是灾难！

第二阶段：掌握核心监控命令与指标 (1-2天)

目标：熟练使用命令获取数据，理解每个关键指标的含义和健康阈值。

free 命令 (最常用、最直观)：
- 命令： free -h (-h 以人类可读格式显示，如 G, M)
- 输出解读：
```
              total        used        free      shared  buff/cache   available
Mem:            15Gi        5.2Gi       1.1Gi       123Mi        8.7Gi        9.5Gi
Swap:           2.0Gi       0B          2.0Gi
```
  - Mem 行：物理内存信息。
  - Swap 行：Swap 空间信息。
  - 关键指标：
    - available (9.5Gi)： 核心关注！ 可用内存充足。
    - used (5.2Gi)： 已用内存，包含 buff/cache。单独看意义不大。
    - buff/cache (8.7Gi)： 缓存大小。数值大通常是好事（资源充分利用），只要 available 够用。
    - free (1.1Gi)： 完全空闲内存。数值小是正常的（被用作缓存），不能单独作为内存不足依据！
    - Swap used (0B)： 核心关注！ 理想状态应为 0 或极小值。大于 0 即开始影响性能，持续增长或占比高是严重问题。
- 健康阈值 (经验值，需结合业务)：
  - Available： > 总内存的 10-20% (越紧张风险越高)。压测时需监控其趋势，看是否持续下降至危险水平。
  - Swap used： ≈ 0 为最佳。持续 > 0 或 > Swap 总大小的 10% 就需要警惕并分析原因。
- 快速应用：
  - 在测试服务器上运行 free -h，记录初始状态。
  - 在压测过程中，定期运行 free -h (如每 30 秒或 1 分钟)，观察 Available 和 Swap used 的变化趋势。
  - 关注点：Available 是否持续下降？Swap used 是否从 0 开始增长？增长速率如何？
vmstat 命令 (查看内存动态和 Swap 活动)：
- 命令： vmstat [间隔秒数] [次数] (如 vmstat 1 5：每秒采样一次，共 5 次)
- 输出解读 (重点关注内存和 Swap 列)：
```
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st1  0      0 1234567 98765 654321    0    0    10    15  101  200 10  5 85  0  0
```
  - swpd (0)： 已使用的 Swap 空间大小 (KiB)。等同于 free 命令的 Swap used。
  - free (1234567)： 空闲内存量 (KiB)。等同于 free 命令的 free。
  - buff (98765)： 用作 Buffers 的内存 (KiB)。
  - cache (654321)： 用作 Cached 的内存 (KiB)。
  - si (0)： Swap In (KiB/s)。每秒从 Swap 读回内存的数据量。 数值持续 > 0 表示系统正在从慢速 Swap 读取数据，性能严重下降的标志！
  - so (0)： Swap Out (KiB/s)。每秒从内存写入 Swap 的数据量。 数值持续 > 0 表示物理内存不足，正在向慢速 Swap 卸载数据，性能下降的开始！
- 健康阈值：
  - si, so： 理想状态是持续为 0。任何持续的非零值（尤其是 si）都是性能问题的明确信号！ 数值越大问题越严重。
- 快速应用：
  - 在压测过程中，持续运行 vmstat 1 (每秒刷新一次)。
  - 眼睛紧盯 si 和 so 列！一旦出现非零值（特别是 si），立刻记录下时间点，并关联此时性能测试工具报告的 RT(响应时间) 是否飙升、TPS(吞吐量) 是否下降、错误率是否上升。
  - 这是证明 Swap 活动导致性能瓶颈 的直接证据！
top / htop 命令 (查看进程级内存占用)：
- 命令： top (动态刷新) 或 htop (更友好，推荐安装 yum install htop / apt install htop)
- 内存相关视图：
  - 顶部汇总行：类似 free，显示总 Mem 和 Swap 使用情况 (used, free, buff/cache)，注意看 avail Mem。
  - 进程列表：关键列：
    - %MEM：该进程占用物理内存占总内存的百分比。 快速找出内存消耗大户。
    - VIRT：虚拟内存大小。 进程申请的总地址空间（代码+数据+堆栈+共享库+映射文件等），可能远大于实际使用的物理内存 (RES)。关注增长趋势。
    - RES：常驻内存大小。 进程当前实际使用的、未被换出的物理内存大小 (包含共享库占用的部分)。更接近进程的实际物理内存消耗。
    - SHR：共享内存大小。 RES 中可被其他进程共享的部分（如共享库）。RES - SHR 大致是该进程私有内存。
    - CODE：代码占用的物理内存大小。
    - DATA：数据+栈占用的物理内存大小。 关注其增长（可能内存泄漏）。
- 快速应用：
  - 当 free/vmstat 显示整体内存紧张时，立刻运行 htop。
  - 按 %MEM (Shift+M) 或 RES (F6 -> RES) 降序排序。
  - 找出占用物理内存 (RES) 最高的前几个进程。记录它们的进程名 (COMMAND) 和 PID。
  - 观察可疑进程的 RES 和 VIRT 是否在压测过程中持续增长（可能是内存泄漏）。
  - 结合应用知识，判断这些进程是否是被测应用或其依赖组件（如数据库、中间件）。
/proc/meminfo 文件 (最底层详细信息)：
- 命令： cat /proc/meminfo
- 内容： 包含 free, vmstat, top 等命令使用的所有原始数据，以及更多细节。
- 关键指标 (补充理解)：
  - MemTotal：总物理内存。
  - MemFree：空闲内存 (同 free 命令)。
  - Buffers：同 free/vmstat。
  - Cached：同 free/vmstat。
  - SwapCached：曾经被换出、但又被换入且仍被 Swap 空间缓存的内存。是 Cached 的一部分。
  - Active(file) / Inactive(file)：活跃/不活跃的文件缓存页（属于 Cached）。
  - Active(anon) / Inactive(anon)：活跃/不活跃的匿名页（应用程序堆栈等）。
  - SwapTotal / SwapFree：同 free 命令。
  - Committed_AS：系统当前已分配的内存总量估计（包括未使用的保留空间和已使用的）。如果接近 CommitLimit (通常是 SwapTotal + MemTotal * overcommit_ratio)，则系统面临 OOM 风险。
  - Dirty：等待写回磁盘的脏页大小。过多可能表示磁盘 I/O 慢或应用写频繁。
  - Writeback：正在写回磁盘的页大小。
  - Slab / SReclaimable / SUnreclaim：内核数据结构占用的内存 (Slab = SReclaimable + SUnreclaim)。如果 SUnreclaim 过大且持续增长，可能是内核模块泄漏。
- 快速应用： 当使用 free/vmstat/htop 发现异常但需要更深入信息时，查阅此文件。例如，怀疑 Slab 泄漏时可重点看 Slab 相关项。

第三阶段：识别内存问题与瓶颈 (核心技能)

物理内存不足：
- 现象： Available 持续降低至危险水平 (如 < 总内存 5%)，free 极低，buff/cache 可能被回收变小。Swap used (swpd) 开始增长，so > 0。
- 后果： 开始使用 Swap，性能下降。严重时触发 OOM Killer。
- 快速诊断： 看 free -h (Available), vmstat 1 (swpd, so)。用 htop 找内存大户。
- 性能测试关联： 观察 so > 0 或 si > 0 的时间点，性能测试的 RT 会显著上升，TPS 会下降。
Swap 过度使用 (Thrashing)：
- 现象： si 和 so 持续保持很高的非零值。swpd 可能很高。CPU 等待 I/O 的时间 (wa in vmstat/top) 飙升（因为 Swap I/O 慢）。
- 后果： 系统极度缓慢，几乎所有时间都花在读写 Swap 上，无法有效工作。
- 快速诊断： vmstat 1 是黄金命令！看 si, so, wa 列。
- 性能测试关联： 此时性能测试结果会极其糟糕，RT 可能达到秒级甚至分钟级，TPS 暴跌，错误激增。
内存泄漏 (Memory Leak)：
- 现象： 某个特定进程的 RES (在 htop 中) 或整个系统的 used (排除 buff/cache 影响) 在负载稳定或空闲时持续、单调增长，即使过了业务高峰也不释放。最终耗尽内存导致 OOM。
- 后果： 内存被无效占用，可用内存越来越少，最终触发 OOM 或被迫重启。
- 快速诊断：
  - 压测过程中及压测后静置期，持续监控 htop，按 RES 排序，观察目标进程的 RES 值。绘制其随时间变化的曲线图（如果使用 Grafana 会更方便）。
  - 监控系统级 MemAvailable 趋势（排除缓存影响）。
- 性能测试关联： 在长时间稳定性测试中容易暴露。表现为随着测试时间延长，Available 逐渐减少，最终可能引发 Swap 或 OOM，导致测试后期失败。
OOM Killer 被触发：
- 现象： 进程突然消失（被杀）。系统日志 /var/log/messages 或 dmesg 命令输出中会有明确记录 (Out of memory: Kill process ... )。
- 后果： 服务中断，数据可能丢失。
- 快速诊断： 检查系统日志 (grep -i 'out of memory' /var/log/messages 或 dmesg | grep -i 'out of memory')。日志会记录被杀进程的 PID 和名称。
- 性能测试关联： 这是性能测试中最严重的失败场景之一。通常发生在内存压力测试或长时间稳定性测试的后期。需要立即分析日志确定被杀的进程，并结合之前的内存监控数据（如 free, vmstat 历史）分析原因。

第四阶段：整合到性能测试工作流程 (快速应用落地)

测试前准备：
- 确认监控工具可用：free, vmstat, htop 通常默认安装，确保 htop 已装 (yum/apt install htop)。
- 基线测量： 在系统空闲或低负载时，记录 free -h, vmstat 1 5 的输出作为基线。运行 htop 记录主要进程的初始内存占用 (RES)。
压测中实时监控：
- 打开多个终端窗口或使用 tmux/screen：
  - 窗口 1：持续运行 vmstat 1，紧盯 swpd, si, so, free (参考), wa。
  - 窗口 2：定期运行 free -h (如每 30 秒一次)，记录 Available 和 Swap used。
  - 窗口 3：运行 htop，按 %MEM 或 RES 排序，定期观察内存大户及其内存增长趋势。特别关注被测应用进程。
- 核心关注：
  - Available 下降趋势？降到多少？
  - Swap used 是否 > 0？增长速率？
  - vmstat 中 si / so 是否 > 0？数值多大？是否持续？
  - 是否有进程 RES 持续异常增长？
  - 当 si/so > 0 或 Available 极低时，立即记录时间戳，并与性能测试工具报告的 RT, TPS, 错误率 进行精确时间点对比！这是证明内存瓶颈导致性能问题的关键证据。
测试后分析与报告：
- 收集数据： 保存 vmstat 输出、free 的定期记录、htop 截图（尤其是内存紧张时）、系统日志 (dmesg 和 /var/log/messages 相关部分）。
- 分析关键点：
  - 内存使用峰值：Available 最低值是多少？Swap used 最高值是多少？
  - Swap 活动：si / so 的最大值、平均值？持续时间？是否与性能下降点吻合？
  - 内存大户：压测中哪些进程消耗内存最多？其 RES 增长了多少？
  - 是否存在泄漏迹象？(压测后静置观察 RES 是否回落？)
  - 是否发生 OOM？杀死了哪个进程？
- 报告撰写：
  - 清晰描述内存监控结果： 列出关键指标峰值（Available min, Swap used max, si/so max/avg）。
  - 展示关联性图表： 制作时间轴图表（或文字描述），将 Available 下降点、Swap used 增长点、si/so 出现点与 性能测试工具记录的 RT 上升点、TPS 下降点、错误率上升点 对应起来。
  - 指出问题与瓶颈：
    - 如：“当 Available 低于 1GB 且 so 持续大于 100KB/s 时，平均响应时间从 200ms 上升至 1500ms，TPS 下降 50%”。
    - 或：“进程 app_server 的 RES 在 2 小时测试中从 1GB 持续增长至 4GB，存在内存泄漏嫌疑”。
    - 或：“测试结束前触发 OOM Killer，终止了数据库进程 mysqld”。
  - 给出建议：
    - 优化应用内存使用/排查内存泄漏。
    - 增加物理内存。
    - 优化配置减少内存需求。
    - 调整 Swap 策略（临时缓解，非根本解决）。
    - 检查数据库/中间件配置。

快速应用到工作中的关键策略

工具优先： 先熟练掌握 free -h, vmstat 1, htop 这三个最常用、最直接的工具。放弃初期就研究 /proc/meminfo 所有字段的冲动。
指标聚焦： 死死盯住 Available, Swap used, si/so。它们是内存健康和性能的晴雨表。
关联分析： 内存指标本身不直接等于性能问题！ 必须将 si/so > 0 或 Available < 阈值 的时间点与 性能测试工具的响应时间 (RT)、吞吐量 (TPS)、错误率曲线 进行精确关联对比。这是证明内存是瓶颈的核心方法！
进程视角： 当整体内存吃紧时，立刻用 htop 按内存排序，找出罪魁祸首进程。
基线比较： 测试前后和不同负载下的内存状态对比，更容易发现问题。
关注趋势： 内存问题（尤其泄漏）往往体现在持续的变化趋势上，而非某个瞬间的快照。持续监控很重要。
理解 Swap 的代价： 深刻认识到 si（Swap In）对性能的毁灭性打击。so > 0 是警告，si > 0 是警报！
动手实践： 立即在测试环境模拟：
- 运行一个消耗内存的脚本，观察 free, vmstat, htop 的变化。
- 尝试填满内存，观察 si/so 何时出现，系统何时变卡，OOM 何时触发（慎用，可能影响他人）。

总结： 零基础快速掌握 Linux 内存监控的核心就是 盯紧 Available & Swap used (free), 监控 si & so 动态 (vmstat), 揪出内存大户 (htop)，并将这些内存指标的变化 精准关联 到性能测试结果的变化上。通过几次实际的性能测试，结合这个流程进行分析，你就能快速将内存监控技能应用到工作中，有效定位内存相关的性能瓶颈。祝你成功！

查看全文

http://www.dtcms.com/a/288402.html