昨天路过某省会城市，在一个很宽的6车道的大路上突然遇到严重的拥堵，过了拥堵路段后也没有发现交通事故、修路等堵点。同行的朋友说堵车点有个50公里限速的摄像头，所以这个地方随时都可能堵车。这也是内地城市管理与发达城市之间的差距，在深圳这种为了罚款而设置的超速设计早就因为缓解交通压力而去除了。
这种不合理的城市道路甚至高速公路限速在早些年很流行，这造成了城市和高速公路局部拥堵，在春运高峰期尤为严重。不过这方面的整治这些年初见成效，我最近走过几次跨城高速公路，以往60公里限速的隧道都已经提高到80，甚至100了。
今天的主要内容不是讨论城市交通，而是想以这个为引子谈谈不合理的监控设置的危害性，其实在企业IT管理中，也处处存在着这样的不合理限速。前些年去一个金融客户那边做优化，他们有一台CPU线程数512，物理内存1TB的4路服务器，跑着一套Oracle。平时CPU使用率也就不到10%，高峰期也很少超过20%。有一条十分常用的查询语句我实在没办法优化了，因为要扫描一张大几千万行数据的大表，因为过滤条件很宽泛，所以无法使用索引。但是客户觉得这个查询往往都是很急的，希望能在2-3秒之内完成。我试了试，用户的存储系统性能很好，热数据都是放在闪存盘里的。于是测了测并行查询，效果很好。于是建议他们使用并行查询来解决这个问题。当时他们不愿意加HINT，于是就在这张表上开了并行。
过了几天，DBA给我打电话说，上回开了并行，效果确实不错，业务部门满意了。不过他们就比较麻烦了，最近他们的服务器CPU使用率经常报警，他天天要给领导汇报，搞得他累死了，他想把那个并行关了，看看那个SQL还有其他优化办法没有。
我当时觉得挺奇怪的，因为那个模块用的人不多，就那么几个做审核分析的人在人工操作。不大可能因为那条SQL并行扫描把CPU干爆吧，难道还有其他SQL也扫描那张表？于是我让他找了一大圈，也没找到问题点。这时候他突然说，CPU又超60%了，他得去处理了。我吃了一惊，CPU超60%处理个啥呢？又不是爆掉了。
于是我问他CPU超60%是什么意思，他说他们规定，核心系统的CPU使用率不能超过60，否则认为系统存在安全运行风险。这是个十分严重的告警，必须做闭环管理。我调了那个并行参数后，他们的数据库服务器隔三差五就会报CPU超60%，虽然是偶发性的，也没发现核心业务受到影响，不过这是一个一级监控指标，一旦报警必须进行分析，并写报告。他最近已经写了三四次报告了。
我当时懵住了，CPU不能超60%，这是个啥管理路数？花那么多钱买那么好的服务器，不就是为了让应用跑得更好一些吗？为啥非要限制CPU使用率不能超60%呢？也正是这样一些奇葩的规定，让数据库的并行执行功能在企业级用户处被限制得很严格。在早些年服务器、存储性能十分有限的时候，并行执行确实很容易耗尽系统资源，因此只能被严格限制。很多IT部门的上点年岁的数据库主管可能都经历过那种痛苦，因此这种限制一直被延续下来了，虽然现代硬件能力已经能够支持并行查询，也不敢轻易放开。
再加上一些不合理的基线指标设计，导致很多数据库中的优秀功能被不合理地限制使用了。就像我们的城市道路，在低水平的管理者的管理下，无端端增加了无数不必要的堵点，让城市交通雪上加霜。今天讲的虽然只是一件小事，其实在我们的企业中，类似的问题还是普遍存在的，管理带来的问题，有时候比技术带来的问题更大。
