AV/IPS 内存高排查
AV/IPS 内存高排查
背景介绍
在使用 Antivirus/IPS 的场景中，内存保护模式的触发可能属于高负载条件下的正常保护机制，并不一定表示系统异常或缺陷。
本文以常用的 flow mode 下的 ipsengine + antivirus 为示例，用一台 4GB 内存的 FortiGate 演示：穿过 FortiGate 对一个 2MB 文件发起大量 HTTP: 80 下载请求，目标是制造多个下载同时处于 pending 与 buffered 状态。后续主要聚焦 antivirus 与 ipsengine 的表现与关联，并给出采集、判断与改进方向。
问题现象
系统挂起（System hangs）
- 当发起下载且文件总大小大于 512KB 时，系统会分配 1MB Cached RAM（用于后续缓冲与处理）。
- 示例：若同时启动 1024 个 4MB 文件传输：
- 初始预分配约 1MB * 1024 = 1GB RAM。
- 在传输接近结束且多数会话同时处于 pending 状态时，可能累积到 4MB * 1024 = 4GB 的缓冲需求，从而占满 4GB 设备的可用内存。
- ipsengine 没有缓存限制。
- 此类极端场景可能导致系统 hang：转发与管理均不可用。
系统死锁（System deadlock）
- 在高内存压力下，系统可能耗尽可用 cached memory。
- ipsengine 进入“S”（sleeping）状态，等待 cache 资源可用以继续缓存流量。
- 该状态可能导致业务中断。
排查准则
- 必须在问题发生当下采集数据：在所有内存保护模式场景中，应在问题发生期间采集调试数据。内存指针、进程内存分配、潜在内存泄漏迹象等关键证据通常只会在异常发生时体现。如果在系统恢复正常或接近正常后再采集，很多现象不会出现在数据中，影响判断。
- 需要观察一段时间内的变化趋势：不少场景需要通过脚本或周期性采集，在一段时间内观察内存使用的演化过程，判断是否存在持续增长、周期性峰值、或与流量/会话变化一致的波动关系。
初步排查
diagnose sys top 2
2表示每 2 秒刷新一次。- 在 top 输出界面中：
- 按“m”按内存排序。
- 按“p”按 CPU 排序。
- 记录进程 PID，用于后续追踪。
- 建议连续采集一段时间，观察 CPU 与内存是否波动、是否同步变化，并尝试总结规律。
diagnose sys top-mem 10
- 列出内存消耗最高的 10 个进程。
- 在较大平台上可适当提高显示进程数。
- 重点关注：
- 哪个进程消耗最高。
- 该进程与其他进程合计占用多少。
- 这几个进程内存之和占系统总内存比例。
diagnose hardware sysinfo conserve
- 当前 FortiGate 是否进入了内存保护模式。
- 内存占用率是否超过 red threshold。
- 如果进入了内存保护模式，则比较其值是否高于 red threshold。
diagnose hardware sysinfo memory
- 可能看到 Cached 占用非常高（例如 3.3GB/4GB）。
- 其他可能较高的 bucket 包括 Inactive、Inactive (anon)、Shmem。
- 该输出与 Linux 的/proc/meminfo（cat/proc/meminfo）一致，可参考 Linux 文档进一步理解各 counter 含义。
get system performance status
- 该输出包含实时与历史统计，例如：
- 过去 30 分钟平均网络使用。
- 最近 10/30 分钟会话数变化。
- 若设备在几分钟前经历过流量冲击，部分非实时的变化在其他命令中不易直接观察，但在此统计中可能更直观。
总结
- 此例中，ipsengine 是主要的内存占用者（示例中 PID 257）。
- scanunitd（一个或多个 worker）是主要 CPU 消耗者（示例中 PID 12262、12260）。
- 设备处于 内存保护模式且超过 red threshold。
- 内存主要被 Cached、Inactive、Inactive (anon)、Shmem 占用。
- 基于以上现象，下一步应重点排查：ipsengine 为何占用大量内存，以及其与 antivirus（scanunitd 高 CPU）之间的关联关系。
ipsengine/antivirus 计数器
本章节目标是确定“pending 状态文件传输缓存用于 AV 检测导致 ipsengine 内存上升”。
diagnose sys process dump 254
查看进程 PID 254（前文中查看的 ipsengine 进程 PID，示例因设备重启导致 PID 变化，请忽略 PID 差异）的状态：
- 进程状态：running（表示进程正在工作）。
- VmSize：示例约 3.6GB，表示该进程正在分配/映射大量内存。
继续向下滚动输出结果：
在 shm（shared memory）目录下出现大量标记为“deleted”的文件映射。
ipsengine 创建了这些文件并删除它们。
这些文件位于 shm（共享内存空间），通常表示 ipsengine 将数据放入共享内存供其他处理组件使用，或处于等待相邻处理完成的状态。
对 scanunitd 做类似的 process dump，通常可看到相同的 shm 文件处理模式。
ipsengine/scanunitd 可能会派生多个 worker，PID 可能变化，建议在问题发生时尽快采集。
ipsengine/scanunitd debug
启用 Debug：
diagnose ips debug enable av diagnose ips debug enable content diagnose ips debug status show diagnose sys scanunit debug all enable diagnose sys scanunit debug level verbose diagnose sys scanunit debug show diagnose debug enable运行数秒后结束 Debug（调试输出可能非常多，一般不需要运行超过 10 秒）：
diagnose ips debug disable all diagnose ips debug status show diagnose sys scanunit debug all disable diagnose sys scanunit debug reset diagnose sys scanunit debug show收集 Debug 输出结果：
可以看到“ips_flowav_append”任务持续处理多个 query/task。
多个下载会话不断接收 1448 字节的 chunk，但未完成。
未出现如下“scanunit 任务完整完成”相对应的输出，判断以上 scanunit 任务处于“pending”状态。
diagnose test application ipsmonitor 24
查看 ipsmonitor 统计中的 antivirus 统计信息：
file open在 ipsengine 需要缓存一个传输会话并将数据交给 antivirus 做进一步检查时递增。file close在对应会话完成/关闭后递增。- 若传输正常完成，
file open与file close通常应保持相对一致的增长趋势。 - 4152（file open） - 2002（file close） = 2150，存在约 2150 个 pending 状态的传输任务正在被缓存，从而消耗 Cached memory。
继续向下滚动 ipsmonitor 输出，可见
total allocated memory（Bytes）。
- 2761613312 Bytes 约为 2.7GB。
- 该数值可能与其他命令观察略有差异，因为会话仍在动态处理，但数量级仍处于较高水平。
排查结论
- 当前现象可理解为系统在压力条件下的正常表现：由用户流量与配置组合触发资源占用上升。内存保护模式的触发可能属于高负载条件下的正常保护机制，并不一定表示系统异常或缺陷。
- ipsengine 内存飙升主要由大量 pending 文件传输引起。这些传输需要被缓存，才能由 Antivirus 完成检测。
- 在 flow mode 下，如果不对文件内容进行缓存，将无法完成 Antivirus 检测流程。原因是 Antivirus 首先需要计算 MD5 校验，而 MD5 只能在获取完整文件内容后计算。
- 当 Antivirus 完成 allow/block 判定且会话关闭后，相关缓存内存会随之释放。
- 优化方向：
- 选择更高型号平台，以提供更高的资源上限来承载更多并发 pending 文件传输与 Antivirus 检测。
- 评估是否必须对特定业务流量启用 Antivirus。
- 提升带宽：目标是降低 pending 状态传输任务的数量与持续时间，减少重叠并发带来的缓存累积。
- 配置优化：参考：开局与日常维护 → 2GB 内存设备配置优化章节。