主机上跑病毒扫描，为什么业务会跟着变慢：签名库、实时扫描和排期这笔账

一台跑着业务的机器上装了恶意文件扫描组件，监控面板上 CPU 使用率并不算高，内存余量看着也还宽裕，但只要业务开始批量接收上传文件，或者后台开始往磁盘落大块数据，接口响应时间就往上抬一截。把扫描组件停掉，延迟立刻回落。这类现象很容易被一句话归因为杀毒太重，但顺着资源路径往下拆会发现，真正被抢走的往往不是算力，而是业务与扫描共用的那条 IO 路径。

主机上的扫描从来不是单一动作。它至少由四件资源特征完全不同的事情叠加而成：一份常驻在内存里的签名与索引结构，一套挂在文件访问路径上的同步钩子，一个周期性启动的全盘遍历任务，以及一层需要采样与判定的行为与启发式逻辑。这四者对 CPU、内存、磁盘 IO 与页缓存的索取方式各不相同，混在一起看，只能得到装了就慢这种无法指导配置的结论；拆开看，每一件都有对应的调整手段，也都有对应的代价。

本文只讨论恶意文件扫描引擎在主机上的资源账：常驻开销从哪里来、实时扫描凭什么和业务抢同一条路、全盘扫描的窗口排在什么时候、排除规则为什么是双刃的、集中式形态把开销挪到了哪里、命中之后按什么顺序处置。主机行为审计与日志规则告警那一类机制的展开不在本文范围内，它们的资源模型属于另一个话题。

扫描这件事在主机上分成哪几种动作

把扫描当成一个整体去谈性能，是配置工作里最典型的起点错误。主机侧扫描通常包含四类动作，它们的资源画像差异极大。

第一类是特征与签名库常驻。引擎启动后要把特征数据、索引与缓存结构装载到内存里，这部分是固定成本，与业务忙不忙基本无关。只要进程在，账就在。

第二类是可按需触发的全盘扫描。它是一段时间内集中消耗的脉冲式任务，同时吃 CPU 与磁盘 IO，特点是可控——完全可以决定它什么时候跑、跑多快、跑多少。

第三类是实时扫描，也叫 on-access 扫描。它常开，且挂在文件访问路径上，只要有打开与读写动作就触发判断。它的单笔开销未必大，但触发频率与业务的 IO 频率完全同频，因此对延迟最敏感。

第四类是行为与启发式检测。它需要在一段时间内收集行为样本再做判定，意味着除了即时的 CPU 与内存，还要维护状态数据与判定上下文，在进程密集、短生命周期进程频繁的环境里，这部分的状态维护开销会变得明显。

四类动作叠加在业务机上，产生的问题往往不是总和超标，而是峰值错位。业务高峰时实时扫描跟着高峰一起被放大，全盘扫描恰好也排在同一时段，两笔开销叠在一起，业务侧感受到的就是延迟整体抬升而不是某一项资源打满。这也是为什么单纯看 CPU 与内存的均值曲线，经常什么异常都看不出来。

这里谈的是主机上常驻运行的文件扫描引擎给这台机器带来的资源占用，流水线里的镜像扫描门禁属于另一类问题，不在本文讨论范围。

签名库常驻内存是固定成本，规模决定下限

签名库的规模决定常驻内存占用，这一点没有太多腾挪空间；引擎通常还要在这份数据之上维护缓存与索引结构，用来加速匹配，这些附属结构同样占用内存。也就是说，扫描组件留给你的内存账由两部分构成：特征数据本身，以及引擎为了查得快而额外建立的结构。前者随库规模变化，后者与引擎实现和并发配置相关。

这份固定成本有两个容易被忽略的乘法因子。第一个因子是机器数量。每台机器都独享一份驻留数据，副本数等于开着的机器数。集群规模上去之后，单机的几百兆会变成集群层面一笔可观的内存总量，在容器密度高、单机内存本就紧张的环境里，它直接压缩了业务可用的页面缓存空间，间接把业务 IO 推向磁盘。

第二个因子是更新动作本身。签名库需要持续更新，更新不是简单地覆盖几个字节，它涉及下载、校验、落盘、加载与索引重建。加载新版本的过程中往往存在新旧两版共存的瞬时窗口，内存峰值高于稳态值。如果一批机器在相同时间点触发更新，还会叠加出一次集中的网络下载与磁盘写入脉冲。更新失败后的回滚、版本不兼容时的降级，也都属于这条账上的支出。因此签名库更新同样需要错峰与分批，而不是随缘地由每台机器自行决定时机。

从选型角度看，内存是这份成本里最硬的一项。它不随 CPU 变强而变小，也不随磁盘变快而变小。在给业务机定内存规格时，把扫描组件的常驻占用当作预留项直接减掉，比事后发现页缓存被挤压再回头调，代价要小得多。

签名库的存放与分发同样要算一笔账。每台机器各自从外部拉取更新，会在出口带宽上形成周期性脉冲，机器数量越多越明显；更稳妥的做法是在内网放置一份分发源或离线更新包，让更新流量留在内部，同时也便于控制版本节奏。对采用只读根文件系统或镜像层只读的部署方式，签名库与缓存结构需要有可写的独立存放位置，否则更新会在重启后被丢弃，机器每次启动都要重新装载一份，白白付出一次加载开销。测试环境与生产环境使用不同版本的库，也是排查时容易误导人的一处差异，判定的可比性会因此下降。

实时扫描为什么和业务的 IO 抢同一条路

实时扫描依赖内核提供的文件访问钩子，Linux 侧常见的是 fanotify 一类机制。这类机制的工作方式是在文件被打开与读写的路径上插入判断，关键之处在于：这个判断通常是同步的。同步意味着业务进程发起的那次文件访问，要等扫描判定完成才能继续往下走，等待时间被直接计入业务请求的处理时间。它不是后台悄悄做的一件事，而是插在业务关键路径上的一段等待。

这解释了开篇那个现象。CPU 使用率不高，是因为判定动作本身的计算量确实不大；但延迟抬升了，因为每一次访问都被加上了一段不可省略的等待。业务每秒发起多少次文件访问，这等待就被收多少次。

影响程度与业务的 IO 形态强相关，大致有两种极端。其一是大量小文件场景。钩子触发次数与文件数量成正比，单次开销被文件数量放大。代码仓库拉取、依赖包解压、模板目录加载、日志按行切分这类动作，都可能在极短时间内产生海量打开操作，此时开销的主体不是数据量，而是访问次数。

其二是大文件连续读写场景。单个大文件在被处理的过程中，内容会被分段提交检查，扫描读取与业务读取交错进行，磁盘的寻道与队列被两种来源的请求共同占用，顺序读的有效吞吐因此被稀释。数据库数据文件、视频与镜像文件、备份归档的落盘与回读都属于这一类。

还有一个经常被归错因的后果：页缓存污染。扫描会把大量业务平时不访问的冷数据读进页缓存，把业务依赖的热数据挤出去。业务随后再访问自己的热数据时，命中率下降，请求落到物理磁盘上，延迟成倍上升。表面看是磁盘变慢，实质是缓存被别人借走了。这种影响具有滞后性，扫描任务结束后还会持续一段时间，排查时很容易与扫描动作本身错开，从而被误判为存储性能抖动。

另外几个需要提前确认的交互点：内存映射方式访问的文件与实时扫描的配合行为，需要按实际引擎实现确认；网络文件系统与挂载点上的实时扫描，会把网络往返叠加到原本已经同步的判定等待里；容器环境中宿主机与容器内的扫描同时开启，可能造成同一份数据被两条路径各扫一遍，开销直接翻倍。这几处都需要在实际部署前确认清楚，而不是默认它是安全的。

全盘扫描的窗口怎么排才不撞业务高峰

全盘扫描是 IO 与 CPU 双密集任务，需要错峰、限速与分批。这三件事听起来基础，真正难的是排期依据——很多环境的扫描窗口是随手设的，设完就再没人复核，直到业务形态变了才暴露问题。

先说错峰的依据。排期不能只盯着本机的业务日内曲线，至少要把这些时间因素叠在一起来看：业务的日高峰与周末低谷、批处理与报表任务的运行时段、备份与快照的窗口、日志轮转与压缩的时间点、主备切换与演练安排、以及上游或下游系统对这台机器的调用节律。真正的低谷是这些曲线共同的低谷，而不是其中某一条的低点。

再说限速。限速手段通常包括 IO 上限、CPU 上限与并发线程数三类，三者应当同时设定而不是只设一项。只限 CPU 不限 IO，磁盘依然会被打满；只限 IO 不限线程，调度与上下文切换的压力仍在。限速值要给业务留出余量，而不是按业务低谷的平均水位去贴边设定——低谷里也会有突发任务，贴边配置在突发时就会翻车。

分批是把单次冲击拆小的直接办法。可以按目录分批、按卷分批、按主机分批，一批跑完再启动下一批，并限制同时执行全盘扫描的主机数量。分批还带来一个附加好处：任何一批出现问题时，影响范围可控，回滚也只需要回到上一批的边界。

起始时间要随机化。如果一批机器用同一个排期表达式，它们会在同一秒一起启动，形成一次集中的 IO 与网络冲击，这在上百台机器的环境里尤其明显。给起始时间加上分散量，是成本极低却经常被漏掉的一项配置。

与备份、快照、压缩类任务互斥是另一条硬规则。这几类任务都在争同一块磁盘带宽，同时进行的结果是两边都变慢，且备份窗口被拉长，连锁影响次日的业务。把扫描与备份在排期层面明确错开，比事后靠限速去调停要可靠得多。

排期还要避开两类容易被漏掉的窗口。第一类是变更与发布窗口：发布过程中会有大量文件写入、解压与替换动作，如果全盘扫描恰好在这时候跑，两件事叠加的结果是发布变慢、扫描也跑不完，且这段时间的文件状态本就在变化中，扫描结果的参考价值也打折扣。第二类是监控与告警的联动：扫描期间的 CPU、IO 等待与延迟指标自然会偏离常态，如果告警阈值按常态设定，扫描一启动就会刷出一屏告警，长期下来会让人对告警脱敏。合理做法是把已知的扫描窗口与告警抑制或阈值调整关联起来，让异常仍然可见，但不至于淹没在预期内的噪声里。

还需要考虑两个环境特有的约束。一是虚拟化与云盘场景：多台虚机的磁盘 IO 最终叠加到同一套底层存储上，各虚机各自错峰并不等于底层错峰，宿主机或存储层面的排期同样要对齐。二是任务的时限：给全盘扫描设置最长运行时间与收敛策略，超时后自动降级或中断，避免一次意外拉长的扫描跨进业务高峰——扫描任务最怕的不是慢，而是没有边界。

排除规则既是性能手段也是风险敞口

排除规则可以按路径、按进程、按扩展名来设定，能显著降低开销，但同时会缩小检测面，需要成对记录与复核。这句话的每个部分都重要：它既是性能手段，也是风险敞口，而且这两个身份永远同时成立。

理解排除规则的本质，可以把它看成用信任换性能。你把某个路径排除掉，等价于声明我信任这个路径下不会产生需要被处理的文件，于是引擎不再为它付出开销。既然是信任声明，它就必须有理由、有责任人、有复核日期，否则时间一长，排除列表会变成一份没人敢动也没人看得懂的遗留配置。

通常具备排除理由的目录有这些：数据库的数据文件与事务日志目录——它们由数据库自身以专有格式管理，且数据库对这些文件已有自己的完整性保障机制，重复扫描的收益与开销不成比例；体积巨大且内容固定的静态资源目录；日志滚动产生的历史归档目录；明确为临时产物的临时目录。这些排除之所以成立，是因为它们有清晰的结构性理由，不是因为它们大。

反过来，有几类目录即使开销明显也不应轻易排除：Web 可写目录与用户上传目录——这是外部内容进入主机的第一站；脚本与可执行程序目录；计划任务与自动启动相关的目录；容器镜像解压层与挂载进容器的宿主目录；以及任何内容由外部输入决定的目录。这些位置的共同特征是：内容来源不受你完全控制。

排除的粒度也值得单独讨论。按路径排除最常见，边界清晰，可审核性最好；按进程排除依赖于进程身份的真实性与稳定性，一旦判定依据可以被同名进程冒用，这条规则就失去了意义；按扩展名排除最省事，也最粗放，它只看名字不看内容，等于把整类文件一次性排除在外，除了极少数用途单一的目录外都不建议使用。粒度越粗，省下的开销越多，同时缩小检测面的幅度也越大，这两件事永远同向。

治理上建议做成配对记录：每一条排除规则对应一条理由、一位申请人、一个复核周期，并且排除规则与包含规则同时命中时的优先级要在文档里写清楚——不同引擎的处理顺序并不一致，凭默认值去假设是常见的踩坑点。还有一条经常被忽略的联动：业务改了目录结构、迁移了数据位置、换了部署方式之后，旧的排除规则可能指向已经不存在的路径，而新的敏感路径可能尚未纳入规则，这类漂移应当在变更流程里被明确检查。测试环境与生产环境的排除规则如果不一致，也要单独标注，否则在测试环境验证过的配置搬到生产环境后，行为可能并不相同。

集中式扫描服务与每台自扫的结构差别

集中式形态是由专用扫描节点通过挂载或代理的方式去扫描目标，把开销从业务机上移走。这个动作换来的是业务机资源账的大幅简化，代价是要解决文件访问链路与权限这两件在单机自扫时根本不存在的问题。

先看自扫形态的特点。每台机器自己装载签名库、自己挂钩子、自己跑全盘扫描。它的优点是逻辑直观、权限天然具备、不依赖任何外部服务；缺点是常驻成本按机器数量线性复制，策略与版本容易出现漂移——几台机器没跟上更新，排查时往往要花很久才发现。

再看集中式形态要解决什么。第一是访问链路：扫描节点要读目标机上的文件，就得有一条稳定、带宽足够、可重试的读取路径。这条路径上的延迟与抖动会直接影响扫描速度，断连后的续扫与去重也需要设计。第二是权限：扫描节点拿到的凭据必须遵循最小权限原则，且挂载应当尽量以只读方式进行，避免扫描过程意外改动目标数据。第三是覆盖范围：加密卷、只在进程内可见的数据、网络存储上的权限边界，都可能成为集中式扫描够不到的盲区，这些盲区要被显式记录而不是默认覆盖。

介于两者之间的是代理形态。业务机上只保留一个极轻的代理，负责读取与传输，判定动作放在中心节点完成。业务机上不再需要完整的签名库常驻，也不再需要承担匹配计算，但仍需承担少量读取与网络传输开销。这种形态的资源账介于两者之间，也更适合那些既想卸掉常驻成本、又无法把磁盘直接暴露给外部节点的场景。

一致性是集中式的另一个收益：策略、签名库版本与排除规则在一处维护，会出现版本漂移的是少数。但它同时引入了新的故障域——中心节点不可用时，受影响的是整个面的扫描能力，而不是某一台机器。因此中心节点本身需要做冗余与容量规划，这件事经常被遗漏：大家算清了业务机上省下的内存，却忘了给中心节点留出足够的内存与 IO。中心的规模取决于它需要覆盖的文件总量与要求的覆盖周期，这两项决定了它在常态下的负载水位，而不是按当前机器数量拍一个值。

还有一层是网络与安全域。集中式扫描意味着文件内容或文件数据会被读取并传输到另一台节点，这条链路要不要跨安全域、是否应当走独立的管理网络、传输过程是否需要额外加密、扫描结果集中存放后由谁可见，这些都需要在设计阶段就确定。集中存放同时也带来了集中风险：一份包含全量扫描结果的存储，本身就需要按敏感数据来对待，设定访问范围与保留期限。把这些想清楚之后，集中式形态在资源账上的优势才不会被新的管理与合规成本抵消掉。

三种部署形态的资源账

把前面几节的内容落到选型上，可以在三种部署形态之间做比较。它们的差别不在能力强弱，而在开销落在谁的账上。

这张表的一个用法是：先按业务对访问时延的敏感程度在第一行与第二行之间做选择，再按机器规模与单机内存余量判断是否要走向第三行。三种形态并不是替代关系，很多环境会长期混合存在——数据库与存储节点走第二种形态，普通应用节点走第一种，再由集中式节点对整体做周期性覆盖。

命中之后怎么办：隔离、留证与恢复顺序

扫描命中之后的处置顺序，和扫描本身的配置一样需要提前定好。推荐的顺序是：先隔离或阻断访问，再保留样本与日志，最后才做清除与恢复；不要先删文件导致证据丢失。这条顺序存在的理由很直接——文件一旦被删除，后续要回答的问题就全都答不出来了。

第一步是隔离或阻断。目标是让这个文件暂时无法被执行或访问，而不是让它消失。隔离的做法包括移动到受控区域、置为不可执行、阻断相关进程对该路径的访问。这一步要考虑业务连续性：在集群环境里，隔离动作可能需要先在负载均衡层面摘除相关实例，再在主机层面处理，避免隔离动作本身造成业务中断。

第二步是留证。需要保留的内容至少包括：样本副本、原始路径、发现时间与相关时间戳、文件哈希、当时的进程上下文、以及扫描引擎与其签名库的版本信息。最后两项尤其容易被漏掉——没有引擎与库版本，事后既无法判断这次判定依据的是什么，也无法复现当时的判定结果。留证数据本身也要有存放位置与保留期限的规定，并且要保证它在后续操作里不会被一起清理掉。

第三步才是清除与恢复。清除之后要做的是恢复，而不是直接宣告完成：确认可用备份的时间点早于问题出现的时点，从干净备份恢复需要恢复的内容，恢复完成后重新扫描确认，并对与该主机相关的凭据做一次审视。这一步的节奏通常比前两步慢，但它是真正让业务回到正常状态的部分。

权限与自动化边界也需要划清。谁有权执行清除动作、哪些动作可以自动执行、哪些必须人工确认，应当在执行前就定义好。完全自动化的风险是误伤业务文件后无从追溯；完全人工的风险是告警堆积、扫到了却没人处理。比较务实的划分是：隔离与留证可以自动执行，清除与恢复保留人工确认环节，并对每一条告警建立明确的责任归属，避免告警发出后落进无人认领的状态。

关于主机扫描，运维最常被问的几件事

装上之后业务变慢，第一步该看什么？先分清慢在哪个动作上。把实时扫描临时关掉观察一段时间，如果延迟回落，问题在访问路径上的同步判定；如果不变，问题大概率在全盘扫描的排期或页缓存污染上。不要一上来就调线程数，那是把两类问题混在一起处理。

能不能只在业务低峰打开实时扫描？技术上可行，但要清楚这意味着高峰时段写入的文件不会在写入那一刻被检查，需要靠后续的全盘扫描补上覆盖。这是一个覆盖时机的取舍，不是免费的优化，做之前应当把补扫的排期一起定下来。

容器里要不要单独装扫描组件？要看宿主机上是否已经有一套在跑。如果宿主机与容器内各跑一套，同一份数据可能被两条路径各扫一遍，常驻内存与 IO 开销都翻倍。更常见的做法是宿主机或节点层面统一处理，容器内以只读根文件系统与最小化镜像来配合，具体形态需按实际的运行时与存储方式确认。

扫描和备份能不能同时跑？不建议。两者争的是同一块磁盘带宽，同时跑的结果是备份窗口被拉长、扫描也变慢，还可能双双跨进业务高峰。在排期层面把它们错开，比靠限速去调停更稳。

签名库更新需要单独排期吗？需要。更新涉及下载、校验、加载与索引重建，加载过程存在内存峰值，批量机器同时更新还会形成网络与磁盘脉冲。更新窗口应当与全盘扫描窗口、备份窗口一并纳入同一张排期表。

排除规则多久复核一次？建议绑定在业务变更流程上，而不是只设一个固定周期。目录结构调整、部署方式变化、数据位置迁移，这三类变更发生时都应当触发一次排除规则的检查；固定周期复核作为兜底，用来发现那些没有被变更流程覆盖到的漂移。

什么时候应该把扫描职责移出业务机

把扫描职责从业务机上移走，不是因为它更先进，而是因为某些条件下业务机已经负担不起这笔账。可以观察几条判断线：业务机内存紧张到页缓存被挤压、实时扫描的同步开销已经能在业务延迟曲线上被看到、机器数量大到常驻内存的总量失控、业务本身是 IO 密集型数据库或存储服务、以及宿主机上运行着大量高度同质的虚机。出现其中任意一条，把匹配计算挪出去就值得认真评估。

移出之后仍要保留两样东西：最小的执行态感知能力，用来知道这台机器上发生了什么；以及命中之后的处置通道，用来保证隔离、留证与恢复的顺序依然能被执行。扫描职责移走了，处置责任没有移走，这一点在架构调整时最容易被误解。

推进上建议分三段走，而不是一次性切换：先把实时扫描关掉，只保留排期全盘扫描与按需扫描，观察业务延迟与 IO 指标的变化，确认影响确实来自访问路径上的同步判定；再引入集中式或代理式扫描，先覆盖一部分机器，验证访问链路、权限与断连重试的行为符合预期；最后回头收敛排除规则，因为架构变了，原来的排除理由未必还成立，新的读取路径也可能带来新的盲区。三段之间留出观察期，比一次性改造更容易定位问题。

主机侧的扫描从来不是装完就结束的事。签名库会变大，业务目录会重构，机器数量会变化，这些都会让当初合理的配置逐渐偏离。把常驻、实时、排期、排除与集中式这五笔账分开记，各自设定复核时机，才能在业务变慢的时候快速定位到是其中哪一笔出了问题，而不是笼统地在加内存与关功能之间来回试。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源；主机安全类组件能不能装、装哪一层，建议按自身合规要求与服务商逐项确认。主机安全类组件的部署方式与机型选择以官网实时信息或咨询确认为准。