要如何诊断Java代码中常见的数据库性能热点问题_南京Java培训分享

jswanho

　　你的Java应用程序的性能是怎样诊断和优化的？在南京万和Java培训看来，性能工程的根本在于通过大量的观察，将关键的架构指标、可伸缩性指标以及性能指标关联在一起。通过对每次构建的结果以及不同负载情况下的表现进行分析，以发现系统中的回归缺陷或瓶颈所在。以下图中的仪表板作为示例：

                               
登录/注册后可看大图

　　通过将系统负载、响应时间与SQL语句的执行次数等指标相关联，可得出某些性能工程方面问题的根本原因。

　　最上面一张图叫做“层分解”图表，它显示了你的应用中各个逻辑组件（例如Web Service、数据库访问、业务逻辑、Web服务器等等）的总体执行时间。红色部分所表示的是某个后端Web Service所花费的时间，很明显这里产生了一个组件热点。

　　我们同时可以发现，该Web Service并没有承受异常的负载，因为从第二张图来看，当时应用程序所处理的请求数量这条线比较平稳。一般情况下，整体响应时间多数都耗费在数据层，但这并不代表数据库本身的速度缓慢！我了解，低效的数据库访问往往是造成性能不佳的主要原因，因此通常会结合分析SQL语句的执行次数。在这个示例中，已经能够很清楚地看到它与大多数响应时间的峰值是相关的。

　　南京万和Java培训所观察到最常见的问题模式就是糟糕的数据库访问模式，此外还有过于细粒度的服务调用、糟糕的共享数据访问共享、过度的日志记录，以及由内存泄露以及大量的对象创建所导致的垃圾回收影响或是应用程序的崩溃。

　　可选的诊断工具

　　在本文中，南京万和Java培训将专注于探讨数据库方面的问题，因为南京万和Java培训十分确信你的所有应用都是因这些访问模式中的某一种而产生问题的！你可以在市场上已有的各种性能诊断、追踪，或是APM工具之间随意选择，不过我所选择的是免费的Dynatrace Personal License。Java本身也提供了各种出色的工具，例如Java Mission Control等等。许多提供数据访问功能的框架也经常通过其日志输出提供各种诊断选项，例如Hibernate或Spring等等。

　　在使用这些跟踪工具时，通常不需要对代码进行任何修改，因为他们都利用了JVMTI（JVM Tooling Interface）以捕获代码层面的信息，甚至能够跨远程的各层次进行调用追踪，这一点对于分布式、面向（微）服务的应用来说非常实用。你所要做的就是修改你的JVM启动命令行选项，以加载这些工具。

　　某些工具的开发商还提供了与IDE的集成功能，你只需简单地表示“在运行时开启XYZ性能诊断功能”。我在YouTube上做了一个简单的视频指南，演示了如何对在Eclipse中启动的应用进行追踪。（https://www.youtube.com/watch?v= ... _WxY_6&index=14）

　　◎找出数据库的性能热点

　　即使你已经发现造成应用整体响应时间过长的主要原因在于数据库，但也不要因此就轻率地指责数据库与DBA！造成数据库繁忙的原因可能有以下几种：

　　·对数据库的使用过于低效：错误的查询设计、糟糕的应用程序逻辑、对于数据访问框架的配置不正确

　　·糟糕的数据库设计与数据结构：表的关联、缓慢的存储视图、缺失的或错误的索引、过期的表统计信息

　　·不恰当的数据库配置，例如内存、磁盘、表空间、连接池等等

　　在本文中，我将着重讲解如何在应用程序端将访问数据库所消耗的时间减至最低。

　　诊断糟糕的数据库访问模式

　　在对应用程序进行问题诊断时，我通常总要检查几个数据库访问模式。我会逐个分析应用的请求，并将这些问题分别放入以下这个“DB问题模式”的分类表中：

　　·过多的SQL执行（Excessive SQLs）：执行大量（大于500）不同的SQL语句

　　·N+1次查询问题（N+1 Query）：多次（大于20）执行相同的SQL语句

　　·单一SQL语句执行缓慢（Slow Single SQL）：某个单一的SQL语句执行时间占据了响应时间的80%以上

　　·数据驱动问题（Data-Driven）：同样的请求，由于输入参数的不同，会执行不同的SQL语句

　　·数据库繁忙（Database Heavy）：数据库执行的总体时间占据总体响应时间的60%以上

　　·未经预处理的语句（Unprepared Statements）：在执行相同的SQL时未对语句进行预处理

　　·连接池资源用光（Pool Exhaustion）：由于连接获取时间过长所导致（getConnection的时间超过了executeStatement）

　　·低效的连接池访问（Inefficient Pool Access）：对连接池的访问次数过多（对getConnection的调用超过了executeStatement调用次数的50%）

　　·数据库服务服务器超负荷（Overloaded Database Server）：来自各个应用的请求过多，造成了数据库服务器超负荷

　　想和兴趣相投的朋友们一起交流吗？那就来江苏万和计算机培训中心吧。而江苏万和作为南京专业的Java培训中心，欢迎广大有志于此行业发展的学员们加入。