每到月末最后两天系统就卡：批量作业和在线业务该怎么分资源

CPU 不高、内存有富余，月末下午为什么还是卡

每个月最后两天的下午，客服群里开始有人反馈"提交不了"，后台订单列表要点七八秒才返回，支付回调偶尔超时。运维把监控面板调出来：CPU 平均使用率不到六成，内存还剩三分之一，磁盘空间充足，出口带宽没跑满。上一次闹过一轮之后，团队把这台机器的核数和内存各加了一档，两个月下来，月末下午的卡顿从"完全点不动"变成了"慢但能忍"，问题并没有消失。

真正的变量不在配置清单里，而在那半天跑着什么。月末最后两天通常同时堆着对账、出账、账单生成、月结重算、报表导出、已完结订单归档这一批任务，它们有一个共同的名字——批量作业。这些作业的特点是把能拿到的资源全部占满：有多少 CPU 用多少，有多少 IOPS 用多少，能开多少连接开多少。在线请求恰恰是在这段时间内对延迟最敏感的那部分负载。

所以看资源监控的平均值得出的结论往往是错的。CPU 平均六成，不等于在线请求没有在排队；内存有富余，不等于排序没有挤掉缓存；磁盘没写满，不等于临时目录没被中间结果占满。周期性卡顿要盯着的是等待发生在哪里，而不是资源的平均余量还剩多少。

在线要低延迟、批量要吞吐：两类负载的目标函数天生冲突

在线请求和批量作业评价"好不好"的标准完全不同。一个下单接口的目标是把响应时间压在一两百毫秒，并且更重要的是让尾延迟稳定——哪怕只有百分之一的请求慢到三秒，用户感知到的也是"系统卡了"。它容忍不了排队，请求来了就希望立刻拿到 CPU、立刻拿到连接、立刻返回结果。

批量作业的目标是吞吐和在窗口内跑完。它不关心单次操作快不快，关心的是八千万行数据能不能在早上六点前处理完。为了做到这一点，它会把并发开到上限、一次扫描全表、一个事务包下几十万行更新。从资源使用视角看，批量的理想状态是"零空闲"：CPU 打满、磁盘队列排满、连接池占满，这才说明没浪费。

两种目标放在同一份资源上时，冲突是结构性的，不是配置不够造成的。在线请求要的是"随时有余量"，批量作业要的是"余量为零"。只要两者共享同一个 CPU 池、同一块磁盘、同一个连接池、同一个缓冲池，任何一方按自己的最优方式运行，就会损害另一方。这也是为什么"加配置"这类横向补救在月末场景下收益递减——它没有改变两个负载共享资源这件事本身。

顺带说清楚一个常见误解：批量作业本身没有错。月末集中处理账单、对账、结算是业务的自然节奏，问题出在没有给这些作业划出边界。有边界的批量可以跑得很凶，无边界的批量才会在最后一个工作日的下午顶掉在线。

第一个争抢位置：CPU 与在线请求的排队时间

CPU 的争抢方式与大多数人想象的不一样。在线请求不会"拿到一半核"，它要么被调度执行，要么在就绪队列里等着。批量作业把核占满时，平均使用率可能才七成，但就绪队列里同时排着几十个在线请求——这些请求的等待时间会直接加到响应时间上，而这段时间在 CPU 使用率图上完全看不出来。

月末下午的典型形态是：一个批量重算任务起了一批并行 worker，每个 worker 都是计算密集型，核数被占满；在线请求进入运行队列，等待被调度。用户看到的是"页面一直在转"，监控看到的是 CPU 七成、负载很高但均值一般。判断这一类问题要看的是运行队列长度和调度延迟，不是 CPU 使用百分比。

这里还有一层连带影响：并行批量会让上下文切换变多、CPU 缓存命中率下降。即使在线请求最终抢到了时间片，它在这颗核上的执行效率也比平时低，因为它要重新预热缓存。这就是为什么月末卡顿往往表现为"整体变钝"，而不是某一个接口单独慢。

第二个争抢位置：磁盘 I/O、临时表与临时空间写满的连带影响

磁盘是月末批量最容易出事的位置，因为它同时消耗三样东西：IOPS、带宽和临时空间。大表扫描吃掉的是顺序读带宽；随机更新和大范围删除吃掉的是随机 IOPS；而排序、分组、去重、哈希连接产生的中间结果，一旦内存里放不下，就要落盘到临时表空间。

磁盘争抢的隐蔽之处在于它是"队列型"资源。CPU 抢不到会排队，但排的是毫秒级；磁盘队列一旦堆起来，一次在线查询原本两毫秒的索引查找可能要等几百毫秒。表现在页面上就是"列表页突然要三秒"，而这段时间 CPU 可能正闲着等 I/O——这正是 I/O 等待型卡顿的典型特征：设备利用率接近饱和，CPU 却在等。

更麻烦的是临时空间。很多团队以为临时目录写满只会让那一个批量任务失败，实际影响常常波及整个实例：临时空间耗尽之后，连在线的简单查询如果也需要落盘排序，同样会报错或直接终止连接。也就是说，一个跑偏的月末大排序，可以把本来健康的在线查询一起拖下水。因此临时空间必须有明确上限，并且这个上限要作为批量作业的资源配额之一，而不是让作业跑到写满为止。

还有一个容易被忽略的点：批量清理类作业会产生大量随机写和删除，导致存储层的写放大和碎片上升。月末跑完之后，系统进入次月初也未必立刻恢复，因为垃圾回收、合并、重建这类后台动作会继续占用 I/O 一段时间。这解释了为什么有些系统"月末卡两天，月初第一天还是不太对劲"。

第三个争抢位置：连接与连接池耗尽时表现为超时而不是慢

连接争抢是最容易误判的一类。在线服务通常通过连接池访问数据库，池大小是固定的，比如每个应用实例二十条连接。批量作业如果开了几十上百个并发，每个并发各占一条连接，连接池很快就会被批量侧的连接占满，在线请求拿不到连接。

这时在线侧的表现不是"慢"，而是"超时"或"获取连接失败"。因为等待连接的时间通常有上限，超过就会直接抛错；即使没有设上限，请求也会堆积在应用层，把线程池一起堵住，最后变成整条链路不可用。用户侧看到的现象往往是"有的请求很快，有的直接报错"，而不是均匀变慢——这与 CPU 争抢的表现完全不同，可以作为区分线索之一。

批量占用连接还有两个衍生问题。其一是批量连接常常长时间持有而不做复用，进一步压缩可用连接数；其二是批量连接的会话状态（临时表、会话变量、预处理语句）会占用数据库内存，累积起来又回到内存争抢上。因此连接数必须作为批量的显式配额来管理，而不是让它按需扩张。

第四个争抢位置：长事务持锁，阻塞在线写入并拉大从库回放延迟

月末批量里最常见的写法是把几十万行更新包在一个大事务里，最后统一提交。这种做法在"原子性"上看起来稳妥，代价是持锁时间从毫秒级变成分钟级甚至小时级。在这个窗口里，任何要修改相同数据行的在线请求都会被阻塞。

锁争抢的表现与前几种都不同：请求不是排队等 CPU，也不是等待 I/O 完成，而是处于"等待锁释放"的状态。它需要的时间完全取决于那个大事务什么时候提交，因此表现为"某几类操作完全卡死，其它操作完全正常"——订单还能看，就是提交不了；列表还能翻，就是改不了状态。这种选择性失灵是判断锁问题的强信号。

长事务的第二重影响在从库。主库上的大事务会产生巨大的事务日志，从库回放时往往需要单线程或有限并发地追这一段。主库三十分钟完成的大批量，从库可能要追更久，期间只读副本上的数据是明显滞后的。如果报表、导出、用户查询都依赖同一个只读副本，滞后期内看到的"昨天的数据"会让业务侧误判。

还有一个次生风险：长事务会让数据库的回滚段、撤销空间持续膨胀，并阻碍旧版本数据的清理，进而拖慢依赖多版本读的在线查询。也就是说，一个本意是一次性月结的大事务，会在结束后一段时间内继续影响系统。

第五个争抢位置：内存与排序区被挤占，平时很快的查询变慢

数据库和搜索引擎的性能高度依赖缓存命中。在线查询平时很快，不是因为磁盘快，而是因为热点数据已经在缓冲池里。月末批量一来，全表扫描和大排序会把大量冷数据读入内存，把热点页面挤出缓冲池。

结果是典型的"缓存冲刷"：平时两毫秒的查询突然要几十毫秒甚至上百毫秒，因为它现在真的要去读磁盘。这解释了为什么内存总量看起来还有富余——富余的是未被用于缓存的部分，而真正关键的缓冲池已经被批量作业污染掉了。

排序区是另一处明确争抢。如果批量作业使用很大的排序缓冲区，而系统允许按会话动态分配，那么多个并发批量会话叠加起来会把内存和交换空间一起吃掉。一旦发生换页，整个实例的响应速度会断崖式下跌，恢复也需要时间。

因此内存问题不能只看"还剩多少"，要看"被谁占了、占的是哪部分"。批量作业应当在配额里明确它的可用内存上限和排序区大小，避免它自由扩张去挤占在线的缓存份额。

第六个争抢位置：网络与上游接口配额，批量触发限流连累在线

月末批量往往不只是本机的事。对账要调用第三方支付接口，出账要推送账单向消息队列，结算要拉取外部汇率或物流状态。这些调用通常共享同一条出口链路、同一个令牌桶配额、同一个外部账号。

外部接口的限流是按调用方整体计算的。批量作业在几分钟内打完几千次调用，很容易把配额打满，随后的在线调用就会拿到限流响应。在线侧看到的现象是"提交订单时第三方校验失败"，但根因在批量侧。这类问题最难排查，因为出错的地方在你无法观测的那一端。

解决思路不是给在线和批量各开一条线路，而是给批量侧的外部调用单独设速率配额和时间窗口，并保证在线调用有保底份额。是否需要独立的出口地址或独立的接口账号，取决于上游限流是按地址还是按账号计算，这一点需要向上游确认，不能凭猜测配置。

为什么加 CPU 加内存常常无效，甚至比之前更糟

理解这一点是本文的核心。在没有资源配额的前提下，批量作业会自动吃满一切可用资源。你给它更多核，它的并行 worker 就会开更多；你给它更快的磁盘，它就会在更短时间内产生更大的 I/O 压力；你给它更大的内存，它的排序就会放得下更多数据，从而选择更激进的执行计划。

换句话说，加配置改变的是批量作业的完成时间，而不是它对在线业务的冲击强度。八核共享时批量要跑四小时，在线每小时被压制四小时；加到十六核，批量两小时跑完，看起来冲击时间缩短了一半，但这段时间内的 CPU 队列长度、磁盘队列深度、锁持有范围都比之前更大，在线请求在这一小时内的尾延迟反而可能更差。

这就是为什么很多团队的实际体感是"加完之后月末那天更陡了"——峰值从"持续不太行"变成"短时间的断崖"。对在线业务来说，后者往往更难接受，因为它触发的是超时和失败，而不是单纯的慢。

所以正确的顺序是：先给批量作业划出边界，再评估剩余容量够不够。配额定好之后，如果发现在线份额不足，那时的扩容才是有效的——因为新增的资源会留在在线侧，而不会被批量自动吸收。

五个抓手的顺序：时间窗、配额、拆批、续跑、只读副本

治理月末批量卡顿的抓手有五个，顺序很重要，跳过前面的直接做后面的，效果通常不明显。

第一，定时间窗和截止时间。把批量作业从在线高峰挪开，是把"每天下午两点到五点"这样的大窗口避开。更重要的是明确截止时间：这个作业必须在早上六点前跑完，而不是"跑到跑完为止"。没有截止时间的批量会自然填满所有可用时间，也会在失败后无限重试，最终侵入在线时段。

第二，定资源配额。具体包括并发度上限、可用连接数、I/O 权重、可用临时空间上限、可用内存上限。配额的意义是把批量对资源的占用从一个变量变成一个常量，这样在线侧的最低保障份额才是可计算的。

第三，拆事务与分批。把大事务拆成多批可提交的小批，每批之间留出短时间间隙，让在线请求有机会拿到锁和连接。批的大小决定了单次持锁时长，通常按"单批处理时间可接受"而不是按"总行数除以批数"来定。

第四，可中断与可续跑。跨小时的批量必须能从断点继续，否则一次失败就要重跑整晚，重跑又会把资源再次打满。可续跑的前提是作业要把进度记录下来，断点粒度与批处理单元一致。

第五，报表与查询走只读副本。分析型查询、导出、月报表不应该落在在线主库上。把它们挪到只读副本，既避免大查询直接压主库，也让副本的用途单一化。

这五步里，前两步是约束，第三步是改造，第四步是容错，第五步是隔离。先约束再改造，是因为如果作业本身没有边界，改造出来的分批逻辑仍然会在没被限制的维度上把资源吃满。

从截止时间倒推并发上限与单批大小

一个实用的设计方法是反着算。不要先跑起来看什么时候结束，而是从"必须在早上六点前完成"这个硬约束出发往前推。

第一步，确定可用时间窗长度。假设允许从凌晨一点开始、六点前必须结束，实际可用时间是五小时，其中还要留出失败重试和异常处理的余量，因此有效作业时间可能是四小时。

第二步，用有效作业时间除以单笔数据的处理耗时，得到理论吞吐要求。这里要注意单笔耗时是在有配额约束下的耗时，不是无限资源下的理想值。也就是说，如果已经限制了单作业只能开四个并发，就要按四个并发的实际速率估算，而不是按十六个并发。

第三步，用并发上限和单批大小共同满足这个吞吐要求，并把单批大小限制在持锁时间可接受的范围内。如果两者冲突——即要达到吞吐就必须放宽单批大小或并发——说明要么截止时间不现实，要么作业逻辑本身需要优化，而不是简单地把配额放开。

第四步，把余量明确写进设计。月末数据量的增长是确定的，按去年峰值再留一档冗余来规划窗口，而不是按当前月的数据量卡着阈值设计。否则业务量一涨，窗口自然溢出到在线时段，卡顿就会以"今年更严重"的形式回来。

这种倒推方式还有一个附带好处：它会逼着你先回答"这个作业的业务截止时间到底是几点"。很多月末批量之所以在下午跑，是因为没有人明确要求它必须在夜里跑完，它就自然地占用了白天。

排查顺序：先分清是 I/O 等待、锁等待还是连接耗尽

月末卡顿发生时，第一步不是加资源，也不是重启，而是判断等待发生在哪里。三类原因对应的现象差别很明显：

I/O 等待型：存储设备利用率长期接近饱和，队列深度很高，但 CPU 使用率相对不高，大量进程处于等待 I/O 的状态。在线侧的感受是整体变慢，原本很快的简单查询也慢了。这时要动的是 I/O 配额、并发扫描数量、是否走只读副本，以及大排序是否落盘。

锁等待型：部分语句长时间处于等待状态而不消耗资源，被影响的是特定的表或特定的行范围，其它操作完全正常。在线侧的感受是"某几类操作彻底卡住"。这时要动的是事务大小、批处理单元和持锁时长。

连接耗尽型：应用层出现获取连接超时或连接池等待数飙升，数据库侧活跃会话数打满配额，CPU 和磁盘反而可能很闲。在线侧的感受是"有的请求很快、有的直接失败"。这时要动的是批量侧的连接配额和并发度。

实际排查建议按"先看是哪种等待、再决定动哪一项"的顺序走，不要三者同时下手。一次只改动一个变量，才能确认那次改动是否真的解决了月末那半天的卡顿。另外，排查看的是月末当天下午的数据，不是平时的平均值——周期性问题的证据只存在于它发生的那段时间里。

三条明确不要做的事

不要在月末当天才第一次跑完整批量。月末的数据量、数据分布、异常记录数量都与平时的测试完全不同。第一次在全量数据上跑，必然遇到内存放不下、临时空间不足、单批过大等问题，而这些问题的处理方式往往就是临时放宽限制，等于把隔离措施一次性拆掉。合理的做法是在月中用接近全量的数据预跑，把资源和耗时先量出来。

不要把批量和在线放在同一个没有隔离的实例上，同时要求在线尾延迟达标。这两个要求在没有配额的情况下无法同时满足。要么给批量划出边界并接受它在配额内的较慢速度，要么把批量移到独立的实例或独立的承载上。既要求隔离又不给配额，实际上是把希望寄托在运气上。

不要在没有续跑能力的情况下跑跨小时的批量。跨小时的作业几乎一定会遇到中断——网络抖动、上游超时、实例维护、单点异常都可能发生。没有断点续跑，每次中断都要从头再来，而来一次就要把资源再打满一次，月末夜里的可用时间就这样被反复吃掉。

本文不覆盖的三类资源争抢问题

本文只讨论"周期性批量作业与在线业务争抢同一套资源"这一件事，以下三类问题不在本文范围内。

其一，本文不是通用性能调优清单。慢查询优化、索引设计、执行计划分析、应用层缓存改造这些工作有自己的方法论，它们能让系统更快，但不能解决"月末下午批量与在线争抢"这一结构性问题。反过来也一样：即使所有索引都完美，批量作业依然会在最后两天把资源吃满。

其二，本文不涉及数据库参数调优。缓冲池大小、日志刷写策略、并发线程数这类参数的具体取值要依据实际负载与版本特性确定，本文中出现的"配额""上限"指的是作业层面的资源约束口径，不等于任何具体的参数建议值。

其三，本文不做弹性伸缩或调度产品的选型。市面上有不少批处理框架和任务调度工具能够实现并发限制、断点续跑和依赖编排，选哪一种取决于团队技术栈与运维能力，本文不做比较。文章强调的是在引入任何工具之前，需要先想清楚时间窗、配额、分批、续跑和读写分离这五件事的先后顺序。

批量作业与在线业务的六个争抢位置对照

下表按资源维度列出批量作业的使用方式、在线业务的感受、可以设的边界，以及在暂时无法设边界时的退而求其次做法。这张表可以当作月末排查时的对照清单使用。

关于月末批量卡顿的常见问题

加 CPU 能不能解决月末卡顿？通常不能解决，有时反而更糟。没有配额约束时，批量作业会自动把新增的核心吃满，加配置改变的是批量完成的时长，而不是它的冲击强度。峰值可能从"持续偏慢"变成"短时间断崖"，对在线来说更难接受。顺序应该是先配额、后扩容。

批量作业是不是都该挪到夜里跑？不一定。要看在线业务的低谷段在哪里，以及是否真的存在低谷。有些业务的夜间仍有跨境订单或定时任务在运行，夜里的可用窗口并不比白天宽。真正要明确的是"必须在几点前跑完"，而不是简单地认为晚上就一定空闲。

长事务一定要拆吗，拆多小合适？需要拆，因为持锁时长决定在线写入是否被阻塞。批的大小没有一个通用取值，判断口径是"单批的处理时间和持锁时长是否可接受"，再用截止时间倒推能否满足吞吐。如果达到吞吐必须放宽单批大小，说明作业逻辑或窗口设计本身要改。

报表查询能不能走只读副本？可以，而且应当这么做。但要接受副本的数据滞后——尤其在月末大批量执行期间，回放延迟会被明显拉大。如果报表要求与主库完全一致，就必须在窗口结束后、延迟追平之后再取数，这需要在报表的时间口径上写清楚。

批量中断之后怎么续跑？前提是把进度记录下来，断点粒度与批处理单元保持一致。中断时只重跑未完成的那一段，而不是从头开始。没有续跑能力的作业不应跨小时运行，因为每次中断的重跑代价是一次完整的资源占用。

怎么判断卡顿是 I/O、锁还是连接的问题？看等待发生在哪里。设备饱和而 CPU 空闲是 I/O 等待；语句长时间处于等待状态、且只影响特定表或行范围，是锁等待；获取连接超时、活跃会话打满而 CPU 与磁盘都闲着，是连接耗尽。三者要分开判断，一次只动一个变量。

批量和在线能不能放同一台机器？可以，但必须在有明确资源边界的前提下。配额、时间窗、可中断点三者齐备时，共用承载能省成本；三者缺一，月末那几天就会出现不可控的延迟波动。既要求在线尾延迟达标又完全不隔离，是做不到的。

并发度该按什么来定上限？按在线业务需要保留的最低份额倒推，而不是按硬件能支持多少。先确定在线侧必须留出的 CPU、连接、I/O 份额，剩下的才是批量可用的并发额度，再用截止时间验证这个额度下的吞吐够不够。

本文关于月末批处理与在线业务资源边界的判断

把全文的判断收成一句话：月末周期性卡顿通常不是服务器配置不够造成的，而是批量作业没有自己的资源边界造成的。批量作业会同时消耗 CPU、磁盘 I/O、临时空间、连接数与锁资源，它按吞吐最优的方式运行；在线请求按延迟最优的方式运行，两者混在同一个资源池里时，先天的目标冲突无法靠加配置消除。

因此处置顺序是固定的：先给批量定时间窗和截止时间，再定 CPU 并发、连接数、I/O 权重与临时空间这些配额，然后拆事务分批、做断点续跑，最后把分析型查询挪到只读副本。配额落地之后再评估在线份额是否不足，那时的扩容才会真正落到在线侧。反过来先扩容、后治理，资源会被批量自动吸收，钱花了，月末下午的卡顿照旧。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。若批量作业与在线业务共用实例，建议在选型阶段就把 CPU 核数、磁盘 IOPS、临时空间与连接数上限分开核算，具体机型与配置需结合作业窗口与数据量确认。

本文关于批处理资源账的口径与信息来源

本文的分析基于通用的数据库与系统设计原理，结合典型的月末批处理部署思路写成，文中出现的典型场景均为假设性描述，并非特指某一真实客户或某一次真实故障。文中未引用任何第三方统计数据、厂商实测数据或产品参数。

关于具体阈值：本文刻意不给出 CPU 核数、IOPS、连接数、排序区大小、批大小的推荐数值。这些取值高度依赖业务数据量、所选数据库版本与存储类型，正确做法是在接近全量的数据上自行实测并按观测结果调整，本文只提供判断维度与排序。

关于外部接口配额：上游限流是按调用账号还是按出口地址计算，需要向对应的服务提供方确认，不同平台的规则不一致，不能套用其它系统的经验值。

关于承载与资源的成本：如果评估后决定为批量作业配置独立承载，或需要更高的磁盘 IOPS 与更大的临时空间，方案成本主要受 CPU、GPU、内存、存储、带宽、IP 与线路这些因素影响，且不同节点的资源单价与可选配置存在差异。这类支出应在选型阶段连同作业窗口与数据增长一起核算，具体机型、带宽与报价以官网实时信息或咨询确认为准，文中不提供任何价格数字。