性能调试

      项目中曾经有过大约三个月的时间用来做性能调试，说是性能调试，不如说是用三个月时间来集中解决项目的性能问题，这里回顾一下当时的步骤、使用的工具和当时的一些常出现的问题，以备后用。

 

使用的工具：

1. Windows Performance Monitor， 比较好的工具，因为工具本身不对应用程序有任何影响，记录的数据可以很大，直接使用Excel的相关功能转化为曲线图或者其它的图，非常直观，但其记录的是JVM所占用的内存，不能细致到对象，是一个粗线条的性能数据的记录；
2. JProfiler，能够记录JVM中对象占用的堆，方法的执行时间，线程状态，利用此工具，可以详细研究系统中哪些方法可以进行优化，哪些地方出现了内存泄露，哪些线程出现死锁；
3. Log，主要是系统开发过程中自己加入的Log，确定任务是否正确执行，是否出现不正常的异常处理、阻塞，出现偶发性问题时记录良好的Log是解决问题的最佳途径；
4. 数据库管理工具，主要用来查看数据库连接的情况；

步骤：

1. 利用QA开发的模拟服务器设置多台服务器，并设置这些服务器的相关参数，如哪些设备有问题，何时发送Trap或者Event，发送的Trap和Event的类型和频率等等；
2. 使用Windows Perfomance Monitor 或者JProfiler监测Tomcat应用；
3. 在Tomcat启动参数中增加-verbosegc，将JVM的GC信息输出到log；
4. Discovery多台设备，并增加多个Task Schedule，并持续运行系统72小时或以上；
5. 监测系统的内存、CPU、线程、IO以及数据库连接的情况，确定是否运行正常；
6. 操作该应用系统，确定是否有不可接受的页面响应；
7. 分析Performance数据，查看Task运行过程中系统是否处于健康状态（CPU利用率不能超过50%）；
8. 查看GC数据，看GC时间是否合理，确定设置的heap值是否合理，也可以看操作页面时是否会出现停滞情况，GC运行时会影响JVM其它线程的运行，heap值过小，会导致GC频率增加，heap值过大，则会导致GC的时间过长，可能会导致假死机；

常出现的问题（感觉虽然性能调试说起来很神秘，但出错的地方却大部分是程序中的低级错误）：

1. 文件操作或者数据库操作不关闭资源，或者关闭资源不当，当异常发生时出现泄漏：项目中曾经出现过应用所占用的Handles随着时间的增加有规律的增加，与系统定义的任务相同，怀疑是线程问题或者是数据库连接没有正确关闭，经过查证发现是数据库连接没有及时关闭，虽然系统有统一的数据库连接池供使用，但出问题的地方没有使用平台提供的数据库连接池，而是独自建立了数据库连接，但是又没有及时关闭，导致问题出现；
2. 没有使用正确的线程池，或者说没有限制线程的个数，导致系统瞬间达到一个峰值，出现OutOfMemory：项目中使用UDP连接接收客户端发来的事件，首先由一个线程accept客户端的连接，接收到以后new一个新的线程处理该连接的内容，正常情况下都没有问题，当模拟的客户端都在同一个时间段高频的发送事件时，服务器new的线程就会瞬间达到一个峰值，出现问题，解决的方式就是控制new的线程的数量，使用一个有限缓存队列来缓存accept的socket连接，并且采取一定的丢弃策略当缓存队列满时丢弃一定的事件，保证系统的正常运行。这里也引申出一个问题，就是系统中的各种缓存队列一定要限制一个上限，除非你能十分肯定该队列不会出现内存无限增长的问题；
3. 另外，通过观察JProfiler中各个方法的执行时间和执行次数，我们可以很容易的得出改进哪些方法可以明显提高系统效率，那么我们可以着重审查这些代码，修改其中的低效操作；
4. 有些时候由于在一个数据库事务中有过多的操作，会导致数据库死锁的出现，没有总结出能够完全避免死锁的方法，但是需要在开发过程中尽量减小事务的持续时间，并且如果可以的话，大家都按照一定的顺序操作数据库表，比如如果可以，都按照字母表的顺序去操作数据库表，可以明显减少死锁出现的概率；
5. 使用Sql相关分析工具分析Sql的执行时间，并针对执行时间长频率高的Sql进行优化。

偶发问题如何定位：

      感觉偶发问题十分令人头疼，也没有很好的解决方法，需要注意如下几个方面：

1. 需要对整个系统十分熟悉；
2. 详细的Log是解决偶发问题的关键所在，但在开发测试阶段可以开启Debug log，而在运行阶段是不大可能记录很详细的log；
3. 解决偶发问题一定要细心，仔细研究Log中的可能问题