Power9问世又怎样,一条SQL就把最牛小型机搞瘫了(有彩蛋)

杨志洪 2016-04-10 09:57:00

 

看惯了各种深入原理、细致入微的分析,今天写一个简单、轻松的话题,但愿不会耽误你的时间。好吧,标题是有点夸张,放心,这不是一个标题党就完事的文章,毕竟我还希望你能持续看我的后续文章呢。

  ◆    

 

 

说到史上最强的小型机,我想,应该是IBM Power880了吧:

 

 

不用想,读者诸君,虽然POWER9的芯片本月已经发布了,但Power880你肯定还没有用过,因为在国内暂时还没有上架呢。

 

今天我说的是上面这孩子的叔叔,Power780,用的是POWER7的CPU处理器,顶配192个CPU,1TB内存,再配以DMX4顶级存储(SSD+SAS)。这单机配置放眼全国企业级服务中心,相信可以秒了许多吧。

 

2.png

 

毫不夸张的说,我刚看到这配置的时候,内心是惊诧的,1TB的X86服务器遍地跑,1TB的小型机真是第一次见。更重要的,这是I家的小型机,可跟H家、O家的这些不一样,最近出来的K家就更不提了。

 

不用说,这是客户的核心业务系统的主机了,48个core共192CPU,这在Power880里也是顶配了哦。客户成功升级到Power870后。大部分时候,CPU利用率从原来的七八十降低到了二三十。但是,就是这样顶配的小型机,居然成功被一条SQL搞瘫了!

 

而且,几乎是用最简单的方式。

  ◆    

 

 

如果你是DBA+社群的订阅者,那么一定看过一篇文章《Oracle后台专家解决library cache锁争用的终极武器》,这篇文章重点介绍了library cache:mutex X锁的原理以及各种解决方法。当然,如果你以前没有看过,那也不用着急去看,读完本文,你仍然急于求学的话,再看不迟。

 

搞死一个小型机的方法多种多样,但今天介绍的这种,应该是最快的。当然,最重要的是,搞死了你还不用承担刑事责任。如果你是一名开发人员,你可能也在用别的方法在搞死你的服务器,那是另外一回事,咱先不多谈。

 

我随便截取系统被搞瘫过程中其中一小段,也就是十几分钟的AWR,给你看看。

 


 

 

这条语句非常简单:

 

4.png

 

在一个本身业务压力就比较大的大型生产系统中,就夹杂在这么一条语句,系统就搞瘫了,在其核心业务单个SQL执行次数也就几万次的情况下,它执行了600多万次,平均每秒接近6000次。当然,你千万别问我,能不能给一个阀值,每秒执行多少次就可以搞瘫一个系统。

 

我可以来模仿这个系统被搞瘫的过程。脚本是俄罗斯人Andrey Nikolaev 写的,原文件名是@library_cache_mutex_contention.sql摘录几段:

 

首先生产一个单会话语句:

 

5.png

 

再生成一个多会话语句:

 

6.png

 

然后,开几个客户端,执行@many_threads.tmp,在数据库里就会出现library cache: mutex X等待事件。如果你的机器还没被搞趴下,那就再开几个窗口,运行@many_threads.tmp。

 

重要提示,千万别在生成上搞,问题会很严重的!重要提示,千万别在生成上搞,问题会很严重的!重要提示,千万别在生成上搞,问题会很严重的!

 

  ◆    

 

 

如果耐着性子看到这里,你应该没去做这个试验。当然,试验你可以回头慢慢做,放心,一定能搞倒机器的,无非是多开几个终端。

你的疑问可能是,这个开发商为什么要这么频繁的执行这么一个简单的SQL语句?

 

或许你之前看得最多的是 select 1 from dual?许多开发商的开发人员,喜欢用select 1 from dual去探测数据库连接是否活着。

 

在本案例里,开发人员是要从数据库里读取服务主机的时钟,然后插入到业务记录里去。

 

需求正常么?好像也没什么不正常。

 

但你知道,一万多个sessions连接到一个数据库实例频繁这行这么个简单SQL,数据库就会变得非常不正常了。

 

解决这个问题的方法相信大家有很多思路。最简单易行的方法,设置一台时钟源,所有的业务主机、客户端都与该时钟源保持同步。然后应用程序读取自己机器的时间就好了。再说了,如果只是一个业务办理时间,不同步,或者不那么准时又如何呢?

 

最好的优化,不是把所谓的优化原理钻得多么透彻,而是把不该需要的“需求”准时的剔除掉。

 

  ◆    

 

 

作为一个技术人员来说,总归会有点叶公好龙的心态,看到“深入解析”“极致分析”“内核探秘”之类的文章都会想去学一学,到头来,其实除了浪费时间,啥也没得到。直到看到和菜头博文的一张图,配了一句绝精妙的话:“你的脑子装的都是别人的垃圾”。我就决定不写深入原理的文章,倒垃圾给别人了。这样的文章,其实除了让作者自己爽,绝大大多数人是什么都收获不到的。

 

因为社群,结识了很多朋友,有开发的大咖约我写一篇《开发人员必备的Oracle基础知识》,我觉得是个好题目,基础的东西才是影响最大的东西。动笔已经很久了,但一直没有写完,总怕写出来太深我也写不出或太浅写了也没太大意思。

 

↓↓ 福利在这 ↓↓

如果你是DBA或者开发大咖,你遇到过开发挖的坑,值得分享的,就像我这篇提到的,欢迎在文末评论给我们。对于那些好的评论,我们将送出价值50元的图灵读书券(可以直接在www.ituring.com.cn上购买图书)或者等值图书。

 

 

作者介绍:杨志洪

 

  • 【DBA+社群】联合发起人

  • 数据管理专家,拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验,掌握ITIL运维体系,擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务。

  • Oracle ACE、OCM、 SHOUG/ZJOUG核心成员、DAMA会员/CCF会员。ITpub版主,译著《Oracle核心技术》。



 

全球敏捷运维峰会【杭州站】

 
 
 

 

 

杭州站倒计时:2016年4月16日,DBA+社群联合Linux中国、三墩IT人开启全球敏捷运维峰会第一站:杭州!

 

技术大咖云集:峰会力邀来自阿里、京东、淘宝、网易、IBM、浙江移动、新炬网络、蘑菇街、百世物流等互联网与传统企业的资深大咖,汇聚500+行业精英!

 

互联网 VS 传统的碰撞:共同探讨互联网前沿技术应用心得、传统企业技术转型的实践与困境、全程拒绝无营养的广告,绝对干货,精彩不容错过!

 

DBA+社群专属购票优惠

门票优惠价:39元(原价99元)

(优惠码:dbaplus001)

VIP票优惠价:199元(原价299元)

(优惠码:dbaplusvip)

 

↓↓ 购票通道 ↓↓


扫描二维码

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告