跳至主要內容

Windows Update 导致 scanunitd CPU 高

2026/6/17AV 常见问题7.4.4大约 7 分钟

Windows Update 导致 scanunitd CPU 高

如果防火墙策略启用了反病毒扫描，客户端通过 FortiGate 传输 Windows Update 流量时，可能会出现 scanunitd 进程占用大量 CPU 的情况。

问题现象

  1. FortiGate 升级到 FortiOS 7.4.4 后，处理 Windows Update 下载流量时，整体 CPU 使用率明显升高，多个 CPU Core 的 system 占比偏高，idle 占比偏低。

  2. 通过以下命令查看系统 CPU 状态：

    # get system performance status

CPU states: 14% user 69% system 0% nice 14% idle 0% iowait 0% irq 3% softirq
CPU0 states: 15% user 65% system 0% nice 16% idle 0% iowait 1% irq 3% softirq
CPU1 states: 15% user 76% system 0% nice 5% idle 0% iowait 1% irq 3% softirq
CPU2 states: 9% user 80% system 0% nice 2% idle 0% iowait 2% irq 7% softirq
CPU3 states: 13% user 72% system 0% nice 11% idle 0% iowait 1% irq 3% softirq
CPU4 states: 10% user 79% system 0% nice 6% idle 0% iowait 1% irq 4% softirq
CPU5 states: 43% user 30% system 0% nice 23% idle 0% iowait 1% irq 3% softirq
CPU6 states: 21% user 37% system 0% nice 37% idle 0% iowait 1% irq 4% softirq
CPU7 states: 16% user 65% system 0% nice 14% idle 0% iowait 1% irq 4% softirq
CPU8 states: 8% user 83% system 0% nice 2% idle 0% iowait 2% irq 5% softirq
CPU9 states: 14% user 69% system 0% nice 13% idle 0% iowait 1% irq 3% softirq
CPU10 states: 16% user 70% system 0% nice 11% idle 0% iowait 0% irq 3% softirq
CPU11 states: 17% user 47% system 0% nice 33% idle 0% iowait 0% irq 3% softirq
CPU12 states: 11% user 73% system 0% nice 13% idle 0% iowait 0% irq 3% softirq
CPU13 states: 13% user 70% system 0% nice 14% idle 0% iowait 0% irq 3% softirq
CPU14 states: 24% user 29% system 0% nice 44% idle 0% iowait 0% irq 3% softirq
CPU15 states: 11% user 78% system 0% nice 8% idle 0% iowait 0% irq 3% softirq
CPU16 states: 8% user 84% system 0% nice 2% idle 0% iowait 1% irq 5% softirq
CPU17 states: 9% user 81% system 0% nice 7% idle 0% iowait 0% irq 3% softirq
CPU18 states: 10% user 72% system 0% nice 14% idle 0% iowait 0% irq 4% softirq
CPU19 states: 12% user 70% system 0% nice 15% idle 0% iowait 0% irq 3% softirq
CPU20 states: 13% user 75% system 0% nice 9% idle 0% iowait 0% irq 3% softirq
CPU21 states: 12% user 80% system 0% nice 5% idle 0% iowait 0% irq 3% softirq
CPU22 states: 12% user 69% system 0% nice 16% idle 0% iowait 0% irq 3% softirq
CPU23 states: 9% user 75% system 0% nice 13% idle 0% iowait 0% irq 3% softirq
CPU24 states: 9% user 82% system 0% nice 2% idle 0% iowait 1% irq 6% softirq
CPU25 states: 14% user 77% system 0% nice 6% idle 0% iowait 0% irq 3% softirq
CPU26 states: 10% user 69% system 0% nice 18% idle 0% iowait 0% irq 3% softirq
CPU27 states: 14% user 74% system 0% nice 9% idle 0% iowait 0% irq 3% softirq
CPU28 states: 15% user 58% system 0% nice 25% idle 0% iowait 0% irq 2% softirq
CPU29 states: 11% user 79% system 0% nice 6% idle 0% iowait 0% irq 4% softirq
CPU30 states: 11% user 64% system 0% nice 22% idle 0% iowait 0% irq 3% softirq
CPU31 states: 13% user 72% system 0% nice 12% idle 0% iowait 0% irq 3% softirq

  3. 继续使用 diagnose sys top 查看进程占用时，可以看到多个 scanunitd 实例分别运行在不同 CPU Core 上，并持续占用较高 CPU：

    # diagnose sys top 2 30

Run Time:  85 days, 21 hours and 26 minutes
13U, 0N, 50S, 34I, 0WA, 0HI, 3SI, 0ST; 48378T, 34803F
       scanunitd    31127      R <    92.5     0.1    8
       scanunitd    31143      R <    92.0     0.1    24
       scanunitd    31147      R <    92.0     0.0    1
       scanunitd    31125      R <    91.5     0.1    22
       scanunitd    31115      R <    91.0     0.1    10
       scanunitd    31140      R <    91.0     0.1    30
       scanunitd    31141      R <    91.0     0.0    2
       scanunitd    31142      R <    91.0     0.0    17
       scanunitd    31109      R <    90.5     0.1    16
       scanunitd    31124      R <    90.5     0.0    23
       scanunitd    31139      R <    90.5     0.0    13
       scanunitd    31137      R <    90.0     0.1    27
       scanunitd    31144      R <    90.0     0.0    14
       scanunitd    31091      R <    89.5     0.1    18
       scanunitd    31130      R <    89.5     0.1    28
       scanunitd    31118      R <    89.5     0.1    5
       scanunitd    31126      R <    89.0     0.1    3
       scanunitd    31134      R <    88.0     0.1    21
       scanunitd    31132      R <    65.6     0.1    6
       ipsengine    15464      R <    35.3     1.6    19

原因分析

在 scanunitd 调试日志中，可以看到被扫描的文件大量为 .cab 文件。Windows Update 传输过程中可能下载大量 .cab 文件，这类压缩文件需要进行解压和扫描，短时间内会增加反病毒扫描进程的 CPU 消耗。

[3368@4017728]process_scan_pending: query=1083806 file="41802753_60a65bb5768294044286332ab1a8c96c3128427a.cab" len=7217 action=PENDING
2024-08-26 11:04:52 su 27128 job 198   object_name '41802753_60a65bb5768294044286332ab1a8c96c3128427a.cab'
2024-08-26 11:04:52 2024-08-26 11:04:52 su 27128 job 198 scan file '41802753_60a65bb5768294044286332ab1a8c96c3128427a.cab' bytes 7217
832722_8d5ee795d5a6a4369a25ebe64e5dc55974ce13bc.cab
802747_44158d850999b894626b3b5b84be90a434a07016.cab
[3368@4017728]process_scan_pending: query=1083808 file="41802747_44158d850999b894626b3b5b84be90a434a07016.cab" len=7195 action=PENDING
2024-08-26 11:04:52 su 27056 job 1005   object_name '41802747_44158d850999b894626b3b5b84be90a434a07016.cab'
2024-08-26 11:04:52 2024-08-26 11:04:52 su 27056 job 1005 scan file '41802747_44158d850999b894626b3b5b84be90a434a07016.cab' bytes 7195
2024-08-26 11:04:52 su 27072 job 703   object_name '41832722_8d5ee795d5a6a4369a25ebe64e5dc55974ce13bc.cab'
2024-08-26 11:04:52 su 27072 job 703 scan file '41832722_8d5ee795d5a6a4369a25ebe64e5dc55974ce13bc.cab' bytes 7233

临时规避方法

建议按以下顺序评估临时规避方案：

  1. 优先对可信 Windows Update URL 仅豁免 AV 扫描，尽量避免扩大豁免范围。
  2. 如果环境中可以通过 ISDB 稳定识别 Windows Update 相关流量，可为可信更新 ISDB 单独建立策略。
  3. 如果前两种方式无法及时实施，可临时关闭匹配策略上的 AV 配置文件，并在问题缓解后恢复。

方法 1：对可信 Windows Update URL 仅豁免 AV 扫描

  1. 根据 Web 过滤日志或流量日志确认 Windows Update 实际访问的下载 URL。

  2. 在 Web 过滤配置文件中配置本地 URL 过滤器，使用通配符条目匹配可信更新站点，并将 action 设置为 exempt，同时在 CLI 中只豁免 av。

    重要

    仅对确认可信的更新站点使用豁免。不要为了规避 CPU 高而对过宽泛的域名或所有 .cab 文件直接豁免 AV 扫描。

    示例配置如下，实际 URL 需要根据环境中的 Windows Update 访问日志确认：

    config webfilter urlfilter
    edit 10
        set name "win_update_av_exempt"
        config entries
            edit 1
                set url "*.windowsupdate.com"
                set type wildcard
                set action exempt
                set exempt av
            next
            edit 2
                set url "*.update.microsoft.com"
                set type wildcard
                set action exempt
                set exempt av
            next
        end
    next
end

  3. 将该 URL 过滤器引用到 Web 过滤配置文件：

    config webfilter profile
    edit "win_update_webfilter"
        config web
            set urlfilter-table 10
        end
    next
end

  4. 在处理客户端上网的防火墙策略中引用该 Web 过滤配置文件，并保留必要的日志记录，用于确认命中范围是否符合预期。

方法 2：为可信更新 ISDB 单独建立策略

  1. 通过 GUI 的“策略 & 对象 → Internet 服务数据库”页面或 diagnose internet-service 命令确认实际命中的 Microsoft/Windows Update 相关 ISDB 条目。

    提示

    ISDB 条目的名称和内容会随 FortiGuard 数据库更新而变化。配置前建议确认当前设备中实际存在且可以稳定命中的 ISDB 条目。

  2. 在通用上网策略之前新增一条更精确的防火墙策略，目标选择可信的 Microsoft/Windows Update 相关 ISDB 对象，并在该策略上不引用 AV 配置文件。

    示例配置如下，<trusted_update_isdb> 需要替换为当前设备中确认可靠的更新相关 ISDB 对象：

    config firewall policy
    edit <id>
        set name "Windows_Update_without_AV_scan"
        set srcintf "<lan>"
        set dstintf "<wan>"
        set srcaddr "<trusted_clients>"
        set internet-service enable
        set internet-service-name "<trusted_update_isdb>"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
end

  3. 确认该策略位于通用上网策略之前，避免 Windows Update 流量继续命中原有启用了 AV 的策略。

  4. 如果是在已有策略上临时调整，可仅对命中 Windows Update 的专用策略取消 AV 配置文件：

    config firewall policy
    edit <id>
        unset av-profile
    next
end

  5. 观察流量日志和 CPU 使用率，确认只有可信更新流量命中该策略，且 scanunitd CPU 占用下降。

方法 3：临时关闭匹配策略上的 AV 配置文件

  1. 确认前两种方法无法及时实施，且业务需要优先恢复 Windows Update 下载。

  2. 临时关闭相关防火墙策略上的 AV 配置文件。

  3. 尽量收窄该策略的源地址、目的范围和生效时间，并保留流量日志。

  4. 待 FortiOS 升级、规则优化或官方修复确认后，恢复 AV 扫描。

重要

此方法会降低该策略匹配流量的安全检测能力，仅建议作为短期应急措施。

收集诊断信息

如果需要向 Fortinet TAC 提交 case，建议在问题发生时先收集以下信息。

  1. 收集基础系统信息：

    execute tac report
diagnose sys mpstat 2
get system performance status
diagnose hardware sysinfo slab
diagnose sys top 2 99
diagnose hardware sysinfo interrupts
diagnose hardware sysinfo cpu
diagnose sys session stat

    diagnose sys top 2 99 建议连续运行 15 秒左右，可多次采集，按 q 退出。

  2. 开启 scanunitd 调试信息：

    diagnose sys scanunit debug all
diagnose debug enable

  3. 等待 2-3 分钟后停止调试：

    diagnose debug disable
diagnose sys scanunit debug reset
diagnose sys scanunit crash-dump read

  4. 开启 CPU Profiling 信息：

    diagnose sys profile cpumask <cpu_id>
diagnose sys profile start

  5. 等待 2-3 分钟后停止并查看结果：

    diagnose sys profile stop
diagnose sys profile show order
diagnose sys profile show detail

  6. 如果多个 CPU Core 同时升高，可以一次指定多个 CPU ID：

    diagnose sys profile cpumask 0 13 18

  7. 如果 diagnose sys top 中同时看到 ipsengine 异常，也可以找到对应 PID 后收集进程信息：

    diagnose sys process trace <PID>
diagnose sys process dump <PID>
diagnose sys process pstack <PID>
diagnose sys process sock-mem <PID>

  8. 同时导出 FortiGate 配置文件，连同以上诊断输出一并提交给 Fortinet TAC。

最近更新: