SQL Server 遭受大并发量时,该做些什么

前言  

L,大面积用户登录不了,咋回事啊

640

640

啊,不会吧,我看看啊

640

640

只要是 IT 职场老鸟,上述系统大面积报停的场面肯定再熟悉不过了。负责人不管是项目经理还是产品经理,轻描淡写的一句“咋回事儿啊”,轻则吓得你面红耳赤,冲则口吐鲜血,不省人事。别以为这是笑话,某银行 Oracle 宕机后,DBA 赶到现场敲开 sql*plus,鼓捣一阵后 直接吐血昏倒。这是血的教训。如果你没遇到,恭喜你,你还年轻。

这类问题,平时没有做过基准线测试的朋友肯定会慌。问问自己,设计的系统能承受多少的并发请求,(讲人话)当 2000 个用户同时登陆系统,查看自己有没有新的消息,页面能在多少时间返回?那么当有 20 万,200 万用户呢。你设计的系统能保证多少人同时访问,并在 1s 内返回请求的数据?

这些问题就是基准线,不知道各位在设计系统的时候,做了测试么?

正文

上面所说,是设计所考虑的主动规划,而现实中往往迫于产品经理或项目经理的淫威,开发人员特别是 SQL 开发人员绝对没有时间来做的事情。上线之后只能烧香拜佛,祈祷千万别来个 10W+ 访问。而现实却会啪啪打脸,所谓越怕的事情越容易发生。作为专业背锅侠,SQL 开发绝对冲在第一线。前端 UI 的异常,报出来的全是数据库连接超时,你说老板不找 SQL 开发难道去找 UI 写 JS 的?

作为补救措施,在昧着自己良心上线未经压力测试的数据应用系统之后,应当做好每日的巡检工作。而其中最重要的一项便是响应统计分析。不知道系统每日访问量,访问峰谷值,QPS, UPS, 我觉得就和拿着 AK47 直往前冲,全然不顾敌人多少,子弹多少一样,自寻死路。

 SQL Server 中有一张神奇的性能表,应用好此表,即可提早知晓 80% 的性能问题:

sys.dm_os_performance_counters.

记载了与 perfmon 中 SQLServer 指标下相同的性能计数器。通过这些计数器可以得到数据库在某段时间内的性能变化。perfmon 可以监控当下最新的系统状态,而对 sys.dm_os_performance_counters 做持续性跟踪记录,便能监控更长时间数据库性能的状态。

主角

性能指标有很多个,每个都要关注未免有点力不从心。聪明的开发者一般都有自己用得顺手的指标。今天介绍一个我喜欢用的 Batch Resp Statistics. 当然你肯定有自己喜欢的,欢迎来文讨论。

Batch Resp Statistics, 用来记录响应统计值。这些值都是自 SQL Server 启动以来累加的统计值。举个例子,一个请求耗时 2ms, 假设系统自启动以来有 2000万个这样的请求,那么总计 4000万 ms 便是计数器 (Elapsed Time:Total(ms) )的值。

对 Elapsed Time:Total(ms) 做间隔时间的跟踪,比如 5s. 可以得到这 5s 内是否出现访问量剧烈跳动的异常,假设做成折线,斜率是非常陡峭的:

640


在稳定的访问时间段,增长都是温和的,基本维持在一个小斜率的曲线上。访问放量之后,斜率就几近垂直了。此刻就要在日志系统分析,是否有异常。这基本属于另一个话题,比如增长,黑客攻击等。数据分析的魅力就在于此,脑洞特别大就越有趣。


配合下面的净增增长柱状图,能在更细粒度查看系统承载的访问量。细看之下,46s 的时候,尽然有 250000 次请求。之后请求又回落到正常的区间。这足以让每个 SQL 开发或 DBA 紧张起来。

640

在跟踪 Batch Resp Statistics 时,需分清指标维度和指标性质。指标维度是区分请求与批次(Batch)的个体,一个批次中会有多个请求;指标性质区分时间分段,仅仅 CPU 耗时,还是整体耗时。

精彩内容

本号精华合集

关于作者

640

推荐朋友 Iyven 的公众号【SQL数据库开发】。同道中人,都是 SQL 爱好者。作者文章思路清晰,知识框架全面,系统性学习 SQL 的好地方。此号有太多特色:想要视频,这里有;想要电子书,这里都给您备齐了;想要经典的 SQL 编程题,关注吧,取之不尽。

640

640

640?

640