性能诊断-Monitor 7大新特性，助你效率起飞

接下来小编将以新特性为纲，结合使用示例带你一步步上手。

• 特性价值：批量监控集群所有实例CPU实时使用情况。

• 操作入口：【集群监控】->【TOP监控】。

• 使用示例：在系统卡顿时，观察集群所有实例CPU负载状况，定位出CPU用量较高的实例，进一步分析是什么线程引起CPU使用异常。

• 宿主机信息：显示宿主机的CPU数量、CPU最近平均负载情况、CPU用量等。

• JAVA线程实时监控：显示CPU使用TOP5的线程，包括线程内存、CPU、任务类型等。

• JAVA进程快照：显示最近5次JVM进程内存、CPU用量详情。

通过上图，我们可以很快发现集群所有节点当前状态CPU用量并不高，但过去一段时间CPU平均负载比较高，基本断定应该会卡在阻塞等待上，结合下面介绍的特性还可以进一步分析。

通过“调用耗时”火焰图，很直观地看到线程阻塞主要发生在与PG数据库通信网络的等待上，这说明执行的SQL较慢，只分析网络等待还不全面，应该继续分析是否有锁阻塞。

• 特性价值：一键排查集群中所有数据中心的慢SQL，支持下载，提高定位业务中慢SQL的效率，支持MySQL、Postgresql、Oracle数据库。

• 操作入口：【性能治理】->【SQL实时快照】。

• 使用示例：结合上面步骤使用SQL实时快照继续分析SQL执行情况，查询执行大于10秒的所有SQL。

SQL实时快照图

如上图，可以同时查询多个数据库正在执行的慢SQL，SQL执行非常耗时，至此我们可以明确，性能慢的主要原因是这些慢SQL导致的，相比分别去每个数据库主机排查，效率提升明显。

在SQL实时快照查询中，每个SQL主要包含2个部分。

• 标题：包含数据库schema和其所属的主机IP以及发起调用的TraceID。

• 详情：包括SQL在数据库中已执行时长、数据库类型，以及SQL对应的原生状态类型和状态值。状态显示具体数据库原生名称，分别如下：

• MySQL显示为status及对应的值，如staus:sending data

• Postgresql显示为wait_event及对应的值，如wait_event:buffer_io

• Oracle显示为event及对应的值，如event:row lock contention

分析到这里是不是感觉还是不透彻，SQL执行这么慢，数据库到底处于一种什么状态？我们继续深入分析。

PMM(Percona Monitoring and Managemen)提供非常友好的监控分析页面，尤其数据库监控功能可以帮助数据库管理员实时监控数据库性能、执行查询分析、诊断问题和优化性能。

V6.0.1 Monitor配置集成PMM监控功能页面，PMM服务端和Agent需要运维人员自己安装，安装方法请参考官网说明。

• 特性价值：支持可视化界面快速查看数据库CPU、IO、内存、网络等指标；支持查看SQL的负载、平均耗时、QPS等状态；支持查看SQL执行计划，定位慢SQL根因等，完善数控层定位问题能力，提高系统故障排除效率。

• 操作入口：【第三方工具】->【PMM】。

• 使用示例：结合上面步骤使用PMM继续深入分析数据库指标，参考入口打开PMM首页。

PMM主页图

如上图，主页主要显示硬件指标详情，便于快速掌握数据库主机的性能。

从监控图示例看，最近15分钟CPU、网络、磁盘都在持续增加，但是可用内存持续下降并且一度接近10%以下，因此从上面监控图可以看出数据库主机内存资源严重不足。我们继续分析数据库自身指标，排查原因，打开数据库实例监控面板，操作方式及监控指标如下图：

最大事务耗时监控图

SQL负载及平均耗时图

从监控图可以看到，第一条SQL最近15分钟平均耗时接近4秒，查询时间就用了将近3秒，进一步可以通过“Plan”页签查看执行计划，以深入分析根因。

分析到这一步，性能根因已经很明确，大量执行一个平均耗时4秒的慢SQL，使数据库主机CPU接近60%，内存使用接近90%产生严重的性能问题，进而导致服务阻塞严重，同时验证了前面通过“调用耗时”火焰图分析的结论，大部分时间用在网络等待。