Suricata 8.0.7 性能分析

性能问题可能有许多成因。本节介绍排查方向：前半部分包含基本步骤和实用工具，后半部分提供更深入的解释及特殊情况。 ## 系统负载

首先检查系统负载。运行 htop 等 top 类工具，了解系统整体负载以及流量分配是否存在瓶颈。如果只有少量 CPU 核心持续达到 100%，其他核心没有，可能是流量分配不均，或出现了“大象流”。原文截图中，单个大象流就使一个核心达到峰值。

如果所有核心都达到峰值，硬件可能不足以承载当前流量，也可能是配置不当。同时检查内存：实际内存用量过高而使系统开始交换，会严重降低性能。

系统负载可以提供初步线索，帮助确定后续应重点排查的部分；后半节会展开说明。 ## 日志文件

接着检查所有日志，重点查看 stats.log 和 suricata.log 中是否有明显问题。最直观的指标是 capture.kernel_drops：理想情况下该指标不会出现，至少应低于 capture.kernel_packets 的 1%。较高的丢包率可能减少记录到的事件和告警数量。 如果统计中出现 memcap，可以提高配置中的相应上限。不过，这会增加内存使用，修改时需要考虑这一影响。

也别忽略系统日志；即使只运行 dmesg，也可能发现潜在问题。 ## Suricata 自身负载 除系统负载外，Suricata 自身的负载也能反映性能问题。perf 是定位瓶颈的实用工具。需要安装 perf 及 Suricata 的调试符号，否则输出的帮助有限。报告性能问题时，这些输出也有助于开发团队缩小问题范围。

sudo perf top -p $(pidof suricata)

如果特定函数调用排在顶部并显示为红色，它们可能是瓶颈。例如 IPOnlyMatchPacket 可能与高丢包率或不完整流有关，并造成性能下降。要分析特定线程，可以给 perf top 传入 -t TID。 有些函数提示某种协议解析器被大量使用。此时可以排查相关性能缺陷，或尝试过滤对应流量。

总体而言，可以调整 Suricata 提供的配置选项，重点参考高性能配置。 ## 流量

如果硬件足以处理流量，但丢包率仍然很高，通常与某些特定流量问题有关。 ### 基本检查

基本检查包括：

• 流量是否双向。如果大多是单向流量，就缺失了流中的重要部分，参见后文 tshark 示例。Suricata 统计中 SYN、SYN-ACK 与 RST 计数差异很大，也可能提供线索。

• 是否存在封装流量。虽然支持 GRE、MPLS 等协议，但它们仍可能造成性能问题，尤其是存在多层封装时。

• 使用 iftop 等工具定位大象流。持续速率超过 1 Gbit/s 的流可能让一个核心一直处于 100%，并使丢包率上升，而深入检查这种流量未必有意义。

• 使用 BPF 过滤器缩小排查范围。例如用 not port 443 排除所有 HTTPS 流量，从而排除可能有问题的流量；若怀疑某一协议，也可以用 port 25 只查看特定端口。更多信息见 Suricata 的 Ignoring Traffic 文档。

• 使用 VLAN 时，如果只有流的一个方向带 VLAN 标签，禁用 vlan.use-for-tracking 可能有帮助。 ### 深入检查

深入分析流量时，还需考虑一些高级步骤与特殊情况。 如果使用 VLAN QinQ（IEEE 802.1ad），在 Intel 驱动、AF_PACKET 运行模式与 cluster_qm 组合下要特别留意。原文指出，该场景预期使用 0x8100 和 0x88A8 两种 EtherType，但许多实现会在每一层都使用 0x8100。如果最外层 VLAN 标签相同，即使内层标签不同，在 cluster_qm 模式下仍会进入同一个队列。 原文在 i40e 驱动最高 2.8.20、固件最高 7.00 的版本中观察到这一问题；若新版本已修复，可通过 Suricata 支持渠道 报告。 用 tshark 概览流量方向，可运行：

sudo tshark -i $INTERFACE -q -z conv,ip -a duration:10

输出会显示 10 秒内的所有流。如果某个方向的计数为 0，说明是单向流量，例如看不到 ACK 数据包。Suricata 按流处理数据，因此这会显著影响可见性。应优先修复单向流量问题；若完全无法修复，可在 stream 配置中启用 async-oneside。 检查支持不充分的其他少见或复杂协议。可以过滤这些流量，观察性能是否改变。例如使用 BPF 过滤器 not ether proto 0x8903 排除 Cisco Fabric Path（EtherType 为 0x8903），因为原文怀疑它可能导致性能问题，参见 问题 3637。 ### 大象流

所谓大象流或流量尖峰较难处理。多数情况下它们来自大文件传输或备份，对全部流量解码并不现实。从网络安全监控角度，记录流元数据，并检查流开始时的数据包，通常已经足够，不必检查整个流。 如果按前述方法定位到特定流，尝试过滤它们。最简单的是 BPF 过滤器，但仍有性能开销。更理想的方式是在驱动或网卡层更早地过滤，参见 eBPF/XDP，甚至在流量抵达 Suricata 主机之前就过滤。有些商用网络流量分发设备支持这种能力，称为 Flow Shunting 或 Flow Slicing。 ## 规则

规则集既影响检测能力，也影响 Suricata 的性能，因此还应检查已启用规则的影响。 如果遇到性能问题且难以缩小范围，可以先不启用任何规则运行 Suricata，再使用前半节介绍的工具。即使没有启用签名，Suricata 仍会完成大部分解码与流量分析，因此仍应观察到一定负载。 若硬件本应能承载这些流量，但负载仍高且出现丢包，应进一步排查特定流量问题，或通过社区渠道报告，以便进一步调查。 Suricata 的 rules 目录还提供一些面向特定流量问题的签名，可临时启用测试。建议从 decoder-events.rules、stream-events.rules 和 app-layer-events.rules 开始。 规则剖析（Rule Profiling）和数据包剖析（Packet Profiling）也有助于找出有问题的规则或流量模式。编译 Suricata 时使用 --enable-profiling 可启用这些功能，但它们会影响性能，应仅用于故障排查。

来源与许可

Suricata 8.0.7 官方文档：Performance Analysis，Open Information Security Foundation 与文档贡献者。文档采用 CC BY-NC 4.0，保留非商业性使用条件。2026-10-03 中文翻译与静态排版转换；保留原始命令、历史驱动及固件版本，未执行命令或复测性能。