关联与下钻:快速定位MySQL性能瓶颈的制胜手段

2019-09-10 15:59:14 采集侠

目前我从事的是MySQL的技术研究并让其实现产品化的工作,所以给大家今天分享的是MySQL性能分析的一些思路。

分享大纲:

1.MySQL性能管理需求与现状

2.MySQL性能分析建设

MySQL性能管理需求与现状 1、数据库管理的现实需求

MySQL性能管理的现实需求很直观,我们现在大部分的客户都是在传统企业,而传统企业这几年向MySQL转型也是非常迅猛的。

所以用传统的商用数据库建设MySQL时就会发生一些很头疼的问题,比如:如何让少量的DBA管理大量的数据库?如何通过简单的方式改善和优化数据库性能问题?如何持续保障数据库的连续性和稳定性?…

数据库

一个极大的风险点在于MySQL的性能数据难铺展开回溯。MySQL性能数据的特点是比较依赖实时分析或执行分析,事后能得到的信息较少,也很难下钻下去。当少量DBA管理大量数据库时,出现问题只能通过高可用手段快速处理保障可用。但缺乏充足信息的回溯手段,往往只能在执行时间,锁定时间等少数几个维度分析问题SQL的影响程度,其覆盖面难以包括大部分SQL语句的影响层面,这在很多运维环境上看来,缺乏事后分析手段,都是存在极大风险的。

在这个方面我们需要基于MySQL目前已有的分析手段去做改进,让MySQL具备它原本不具备的性能信息增量记录的能力,并在这个基础上实现关联与下钻分析,便于快速定位到数据库性能问题。

2.传统MySQL性能管理手段的限制

从传统上来说,MySQL性能分析的特点是实时执行、分析手段多样,事后分析主要依赖Slow日志。

人工做问题分析,一般需要借助PT工具(Percona Toolkit)生成时段内慢语句报告,它能得到一些时段内的慢语句情况。但这并不能把PT工具生成报告跟原本在某一时段内的数据库性能的整体状态做一个关联。

假设出现了一个性能问题引起的数据库宕机故障,因为存储在数据库内的状态信息P_S信息在重启后都丢失了,那我们可以借助的手段只有日志分析和监控平台的状态指标分析。事实上这是一个比较头痛的过程,因为这些分析难以关联、精确定位到造成问题的原因。

数据库

另一方面,如果要将这些多样化的分析手段都产品化,那对我们来说一定是一个稳定性、可用性非常差的选择。

因此,从简单即运维这个观点出发,站在产品化的角度面对不同的用户时,要尽量减少现场为了适应产品接入而进行的变更,同时还要能够提供最关键的关联与下钻分析功能。上述提到的这些点都是我们做设计的过程中一致考虑的问题。

3、优化MySQL性能管理的思考

谁都希望实现的工具是轻量化的,不需要做太多改造就可以接入。性能管理的需求分析起来可归结为三点:

第一是轻量化采集,即接入数据库并拿到数据库性能信息。常规的分析手段都是用一种形式,但其实用非侵入手段会更好。什么叫非侵入手段?就是直接给工具提供一个账号和相应的权限,然后工具就能通过接入数据库采集响应的信息来避免Agent,这样就能尽量避免自动化采集过程中对目标端的性能影响和风险。

MySQL

第二是增量化记录:状态增标、语句信息实现增量化记录,使性能管理具备丰富的时段展示手段和历史回溯手段。

第三是经验沉淀:沉淀MySQL性能分析经验的重点在于沉淀指标关联,下钻到问题语句分析过程。整个分析过程很简单,重点在于提供给用户在使用层面中哪些指标是需要关联的、哪些指标是可以帮助我们进一步下钻的,这样就可以把分析的逻辑清晰化,也可以解决很多问题。

MySQL性能分析建设

下图是在MySQL做性能分析里要去关联下钻的总体思路。从图中可以看出,展示层就是性能入口。我们应该选取少量小而简单的性能指标来作为它的问题点上浮。

MySQL

后面是通过性能上浮的指标来提供一系列对比的手段进行分解,同时还能做到指标间的对比、指标和语句的关联。最后根据突出的性能指标下钻到语句,并确认语句的执行形态是否造成了性能的风险。

能做到这层指标关联与下钻,主要在于数据库中对语句执行性能信息的丰富程度远远大于日志记录的信息,再将语句执行记录的信息与数据库相关的状态信息进行关联,这样就更容易分析到语句执行对性能的影响了。

1、性能入口

(1)选取适当的上浮核心指标