最近在针对某系统进行性能优化时,发现了一个hive on spark 模式下使用 HikariCP 数据库连接池造成的资源泄露问题,该问题具有普适性,故特地拿出来跟大家分享下。
1 问题描述
-
在微服务中,我们普遍会使用各种数据库连接池技术以加快获取数据库连接并执行数据查询的速度,这本质是一种空间换时间的有效的性能优化的思路。
-
推而广之,在大数据场景下通过JDBC访问HiveServer2并提交数据查询SQL语句时,也很容易想到同样使用数据库连接池技术以加快作业速度。
-
但是相比普通的RDBMS,Hive的JDBC连接更重,以HIVE ON SPARK模式运行作业时更是如此,因为当连接底层需要执行SQL时,HS2会向YARN申请CONTAINER资源,然后启动分布式的SPARK ON YARN集群并分布式地执行编译好的SQL,当该SQL执行完毕后并不会立即释放SAPRK ON YANR资源,而是会等待一段时间以复用这些 SPARK ON YARN资源执行客户端通过该连接提交的新的SQL,只有当该JDBC连接关闭时,或者达到了配置的超时时间而客户端仍没有提交新的SQL时,才会彻底释放这些 SPARK ON YARN 资源。
-
当业务代码使用了数据库连接池技术时,由于其关闭JDBC连接时本质上只是将连接归还给了连接池而没有真是关闭底层的JDBC连接,所以连接背后的 SPARK ON YARN资源并不会被及时释放也就是造成了资源泄露,此时其它作业向YARN申请资源时就需要排队等待,从而影响了其它作业的执行。
-
本案列中该系统使用了HikariCP 数据库连接池,且没有配置数据库连接的空闲超时时长(idletimeout),真