快被系统性能逼疯了？你需要这份性能优化策略(3)

解决方法：采用更高效的算法、数据结构替换原来消耗CPU的代码，或者采用新的设计绕过瓶颈代码，比如查找数据的逻辑，可以把List改为Map，以空间换时间；比如用Json报文替换XML报文，提高传输、解析和打印日志的效率。

导致Cpu计算资源高消耗的代码：报文格式转换、加解密、正则表达式、低效的循环、低效的正则表达式。

排查方法：

• 压测进行时，使用jvisualvm工具远程连接应用，点抽样器àCPU，点快照生成线程快照。采样一段时间后，抽样器会显示各个方法占用cpu时间，可以针对CPU时间占用高的方法进行优化。

• 使用tprofiler，jprofiler，OracleDeveloperStudio12.6-linux-x86工具分别分析消耗CPU时间长的方法，以上工具分析结果可能有些差别。针对CPU计算耗时最长的方法进行优化。

9、批处理时间长、数据库逐笔插入缓慢

问题现象：大批量数据（10万条以上）更新或插入数据库，耗时较长。

问题原因：批量数据处理时，如果逐条更新数据库，则会存在大量网络io、磁盘io，耗时较长，而且对数据库资源消耗较大。

解决方法：

• 采用java提供的batchUpdate方法批量更新数据库，每1000条commit一次，可大幅提高数据更新效率。

• 单线程改成线程池，并行处理，充分利用多核CPU，通过数据库或者其他同步锁控制并行性；增加缓冲池，降低数据库或磁盘IO访问频次。

10、数据库CPU高

问题现象：后台指令发送满负荷工作时，数据库CPU高。

问题原因：后台指令发送线程每次对全量查询结果排序，结果集很大，然后取一条记录；索引区分度不高，满负荷执行时；查询频率很高；压测显示，并行发送指令的后台线程越多，数据库CPU越高，效率越低。

解决方法：

• 去掉ORDER BY，增加索引后，效果不明显。因为结果集大和查询频繁两个问题没有解决，因此考虑使用设计新的方案。

• 新方案：设计指令发送线程池，生产者线程每台任务服务器只有一个线程，负责查询待发送指令，每次查询50条指令。每条指令包装成一个Runnable对象，放进ThreadPoolExecutor线程池，线程池大小参数设置为100或200。每当线程池满时，生产者停止生产指令，休息15秒后继续。消费者线程即线程池里的线程，参数设置为4，8或12（和不同指令类型的指令数据量成正比）。

改进后的方案，数据库CPU降到10%一下，发送效率单机提升6倍，且可线性扩展任务服务器。

11、压测TPS曲线剧烈下降或抖动

问题现象：50并发压测，TPS曲线正常应该是平缓的，波动不大，如果突然出现剧烈下降，并且短时间内无法恢复，则可能存在问题。

问题原因：一般是由于前置或bp的jvm进行垃圾回收，或者日志记录磁盘满导致的。

解决方法：如果不是特别剧烈的波动或者TPS曲线下降后长时间不反弹，则可以忽略该问题。否则，需要分析曲线下降的时刻，系统当时正在发生的事情。可以通过top命令监控当时CPU占用比价高的线程，也可以kill -3 pid杀javacore来查看线程堆栈。

六、优化案例

1、网银系统基本情况

1） 压测环境系统架构

压测环境不包括F5，只有1台WEB、1台前置（应用服务器）、1台BP（业务处理服务器）、1台DB、1台Redis服务器。

2）客户请求链路：

客户端压力机-〉Web-〉PRE-〉BP-〉DB2 ；

客户端压力机-〉Web-〉PRE-〉BP-〉挡板服务器（模拟后端服务方）。

3）系统特点：

• 用户、账号权限校验较多。

  对公业务典型场景：经办、审核、查询、下载、批量。用户权限通过业务链控制。

• 接口调用较多，且由前端组合调用接口。

  前后端分离，前端通过调用一个个接口来完成业务。接口粒度较细。登陆、支付转账经办需要15~19个接口完成一次交易。

• 强一致性、高可用性。

  资金交易系统，一致性需要通过数据库来保证。

4）网银登录压测曲线

2、数据库消息队列案例（指令发送队列）

需求是：对于需要异步处理的交易指令，需要设计一个基于数据库的消息队列，我们称之为指令发送队列。该队列既要满足服务器的性能约束，又要满足每日处理交易量的要求。

1）优化前处理过程

后台任务每次从数据库指令表中排序并取最早的一条指令，获取该指令的详细交易信息，组装成报文并调用接口发送后台核心系统。

在压测环境下，该方案如果配置一个后台任务，无法达到系统设计的指令处理速度；如果配置多个后台任务，则会导致数据库CPU占用较高，影响其他联机业务的开展。

2）优化后处理过程

每台后台任务服务器配置一个生产者任务，20个消费者任务。

生产者任务一次取100个（可配置）指令，依次分配给20个消费者任务中空闲的任务，消费者任务获取指令详细信息，并组装报文后发送后台核心系统；生产者任务如果发现无空闲消费者任务，则等待15s后重新判断。

此方案显著降低了数据库CPU负载，合理利用了应用服务器的并发能力，处理效率大为提高，以上线程数和每次获取的指令数可以配置。

指令发送线程池模型图：

3、数据库死锁案例

1）死锁问题现象

（编辑：ASP站长网）