[转帖]TiDB 适配应用实践:MyBatis 3.5.X 在 JDK8 中性能问题的排查与优化

tidb,适配,应用,实践,mybatis,jdk8,性能,问题,排查,优化 · 浏览次数 : 0

小编点评

**内容概述** 文章介绍了 Java 语言源代码中的 bug,并推进了 MyBatis 框架绕开了这个编程语言级的 bug。调整后的应用处理速度大幅提升,在在我们这个场景中提升了一倍以上。 **主要内容** * Java 语言源代码中的 bug,并推进了 MyBatis 框架绕开了这个编程语言级的 bug。 * ADJUSTED 应用处理速度大幅提升,在在我们这个场景中提升了一倍以上。 * MyBatis 的框架绕开了这个编程语言级的 bug。 * 调整后的应用处理速度大幅提升,在在我们这个场景中提升了一倍以上。 **结论** 文章表明 MyBatis 框架绕开了 Java 语言源代码中的 bug,并通过调整后的应用处理速度大幅提升。

正文

https://zhuanlan.zhihu.com/p/371638037

 

作者介绍:PingCAP Tech Center,于旸。

最近有金融客户使用 TiDB 适配批处理场景,数据量在数亿级。对于相同数据量的处理耗时,TiDB 要 35 分钟,而某商业数据库只要 15 分钟,足足相差 20 分钟。从之前的经验来看,在批处理场景上 TiDB 的性能是更优的,这让我们感到困惑。经过一番排查最终定位是批处理程序问题。调整后,在应用服务器有性能瓶颈、数据库压力依然不高且没有进行参数优化的情况下,TiDB 处理时间缩短到 16 分钟。

 

远程排查

 

通过 Grafana 发现执行批处理时数据库集群的资源使用率非常低,判断应用发来的压力较小;将并发数从 40 提高到 100,资源使用率和 QPS 指标几乎没有变化。通过 connection count 监控看到,连接数随着并发数增加而增加,确认并发数修改是生效的。执行 show processlist 发现大部分连接是空闲状态。简单走查了下应用程序代码,是 Spring batch + MyBatis 结构。因为 Spring batch 设置并发的方式很简单,所以考虑线程数的调整应该是生效且可以正常工作的。虽然还没有搞清资源使用率低的问题,但还是有其他收获,ping 应用和 TiDB 集群的网络延迟,达到了 2~3 ms。为了排除高网络延迟的干扰,将应用部署到 TiDB 集群内部运行,批处理耗时从 35 分钟下降到 27 分钟,但依然和某商业数据库的表现有较大差距。因为数据库本身没有压力,所以调整数据库参数也没什么意义。

因为应用提高并发的效果不符合预期,所以考虑线程可能造成了阻塞,但也没有证据,于是想了这样的场景来简单验证到底是应用的问题还是数据库的问题:在 TiDB 集群中创建两个完全相同的 Database,d1 和 d2,使用两个完全相同的批处理应用分别对 d1,d2 中的数据进行处理,等同于双倍压力写入 TiDB 集群,预期结果是对于双倍的数据量,同样可以在 27 分钟处理完,同时数据库资源使用率应大于一个应用的。测试结果符合预期,证明应用没有真正的提高并发。

可能的原因?

1. 应用并发太高,CPU 繁忙导致应用性能瓶颈。

应用服务器的 CPU 消耗只有 6%,不应该存在性能瓶颈。

2. Spring batch 内部有一些元数据表,同时更新元数据表的同一条数据会造成阻塞。

这种情况应该是阻塞在数据库造成锁等待或锁超时,不应该阻塞在应用端。

该如何解决?

1. 多应用部署并发运行,性能随应用部署数线性提升。

不能解决单机应用性能瓶颈问题,对于业务高峰时的拓展也很不方便。

2. 采用异步处理的方案,提高应用吞吐。

目前是有些异步访问数据库的技术,但成熟度低,强烈不建议使用。

 

现场排查

 

为了弄清问题根本原因,来到现场。

  • 现场使用 JDBC 编写了一个 Demo 对问题集群进行压测,发现数据库资源使用率随着 demo 并发数提高而增长,证明提高并发数可以给数据库制造更高的压力,此时完全排除数据库问题的可能。
  • 通过 VisualVM 发现,应用程序的大量线程处于阻塞状态,这种情况线程开的多其实也没用上,实锤性能瓶颈来自应用。

 

 

  • 走查应用代码,发现虽然有用到同步锁等逻辑,但应该不会造成严重的线程阻塞。
  • 通过 dump 发现线程都阻塞在了 MyBatis 的堆栈中,是在源码的这个位置:
@Override
  public Reflector findForClass(Class<?> type) {
    if (classCacheEnabled) {
      // synchronized (type) removed see issue #461
      return MapUtil.computeIfAbsent(reflectorMap, type, Reflector::new);
    } else {
      return new Reflector(type);
    }
  }

这里大致是这样,MyBatis 在进行参数处理、结果映射等操作时,会涉及大量的反射操作。Java 中的反射虽然功能强大,但是代码编写起来比较复杂且容易出错,为了简化反射操作的相关代码, MyBatis 提供了专门的反射模块,它对常见的反射操作做了进一步封装,提供了更加简洁方便的反射 API 。DefaultReflectorFactory 提供的 findForClass()会为指定的 Class 创建 Reflector 对象,并将 Reflector 对象缓存到 reflectorMap 中,造成线程阻塞的就在对 reflectorMap 的操作上。

因为 MyBatis 支持对 ReflectorFactory 自定义实现,所以当时的思路是绕过缓存的步骤,也就是将 classCacheEnabled 设为 false,走 return new Reflector(type) 的逻辑。但依然会在其他调用 ConcurrentHashmap.computeIfAbsent 的地方被阻塞。

到这看起来是一个通用问题,于是将注意力放到 concurrentHashmap 的 computerIfAbsent 上。computerIfAbsent 是 JDK8 中 为 map 提供的新方法。

public V computeIfAbsent(K key, Function<? super K,? extends V> mappingFunction)

它首先判断缓存 map 中是否存在指定 key 的值,如果不存在,会自动调用 mappingFunction (key) 计算 key 的 value,然后将 key = value 放入到缓存 Map。ConcurrentHashMap 中重写了 computeIfAbsent 方法确保 mappingFunction 中的操作是线程安全的。

官方说明中一段:

The entire method invocation is performed atomically, so the function is applied at most once per key. Some attempted update operations on this map by other threads may be blocked while computation is in progress, so the computation should be short and simple, and must not attempt to update any other mappings of this map.

可以看到,为了保证原子性,当对相同 key 进行修改时,可能造成线程阻塞。显而易见这会造成比较严重的性能问题,在 Java 官方 Jira,也有用户提到了同样的问题。

[JDK-8161372] ConcurrentHashMap.computeIfAbsent(k,f) locks bin when k present

很多开发者以为 computeIfAbsent 是不会造成线程 block 的,事实却相反。Java 官方当时认为这个设计是没问题的,不过之后也觉得在性能还不错的 Concurrenthashmap中有这么个拉胯兄弟属实不太合适。最终在 JDK9 中修复了这个问题。

 

验证

 

将现场 JDK 版本升级到 9 ,应用在 500 并发,并排除网络延迟干扰的情况下,批处理耗时 16 分钟。应用服务器 CPU 达到 85% 左右使用率,出现性能瓶颈。理论上,提高应用服务器配置、优化数据库参数都可以进一步提升性能。

 

 

 

当时的结论

 

MyBatis 3.5.X 在缓存反射对象用到的 computerIfAbsent 方法在 JDK8 中性能不理想。需要升级 jdk9 及以上版本解决这个问题。对于 MyBatis 3.5.X 本身,没有针对 JDK8 中的 computerIfAbsent 性能问题进行特殊处理。

升级的路走不通,也可以试着降级到 MyBatis 3.4.X,这个版本还没有引入 computerIfAbsent,理论上没有这个问题。

@Override
public Reflector findForClass(Class<?> type) {
    if (classCacheEnabled) {
            // synchronized (type) removed see issue #461
      Reflector cached = reflectorMap.get(type);
      if (cached == null) {
        cached = new Reflector(type);
        reflectorMap.put(type, cached);
      }
      return cached;
    } else {
      return new Reflector(type);
    }
  }

 

现在的结论

 

MyBatis 官方在收到我们的反馈后,非常效率地 fix 了这个问题。手动点赞。

 

 

 

 

可以看到 MyBatis 官方对 computerIfAbsent 进行了一层封装,如果 value 已存在,则直接 return,这样操作相同 key 的线程阻塞问题就被绕过去了。MyBatis 会在 3.5.7 版本中合入这个 PR。

public class MapUtil {
  /**
   * A temporary workaround for Java 8 specific performance issue JDK-8161372 .<br>
   * This class should be removed once we drop Java 8 support.
   *
   * @see <a href="https://bugs.openjdk.java.net/browse/JDK-8161372">https://bugs.openjdk.java.net/browse/JDK-8161372</a>
   */
  public static <K, V> V computeIfAbsent(Map<K, V> map, K key, Function<K, V> mappingFunction) {
    V value = map.get(key);
    if (value != null) {
      return value;
    }
    return map.computeIfAbsent(key, mappingFunction::apply);
  }

  private MapUtil() {
    super();
  }
}

 

结语

 

经过这次排查,我们发现了 JAVA 语言源代码中的 bug,并且进一步推进了已经受这个 bug 影响的 MyBatis 框架绕开了这个编程语言级的 bug。调整后的应用处理速度大幅提升,在我们这个场景中提升了一倍以上。相信对于使用应用开发框架 MyBatis 的企业来说会提供巨大帮助。

与[转帖]TiDB 适配应用实践:MyBatis 3.5.X 在 JDK8 中性能问题的排查与优化相似的内容:

[转帖]TiDB 适配应用实践:MyBatis 3.5.X 在 JDK8 中性能问题的排查与优化

https://zhuanlan.zhihu.com/p/371638037 作者介绍:PingCAP Tech Center,于旸。 最近有金融客户使用 TiDB 适配批处理场景,数据量在数亿级。对于相同数据量的处理耗时,TiDB 要 35 分钟,而某商业数据库只要 15 分钟,足足相差 20 分

[转帖]tidb backup

https://docs.pingcap.com/zh/tidb/v4.0/sql-statement-restore BACKUP 语句使用的引擎与 BR 相同,但备份过程是由 TiDB 本身驱动,而非单独的 BR 工具。BR 工具的优势和警告也适用于 BACKUP 语句。 执行 BACKUP 需

[转帖]使用 TiUP 升级 TiDB

本文档适用于以下升级路径: 使用 TiUP 从 TiDB 4.0 版本升级至 TiDB 7.1。 使用 TiUP 从 TiDB 5.0-5.4 版本升级至 TiDB 7.1。 使用 TiUP 从 TiDB 6.0-6.6 版本升级至 TiDB 7.1。 使用 TiUP 从 TiDB 7.0 版本升级

[转帖]操作系统性能参数调优

https://www.bookstack.cn/read/TiDB-4.0/tune-operating-system.md 本文档仅用于描述如何优化 CentOS 7 的各个子系统。 注意: CentOS 7 操作系统的默认配置适用于中等负载下运行的大多数服务。调整特定子系统的性能可能会对其他子

[转帖]tidb集群部署

http://blog.itpub.net/29785807/viewspace-2789852/ 一.安装规划 1 2 3 4 5 6 使用15台服务器 5台tidb服务器:每台3个tidb实例+1个pd+1个pump 10台tikv服务器:每台4个tikv实例 drainer_servers 安

[转帖]tidb 修改root密码

http://blog.51yip.com/tidb/2452.html 通过 {pd-ip}:{pd-port}/dashboard 登录 TiDB Dashboard,登录用户和口令为 TiDB 数据库 root 用户和口令。如果你修改过数据库的 root 密码,则以修改后的密码为准,默认密码为

[转帖]tidb 搭建私有镜像库

https://docs.pingcap.com/zh/tidb/stable/tiup-mirror 在构建私有云时,通常会使用隔离的网络环境,此时无法访问 TiUP 的官方镜像。因此,TiUP 提供了构建私有镜像的方案,它主要由 mirror 指令来实现,该方案也可用于离线部署。使用私有镜像,你

[转帖]tidb 如何对 TiDB 进行 TPC-C 测试

https://docs.pingcap.com/zh/tidb/stable/benchmark-tidb-using-tpcc TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试,其中包含五类事务: NewOrder – 新订单的生成

[转帖]TiDB 环境与系统配置检查

https://docs.pingcap.com/zh/tidb/stable/check-before-deployment 在 TiKV 部署目标机器上添加数据盘 EXT4 文件系统挂载参数 生产环境部署,建议使用 EXT4 类型文件系统的 NVME 类型的 SSD 磁盘存储 TiKV 数据文件

[转帖]TIDB-TIDB节点磁盘已满报警

一、背景 今日突然收到tidb节点的磁盘报警,磁盘容量已经超过了80%,但是tidb是不放数据的,磁盘怎么会满,这里就需要排查了 二、问题排查 解决步骤 1.df -h查看哪里占用磁盘比较多,然后通过du -h找到具体占用多的目录 2.最终发现tidb/tidb-deploy/tidb-4000/l