简介这份文档聚焦 SQL Server 2008 R2 多数据库环境下的 CPU 与内存分配优化面向数据库管理员、解决方案供应商及运维人员帮助应对资源争抢、实例隔离和虚拟化开销等常见难题。内容围绕资源控制器展开讲解系统资源池与默认资源池、工作负载组、CPU/内存最小值和最大值的配置思路并对比 SQL Server 2005 的处理器亲和性与独立实例方案说明如何按查询、写入等负载类型划分资源。压缩包仅含 1 个 docx大小约 84KB便于集中查阅和离线留存。已有 1354 人学习文档还提及通过脚本和 MSDN 资料完成分类请求与资源池配置的实践路径适合需要理解资源治理框架、规划资源上限并排查分配问题的中高级读者参考。1. 多数据库抢同一台服务器资源控制器到底在管什么合租过的人都懂那种微妙房子就那么大洗衣机只有一台谁在周日早上洗四件套其他人就得排队。一台服务器上跑好几个数据库本质上是同一件事——CPU 和内存是共用的某个库突然来一个大报表查询其他库的响应立刻开始抖。SQL Server 2008 R2 里的资源控制器Resource Governor管的就是这个总闸和分表的事。它让 SQL Server 2008 R2 的 CPU 与内存分配不再依赖一个库一个实例这种粗暴切法而是把资源按百分比划成池用最小值和最大值界定每个池能保底拿多少、最多用多少。对多数据库同机部署的场景来说这是做分配与优化时最该先搞懂的一个组件——很多人遇到抖动第一反应是加内存换 CPU钱花了问题还在。2. 资源池最小值和最大值到底承诺了什么资源池这个名字听着抽象其实它就是一个资源集合服务器上的一部分 CPU 和一部分内存被划进这个集合里供池内的工作负载使用。SQL Server 2008 R2 默认就定义了系统池和默认池这两个新建的池则用来承接你特意分出去的负载。真正需要搞明白的不是池怎么建而是池上那两个百分比参数——最小值和最大值。它们不是简单的下限和上限语义差一点点配置出来的效果就完全不是一回事。很多人第一次配完发现没生效八成是把这两个值的含义理解反了。2.1 最小值不是预留锁死而是兜底份额最小值用 CPU 或内存资源的百分比表示含义是这部分资源专门分配给该池并且对该池一直可用。注意一直可用这四个字它承诺的是你需要的时候一定拿得到而不是你不需要的时候别人也不能用。打个比方家里给老人留了一份固定的饭菜这是最小值但老人今天没胃口那份饭菜别人可以吃不会倒掉浪费。原文把这一层说得更直接任何没有声明最小值的资源可以自由地跨所有资源池使用。也就是说资源池里剩下的那部分份额是所有池都能来抢的浮动资源。举个例子三个池分别设了 30%、40%、0% 的最小值加起来 70%那么剩下 30% 就是浮动区。前两个池在空闲时第三个池哪怕最小值为 0也能用上远超 0 的资源反过来一旦前两个池忙起来它们会稳稳拿回属于自己的 30% 和 40%第三个池只能退回到浮动区里去争。这个设计带来的第一个实践结论是最小值是保护关键业务的工具不是限制它的工具。给核心交易库所在的池设一个合理的最小值等于给它买了一份再挤也有我一份的保障但如果你给所有池都把最小值设得很高浮动区被吃干净等于把整台服务器的弹性锁死了——高峰一来谁都借不到资源。第二个结论是别把最小值当配额用。有人给报表池设 10% 最小值然后抱怨报表只能用到 10% 的 CPU。其实它空闲时完全能用更多只有在和别的池抢资源时10% 才是它的保底座位。2.2 最大值不是硬墙短时 CPU 峰值是正常的最大值表示该池可以使用 CPU 或内存资源的最大百分比。这句话读起来像一堵墙但原文紧接着给了一个非常重要的补充不管你把最大值设成多少池仍然有可能触发短暂的 CPU 百分之百高峰而且这些高峰不会带来问题被视为正常行为。为什么会这样因为资源调度不是每毫秒精确卡点它是在一段时间窗口内做统计和调整的。当你把最大值设成 60%意思是长期看别超过 60%而不是任何一个瞬间都不许碰到 61%。短时的冲高随后被调度拉回来这才是它真实的工作方式。这一层认知直接决定了你怎么用它。如果你把最大值当成 SLA 里的硬性天花板然后对客户承诺这个池绝不会超过 50%那基本是在给自己埋雷——某次批量任务撞上瞬时高峰监控图上那根尖刺就会成为事故证据。血泪经验是最大值按平均水位 余量来设监控看一段时间的中位数和 P95而不是盯着瞬时峰值做判断。还有一个容易被忽略的点最大值调低不等于性能变好。给某个池压低上限受益的是别人受损的是它自己。压到多少合适取决于你能容忍它慢到什么程度这需要先量出它平时的真实消耗而不是拍脑袋填一个看起来安全的数字。注意资源池的最大值是软约束不要拿它当硬性容量保证来设计应急预案。2.3 为什么所有池的最小值加起来不能超过 100%这条规则是硬性的在配置了多个资源池的情况下分配给所有池最小值的总和不能超过 100%。你可能会想超一点又能怎样答案是那不叫超一点那叫超卖。这跟财务上的道理一模一样。账上只有 100 块你承诺给 A 60 块、给 B 50 块这两个承诺单独看都合理加起来就是 110 块——账面是假的真到两个人同时来取钱必然有一个拿不到。资源调度器同样没法同时对两个池兑现超过总量的保底承诺所以系统干脆在配置阶段就不让你这么填。实际配置时还有一层现实考量100% 不是目标是天花板。真正成熟的做法是给浮动区留出余地比如关键池保底 40%次要池保底 30%剩下 30% 谁忙谁用。这样既保证关键业务有座位又保留了突发流量互相借资源的空间。如果把所有池的最小值堆到接近 100%表面上每个池都有保障实际上是把整台服务器切成几块互不流通的固定分区回到了处理器亲和时代的老问题上——隔壁池闲着你这边再急也用不上。资源控制器最大的价值恰恰在于保底 浮动这个组合把浮动区挤没了等于花新工具的钱办旧方案的事。3. 工作负载组与分类器一个请求是怎么被分到池里的池是装资源的地方但资源不会自己长眼睛去找请求。真正把某个连接和某个池连起来的是工作负载组和分类器函数这对搭档。资源池定义资源边界工作负载组定义一组同类请求分类器则在连接进来的那一刻做出判断你去哪个组。理解这条链路才能理解为什么原文反复强调这活儿不是点几下鼠标就能配好的。建池建组只是配置真正决定成败的是那段要自己写的分类逻辑。3.1 分类器函数给每个连接贴标签的那段脚本分类器函数本质上是一段返回名字的脚本返回一个工作负载组的名字引擎就把这个连接丢进那个组返回空值就落到默认组。它像小区门口的保安看你一眼决定你进哪栋楼。-- 分类器函数连接建立时执行一次返回工作负载组名 CREATE FUNCTION dbo.fn_rc_classify() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE grp SYSNAME; -- 报表类应用应用名里带 Report丢进报表组 IF APP_NAME() LIKE %Report% SET grp NwgReport; -- 批处理账号按登录名识别丢进批量组 ELSE IF SUSER_SNAME() Nbatch_loader SET grp NwgBatch; -- 其余返回 NULL自动落到默认工作负载组 ELSE SET grp NULL; RETURN grp; END;这段脚本有三处值得说清楚的地方。第一返回类型是 SYSNAME也就是对象名类型返回值必须是组名不能是池名——池和组是两层写错了不会报错只会让请求默默落进默认组然后你对着监控纳闷为什么配置没生效。第二WITH SCHEMABINDING 是必须的它把函数和依赖关系绑住防止底层对象被随意改动。第三也是最容易搞错的一点函数里不能做数据访问不要想着去查业务表来判断这个连接属于谁它只能看连接本身携带的信息比如应用名、登录名、主机名这一类。再说执行时机。分类器函数只在连接建立的那一刻执行一次不是每条语句都跑一遍。这意味着它 overhead 很小但也意味着——同一个连接里的所有语句都进同一个组。如果你的应用用连接池而连接池里既有大查询又有小更新它们在分类器眼里是同一个身份分不开。想分开就得从连接来源上区分不同的应用、不同的账号、不同的连接串才是分类器能识别的真实边界。3.2 从登录到执行请求分流的完整链路把配置串起来看顺序是这样的先建池并设置百分比再建组并挂到池上然后注册分类器函数最后让配置生效。-- 建池CPU 保底 10%、软上限 60%内存保底 0、软上限 40 CREATE RESOURCE POOL rpReport WITH (MIN_CPU_PERCENT 10, MAX_CPU_PERCENT 60, MIN_MEMORY_PERCENT 0, MAX_MEMORY_PERCENT 40); -- 建组挂到池上优先级设为高 CREATE WORKLOAD GROUP wgReport WITH (IMPORTANCE High) USING rpReport; -- 注册分类器函数 ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION dbo.fn_rc_classify); -- 让配置真正生效 ALTER RESOURCE GOVERNOR RECONFIGURE;参数逐一看MIN_CPU_PERCENT 和 MIN_MEMORY_PERCENT 填的是保底份额取值范围 0 到 100所有池的最小值之和不能破 100MAX_CPU_PERCENT 和 MAX_MEMORY_PERCENT 填的是软上限是长期平均别超的意思IMPORTANCE 决定同一个池内部不同组争抢时的调度优先级高优先级的请求会先拿到时间片但它不能让组突破池的边界USING 指定这个组归属哪个池写错或漏写组就会落在默认池里。最后那句 ALTER RESOURCE GOVERNOR RECONFIGURE 是最常见的翻车点之一。前面的建池、建组、绑函数都只是写进了元数据不执行这一句配置不会真正生效。很多人配完发现监控毫无变化排查半天最后发现只是少敲了这一行。3.3 为什么按请求类型分比按数据库分更细原文有一个很容易被略过但价值很高的点用了资源控制器之后你不再被限制在数据库这个粒度上分配资源可以给不同类型的数据库请求分配不同的池。它举的例子是可以给查询类操作多分一些 CPU 时间给写入类操作少分一些。这个粒度差异非常关键。按数据库分前提是这个库整体偏重或这个库是核心资产但现实里同一个库上往往同时挂着交易写入和夜间报表两者对资源的胃口完全不同。按数据库分你要么一起保护要么一起限制按请求来源分你可以只把报表那条连接线拎出来扔进一个上限不高的池里让它慢一点跑别拖着交易一起抖。这也解释了为什么分类器只能看连接信息它分的是谁在连而不是这条语句在干什么。你要做的是在应用侧把不同性质的负载用不同的连接串、不同的账号、不同的应用名区分开剩下的交给分类器判断。这条链路想清楚了配置才不是玄学。4. 从处理器亲和到虚拟机旧方案为什么不够用要理解资源控制器为什么被造出来得先看看在没有它的年代DBA 们是怎么处理资源争抢的。两条主流路子——独立实例加处理器亲和、以及服务器虚拟化——都能解决一部分问题但都留下了明显的短板。4.1 处理器亲和分出去就收不回来SQL Server 2005 时代的常规做法是给每个数据库建一个独立的实例然后用处理器亲和把不同的 CPU 绑给不同的实例。听起来很干净物理隔离各过各的。问题在于这个分是单向的。一旦某几颗 CPU 被分配给某个实例它们对其他实例就永久不可用了。结果就是原文描述的那个尴尬局面某个库的负载特别重它也没办法从别的实例那里暂借 CPU 资源哪怕那些实例此刻的 CPU 正闲着晒太阳。打个比方这就像把几台发动机直接焊死在各自的车上。车 A 趴窝了缺动力车 B 停在车库里发动机空转你也拆不下来借过去。资源利用率的天花板在分配那一刻就被钉死了。这种方案的代价还体现在运维上实例多了每个实例都有自己的内存、连接、备份、补丁节奏管理的复杂度是随实例数线性上升的。为了分资源而制造出一堆实例本质是用运维成本换隔离性。4.2 虚拟机隔离每台虚拟机都在偷偷吃资源另一条路是服务器虚拟化每台虚拟机只托管一个数据库用虚拟机来做资源隔离。这条路确实可行隔离性也不错但它有两个绕不开的成本。第一个成本是过路费。虚拟机和它上面的操作系统本身就要消耗一部分服务器资源而这部分资源本该是留给数据库的。你为了隔离付出的代价是整体可用资源被打了个折。第二个成本是弹性。原文说得很克制依赖你使用的虚拟化软件以按需分配为基础的资源动态分配可能有些困难或者根本不可能实现。翻成大白话就是——你能不能在某个虚拟机闲着的时候把它的资源临时挪给另一个饿着的虚拟机取决于底层平台支持到什么程度很多时候答案是不太行。于是局面变成隔离做到了开销增加了动态调度还是没解决。对于本来就资源紧张的服务器来说这等于用更少的资源做同样的事。4.3 三种方案放一起对比把三条路摆在一起看差异其实很清晰。维度独立实例 处理器亲和每库一台虚拟机资源控制器隔离粒度实例级虚拟机级池 / 工作负载组级资源能否动态流动不能分出去就锁死依赖虚拟化平台常受限能未声明最小值的部分自由竞争额外开销多实例运维成本虚拟机与客户机系统开销分类判断的极小开销配置方式图形界面为主虚拟化平台配置需要编写脚本适用前提库数量少、负载稳定已有成熟虚拟化平台单实例多库、负载性质可区分看这张表要抓住一条主线前两种方案都是在切分上做文章切完就固定资源控制器是在保底 浮动上做文章切完之后资源还能流动。这正是它相比前两者最本质的进步也是为什么原文开头就说SQL Server 2008 R2 的资源分配方式与 SQL Server 2005 相比是完全不同的过程。但表里最后一行也别忽略它需要写脚本。原文明确点出了这个缺点——这不是一个点几下鼠标就能启用的管理工具分类处理请求、把请求转发给合适的负载组需要编写大量脚本。功能和成本永远是一对愿不愿意付这个成本取决于你的场景到底有多痛。5. 五个最容易搞混的点资源池、工作组、上限和峰值配置本身不难难的是概念之间的边界。下面这五组混淆是刚开始接触资源控制器时出现频率最高的每一条都能让人在监控面板前多坐两个小时。5.1 误区一最小值等于独占易混点把 MIN_CPU_PERCENT 理解成这个池被锁定的资源量。为什么混因为最小值这个词天然带着固定下来的暗示加上配置界面上确实是一个确定数字很容易脑补成一块被切走的蛋糕。怎么区分记住它是保底不是封顶。池在别人不用的时候可以远远超过最小值只有当多个池同时争抢时最小值才生效保证它至少能拿到这么多。判断方法很简单——看浮动区还有多少。如果所有池的最小值加起来远低于 100%说明还有大量资源在自由流动此时某个池跑出高于最小值的成绩是正常的不是配置失效。5.2 误区二设了最大值就绝不会超易混点把 MAX_CPU_PERCENT 当成一道物理硬墙。为什么混参数名叫最大直觉上就该是绝不能越过。加上很多监控工具默认展示瞬时值一根尖刺特别扎眼。怎么区分在 SQL Server 2008 R2 这一版里最大值是软上限允许短时的 CPU 冲高原文明确说这种短暂峰值不带来问题、属于正常行为。所以判断它有没有生效不能看单点要看一段时间的平均水位和趋势。如果你的场景需要的是绝对封顶那要在版本特性上单独确认别想当然。5.3 误区三资源池就是工作负载组易混点把池和组当成同一个东西的两种叫法。为什么混两者总是成对出现配置时前后脚创建名字还经常起得很像。怎么区分用一句话分开——池装的是资源组装的是请求。资源池是一堆 CPU 和内存的集合工作负载组是一群同类连接的集合组通过 USING 挂到池上才把人和资源接上。所以你会看到多个组可以共用一个池也会看到池的百分比参数和组的优先级参数完全不是一回事。搞混这两个配置就会写成给组设最小 CPU 百分比然后发现语法根本不对。5.4 误区四分类器是自动的易混点以为建完池和组请求就会自己找对门。为什么混图形界面把池和组画得很直观让人以为分流是内建行为。怎么区分分流完全依赖你写的那段分类器函数。没注册函数所有连接都会落到默认组前面配的池一个都用不上。另外两个细节也要记住函数只在连接建立时执行一次不是每条语句都判断改完函数必须重新执行生效命令。排查配置没效果时第一步就该确认分类器函数是否已注册、返回值是否真的命中了目标组名。5.5 误区五内存份额和实例的内存上限是一回事易混点用资源池的内存百分比去替代实例级别的内存配置。为什么混两个旋钮都带内存两个字都在调百分比或上限看起来像同一个东西的两种入口。怎么区分它们不在一个层级。资源池的内存百分比管的是池和池之间怎么分而整台实例愿意用多少操作系统内存是另一个层面的设置。前者解决的是内部打架后者解决的是别把整台机器吃光。指望调低某个池的内存上限来给操作系统留出空间方向就错了。正确的顺序是先定实例层面的总量边界再用资源池在内部做二次分配。6. 什么时候该配什么时候干脆别碰聊完概念最后落到判断上。资源控制器不是性能优化开关它解决的是一个很具体的问题同一台服务器上多种负载互相踩脚。符合这个前提它才有价值不符合配了也是给自己找活干。该配的典型场景有三类。一是单实例上挂着多个库且负载性质差异明显比如交易写入和报表查询混在一起二是连接来源可识别应用名、登录名、主机名能稳定区分出不同性质的负载分类器才有判断依据三是团队有能力维护脚本愿意把分类逻辑纳入变更管理。三条同时满足收益会非常直接——不用拆实例、不用加机器就能让关键业务拿到保底资源。不该碰的场景同样清楚。只有一两个库且负载平稳问题根本不在资源争抢配置只会增加一层不必要的复杂度连接来源完全无法区分所有请求长一个样分类器写出来也只能全丢默认组团队没人愿意维护那段脚本配置上线后没人敢改它会迅速变成一个黑匣子。还有一种情况要特别警惕把资源控制器当成性能调优手段指望配完跑得更快。它做的是资源再分配不是性能提升总量不变的前提下有人变快就一定有人变慢。你的处境建议单实例多库报表和交易互相拖累值得配先分离报表连接连接来源可用应用名或账号区分适合配分类器有判断依据只有一个库负载平稳不必配先查慢查询和索引所有连接来源完全一致暂不配先改造连接管理配完就没人维护脚本不建议配风险大于收益期望配完整体变快不建议配它不是加速器真要我给一句实操建议那就是先量后配把每个候选负载平时的 CPU 与内存消耗摸清楚按实测水位去设最小值按可容忍的慢速程度去设最大值浮动区留足别一上来就把百分比填满。我自己的教训是早年给一套多库环境配完就撒手三个月后业务方说报表慢得离谱我打开配置才发现有人为了救一个批处理任务把报表池的上限压到了个位数而这件事没有任何记录。从那以后我每次动资源配置都强制走一遍流程先记录改动前的实测水位再写清楚每个数字的依据改完立刻用两组不同来源的连接验证分流是否真的命中。慢一点但省下来的排查时间远超这点功夫。希望帮到你。本文还有配套的精品资源点击获取