"数据库(或中间件)非常慢了,如何监控它的性能”
“你想得到什么性能指标?”
“就是……内部的性能指标”
收到性能测试人员这样的问题后,通常会发生上面的对话。
我的观点是,准确的说出你想要做什么,比你会不会做更重要。
那么对于性能测试人员来说,”性能监控“这门必修课,该从何下手呢?
监控什么
如果我给你一个黑盒子,告诉你里面是一部机器,要监控它的性能。你能做到么?当然不能。因为你不知道这部机器如何运行,你不知道对它而言性能是什么。
性能测试也一样,说到操作系统,大家都知道性能指标要看CPU、MEMORY、DISK IO以及NETWORK等等。但是到了数据库和中间件,如果测试人员说不出具体内容,这表明他不知道针对这个对象,性能是什么,即便把最完整的性能指标摆在面前,恐怕也是没有意义的。
当然知识和经验是一步步积累起来的,但也需要测试人员去主动的学习。从系统体系结构、运行原理到性能监控、性能调优基础和方法,官方手册总是最好的教材。
那么在没有掌握这些知识之前,我希望上面的问题是这样问,“数据库(或中间件)非常慢了,一般需要监控它的哪些性能指标呢”,得到回答后赶紧翻资料吸收相关的知识。
过程中的监控
性能测试新手容易忽略测试过程中的性能监控,而只给出一个最终的测试运行结果。
比如这个问题,“测试运行3小时后,系统没有响应,中间件无法连接”。
对于这样的问题,期望开发人员如何处理呢?中间件已经无法连接,想获取到一些内部的性能指标恐怕都已做不到。只有重运行一次,让开发人员来关注过程中的运行状况,但这本应是由测试人员来做的。
如果我们知道,中间件本身无法响应一般可能是因为这两个问题:
JVM堆内存用满,不停的进行GC,导致响应超慢(但是还没有OOM,否则就报错了)
处理HTTP请求的线程,都被占用或者锁住
那么我们就可以在测试过程中去监控这两项数据,跟踪变化趋势,直到系统再次无法响应。如果正好其中的一个资源也耗尽了,那么就可以确认“无法响应“这个现象的直接原因。实际上,这两个指标基本也是中间件最重要的指标,理应每次测试过程都进行监控和数据采集了。
监控的层次
系统的性能表现会涉及到多个层面,比如:
中间件 -> 中间件操作系统 -> 数据库 -> 数据库操作系统 -> 客户端
监控时也要着眼于多个层面,这样才有可能更接近问题的本质。还是上面那个中间件无法响应的问题,假设我们观察到了所有HTTP线程都被占用,也许更进一步我们又会发现这些线程都在执行数据库的查询,而这些查询在数据库中的状态依然是running,那就说明更根本的原因是在数据库层面。这也就是问题的逐步定位。
全面的监控
片面的数据不足以说明问题,系统的方方面面常常是相互影响的。
比如数据库的CPU占用很高,并不能证明系统是计算密集型、CPU是瓶颈,也有可能是spinlock的争用导致了CPU骤增。
再比如大量的page-in IO可能会使内存出现瓶颈。
上面的层次问题其实也属于”全面“的范围。只有拿到全面的数据,才有可能分析出正确的结论。
当然,这又是一个需要积累的过程,如果连spinlock都不知道,又怎么可能有准确的判断呢。
方法还是一个,主动的学习,系统的学习。