hikariCP 数据库连接池配置
输出指标说明打印指标的格式为{连接池名称}.pool.{指标}指标解释在运维时的作用活跃连接数此数据长期保持最大连接数值的时候可以尝试扩大连接数空闲连接数此数据过高的时候可以尝试减少配置中的最小连接数配置的最大连接数配置的最小连接数排队等待连接的线程数如果此数据持续飙高,表示连接池中已经没有空闲线程了当前总连接数创建新连接的耗时此数据主要反应当前服务到数据服务的网络延迟创建新连接的超时如果经常创建
springBoot 项目默认自动使用 HikariCP ,HikariCP 的性能比 alibaba/druid快。
一、背景
系统中多少个线程在进行与数据库有关的工作?其中,而多少个线程正在执行 SQL 语句?这可以让我们评估数据库是不是系统瓶颈。
-
多少个线程在等待获取数据库连接?获取数据库连接需要的平均时长是多少?数据库连接池是否已经不能满足业务模块需求?如果存在获取数据库连接较慢,如大于 100ms,则可能说明配置的数据库连接数不足,或存在连接泄漏问题。
-
哪些线程正在执行 SQL 语句?执行了的 SQL 语句是什么?数据库中是否存在系统瓶颈或已经产生锁?如果个别 SQL 语句执行速度明显比其它语句慢,则可能是数据库查询逻辑问题,或者已经存在了锁表的情况,这些都应当在系统优化时解决。
-
最经常被执行的 SQL 语句是在哪段源代码中被调用的?最耗时的 SQL 语句是在哪段源代码中被调用的?在浩如烟海的源代码中找到某条 SQL 并不是一件很容易的事。而当存在问题的 SQL 是在底层代码中,我们就很难知道是哪段代码调用了这个 SQL,并产生了这些系统问题。
在研究HikariCP的过程中,这些业务关注点我发现在连接池这层逐渐找到了答案。
JBDC背景
JABC是JAVA访问关系型数据库的标注API,它为各种关系型数据的访问提供统一的接口标准,然后,各个关系型数据库厂商按照JBDC的标准,提供能使JAVA访问的驱动包。一般情况下,在JAVA中执行一条SQL语句,需要以下几个步骤:
状态JDBC驱动程序
-
建立数据库连接
-
创建数据库操作对象
-
访问数据库,执行SQL语句
-
处理返回结果集
-
断开数据库连接
其中第2步的连接需经历一下步骤: -
与数据建立TCP连接的三次握手
-
数据库账号密码认证的通信
-
sql执行与返回的通信
= 关闭TCP连接的4次握手
由此看出,执行一个sql的开销是比较大的,因此,为了节省资源提高效率,使用数据库连接池是很有必要的
二、配置
pom 引入
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
</dependency>
增加监控配置类
import com.codahale.metrics.MetricRegistry;
import com.codahale.metrics.Slf4jReporter;
import com.zaxxer.hikari.HikariDataSource;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.autoconfigure.jdbc.DataSourceProperties;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.util.StringUtils;
import java.util.concurrent.TimeUnit;
@Configuration
public class DatasourceConfiguration {
private final static Logger LOGGER = LoggerFactory.getLogger(DatasourceConfiguration.class);
@Bean
@ConfigurationProperties(prefix = "spring.datasource.hikari")
HikariDataSource dataSource(DataSourceProperties properties) {
HikariDataSource dataSource = properties.initializeDataSourceBuilder()
.type(HikariDataSource.class)
.build();
if (StringUtils.hasText(properties.getName())) {
dataSource.setPoolName(properties.getName());
}
dataSource.setMetricRegistry(initMetricRegistry(dataSource.getPoolName()));
return dataSource;
}
/**
* 配置指标监控
* @param poolName
* @return
*/
public MetricRegistry initMetricRegistry(String poolName) {
MetricRegistry metricRegistry = new MetricRegistry();
Slf4jReporter reporter = Slf4jReporter.forRegistry(metricRegistry)
.outputTo(LOGGER)
.convertRatesTo(TimeUnit.SECONDS)
.convertDurationsTo(TimeUnit.MILLISECONDS)
.build();
reporter.start(30, TimeUnit.SECONDS);//30秒打印一次
return metricRegistry;
}
项目启动后控制台会打印监控日志
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.ActiveConnections, value=0
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.IdleConnections, value=5
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.MaxConnections, value=40
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.MinConnections, value=5
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.PendingConnections, value=0
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=GAUGE, name=pdmHikariCP.pool.TotalConnections, value=5
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=HISTOGRAM, name=pdmHikariCP.pool.ConnectionCreation, count=84, min=752, max=10874, mean=825.1112278127991, stddev=106.00103981809646, median=793.0, p75=817.0, p95=1248.0, p98=1248.0, p99=1248.0, p999=1248.0
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=HISTOGRAM, name=pdmHikariCP.pool.Usage, count=7, min=0, max=948, mean=148.27471786535676, stddev=322.1937983856062, median=3.0, p75=103.0, p95=948.0, p98=948.0, p99=948.0, p999=948.0
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=METER, name=pdmHikariCP.pool.ConnectionTimeoutRate, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second
17:22:56.072 [metrics-logger-reporter-1-thread-1] [traceId= spanId=] INFO avicit.pdm.config.DataSourceConfig - type=TIMER, name=pdmHikariCP.pool.Wait, count=7, min=0.0128, max=78.9716, mean=55.49616178913166, stddev=34.76115035148255, median=76.7992, p75=77.636, p95=78.9716, p98=78.9716, p99=78.9716, p999=78.9716, mean_rate=0.006881493151999419, m1=3.2892511143081085E-8, m5=0.02117048948569106, m15=0.19678830181225304, rate_unit=events/second, duration_unit=milliseconds
springboot hikariCP 配置文件配置
spring:
datasource:
name: database-a
driver-class-name: com.mysql.cj.jdbc.Driver # MySQL 驱动,这里根据引入的 mysql-connector-java 包版本选择不同的 Driver, 8.x 需要用 cj
url: jdbc:mysql://mysql:3306/database-a?useUnicode=true&characterEncoding=utf-8&serverTimezone=GMT%2B8&allowMultiQueries=true
username: root
password: 1
type: com.zaxxer.hikari.HikariDataSource # JDBC 连接池类型:HikariCP
hikari:
connection-timeout: 30000 # 等待连接池分配链接的最大时长(毫秒),超过这个时长还没有可用的连接则发生 SQLException,默认:30 秒
minimum-idle: 5 # 最小连接数
maximum-pool-size: 20 # 最大连接数
auto-commit: true # 自动提交
idle-timeout: 600000 # 连接超时的最大时长(毫秒),超时则被释放(retired),默认:10 分钟
pool-name: DataSourceHikariCP # 连接池名称
max-lifetime: 1800000 # 连接的生命时长(毫秒),超时而且没被使用则被释放(retired),默认: 30 分钟
connection-test-query: select 1```
hikariCP 配置参数
下面给出详细的配置信息:
使用率较高
- autoCommit:用于控制从池中返回连接的默认自动提交行为,默认为true
connectionTimeout:客户端等待池中连接的最大事件(毫秒),超时则会抛出 -SQLException,最低可接受时间为 250ms,默认值为30000ms - idleTimeout:池中连接保持空闲状态的最长时间,只有在定义的minimumIdle 小于- – maximumPoolSize时生效,允许的最小时间为 10000ms。默认为 600000ms
- keepaliveTime:用于控制 HikariCP 中空闲线程的最大存活时间,该值必须小于- - - - maxLifetime,最小为 30000ms。默认为 0 (disabled)
- maxLifetime:控制连接池中连接的最长时间,正在使用的连接不会被删除,只有当其关闭连接后才会被删除,当设置为 0 时表示永不删除,最小允许值为 30000ms。 默认值为 1800000ms
- connectionTestQuery:当使用的驱动为 JDBC4 时不建议设置该项。
- minimumIdle:控制 HikariCP 中维护的最小空闲连接数。当空闲连接数小于 - - - – - minimumIdle 并且池中的总连接数少于 maximumPoolSize 时,HikariCP 将添加其他连接直到 maximumPoolSize。为了获得最佳性能和对峰值需求的响应能力建议不要设置此值。 默认值与 maximumPoolSize 相同
- maximumPoolSize:连接池中的最大连接数。默认为 10
- metricRegistry:该项仅在编程式配置或IoC容器中使用,允许指定一个 Codahale/Dropwizard MetricRegistry 的实例来记录池中的各项指标
- healthCheckRegistry:同上,用于报告当前连接池的健康状况
poolName:定义连接池的名称,可以在日志或控制台识别连接池
不常使用
- initializationFailTimeout:允许初始化失败的次数。默认值为 1
- isolateInternalQueries:控制 HikariCP 是否在其自己的事务中隔离内部池查询,仅在禁用 autoCommit 时适用。默认值为 false
- allowPoolSuspension:控制连接池是否可以通过JMX暂停和恢复,当连接池暂停时,对 getConnection() 的调用永不超时,直到连接池恢复。默认为 false
- readOnly:控制从池中获取的连接是否默认为只读。默认为 false
- registerMbeans:控制是否注册JMX Management Bean (MBean)。默认值为 false
- catalog:为支持目录概念的数据库设置默认目录。如果未指定此属性,则使用 JDBC 驱动程序定义的默认目录。默认值为 driver default
- connectionInitSql:设置一个 SQL 语句,该语句将在每次创建新连接后执行,然后再将其添加到池中。如果此 SQL 无效或引发异常,它将被视为连接失败,并且将遵循标准的重试逻辑。
- driverClassName:HikariCP 将尝试通过基于 jdbcUrl 的 DriverManager 解析驱动程序,但对于一些较旧的驱动程序,必须指定 driverClassName
- transactionIsolation:控制从池中返回连接的默认事务隔离级别。如果未指定此属性,则使用 JDBC 驱动定义的默认事务隔离级别。默认值为 driver default
- validationTimeout:控制用于测试连接的最长存活时间,该值必须小于 - - - connectionTimeout,最短时间为 250ms。默认值为 5000ms
- leakDetectionThreshold:控制在log日志记录可能发生连接泄漏的消息之前,连接可以离开池的时间。值为 0 表示禁用泄漏检测。启用泄漏检测的最低时间为 2000ms。 默认值为 0
- dataSource:仅可通过编程式配置或IoC容器使用。通过此属性可以直接设置 DataSource 要由池包装的的实例,而不必让 HikariCP 通过反射进行构造
- schema:为支持 schema 概念的数据库设置默认的 schema,如果未指定此属性,则使用 JDBC 驱动定义的默认模式。
- threadFactory:仅可通过编程式配置或IoC容器使用。此属性允许通过 java.util.concurrent.ThreadFactory 创建池使用的所有线程
- scheduledExecutor:仅可通过编程式配置或IoC容器使用。此属性允许通过 java.util.concurrent.ScheduledExecutorService 设置实将用于各种内部任务的调度。
三、HikariCP監控指标介绍和应用
输出指标说明
打印指标的格式为{连接池名称}.pool.{指标}
指标 | 解释 | 在运维时的作用 |
---|---|---|
ActiveConnections | 活跃连接数 | 此数据长期保持最大连接数值的时候可以尝试扩大连接数 |
IdleConnections | 空闲连接数 | 此数据过高的时候可以尝试减少配置中的最小连接数 |
MaxConnections | 配置的最大连接数 | |
MinConnections | 配置的最小连接数 | |
PendingConnections | 排队等待连接的线程数 | 如果此数据持续飙高,表示连接池中已经没有空闲线程了 |
TotalConnections | 当前总连接数 | |
ConnectionCreation | 创建新连接的耗时 | 此数据主要反应当前服务到数据服务的网络延迟 |
ConnectionTimeoutRate | 创建新连接的超时 | 如果经常创建连接超时这个时候需要排查数据服务或者网络通讯是否异常 |
Usage | 连接被复用时长 | 此参数表示连接池中一个连接从返回连接池到再次被复用的时间间隔,表示数据访问频繁程度,对于使用较长的间隔可以尝试减少连接数 |
Wait | 获取连接的等待耗时 | 可以和PendingConnections结合分析连接池情况。 |
Wait和PendingConnections结合分析连接池情况
-
如果排队多等待短:此时表示数据访问频繁可以尝试扩大连接数;
-
如果排队少等待长:此时连接中存在慢查询或者比较大的事务;
-
如果排队多等待长:此时可能是数据访问压力过大且存在大量慢查询,但实际上如果频繁出现慢查询很有可能是程序或者业务上出现了问题,需要对业务和代码进行排查。这种时刻也能网络出现异常导致所有查询都变得非常慢;
输出度量说明
属性 解释
count | 指标记录次数 |
---|---|
min | 最小记录数 |
min | 最大记录数 |
mean | 平均值 |
stddev | 标准差 |
median | 中位数 |
p75 | 75百分位数 |
p95 | 95百分位数 |
p98 | 98百分位数 |
p99 | 99百分位数 |
p999 | 99.9百分位数 |
mean_rate | 平均耗时 |
m1 | 1分钟内记录平均数 |
m5 | 5分钟记录平均数 |
m15 | 15分钟记录平均数 |
duration_unit | 统计单位 |
rate_unit | 记录单位(events/second 为 事件次数/每秒钟) |
四、 手动方式获取连接池指标信息
有时候因为业务需要我们可以从DataSource中直接获取指标数据进行处理
@Autowired
DataSource dataSource;
@Value("${datasource.name:test}")
String poolName;
@RequestMapping("/getInfo")
public String getInfo() throws SQLException {
String indexName = poolName + ".pool.";
MetricRegistry metricRegistry = (MetricRegistry) ((HikariDataSource) dataSource).getMetricRegistry();
SortedMap<String, Gauge> gauges = metricRegistry.getGauges();
Gauge activeConnections = gauges.get(indexName + "ActiveConnections");
Object activeConnectionsV = activeConnections.getValue();
log.info("activeConnections : " + activeConnectionsV);
Gauge IdleConnections = gauges.get(indexName + "IdleConnections");
Object IdleConnectionsV = IdleConnections.getValue();
log.info("IdleConnections : " + IdleConnectionsV);
Gauge MaxConnections = gauges.get(indexName + "MaxConnections");
Object MaxConnectionsV = MaxConnections.getValue();
log.info("MaxConnections : " + MaxConnectionsV);
Gauge MinConnections = gauges.get(indexName + "MinConnections");
Object MinConnectionsV = MinConnections.getValue();
log.info("MinConnections : " + MinConnectionsV);
Gauge PendingConnections = gauges.get(indexName + "PendingConnections");
Object PendingConnectionsV = PendingConnections.getValue();
log.info("PendingConnections : " + PendingConnectionsV);
Gauge TotalConnections = gauges.get(indexName + "TotalConnections");
Object TotalConnectionsV = TotalConnections.getValue();
log.info("TotalConnections : " + TotalConnectionsV);
SortedMap<String, Histogram> histograms = ((MetricRegistry) metricRegistry).getHistograms();
Histogram ConnectionCreation = histograms.get(indexName + "ConnectionCreation");
Object ConnectionCreationV = ConnectionCreation.getCount();
Snapshot snapshot = ConnectionCreation.getSnapshot();
log.info("ConnectionCreation : " + ConnectionCreationV);
Histogram Usage = histograms.get(indexName + "Usage");
Object UsageV = Usage.getCount();
log.info("Usage : " + UsageV);
SortedMap<String, Meter> meters = ((MetricRegistry) metricRegistry).getMeters();
Meter meter = meters.get(indexName + "ConnectionTimeoutRate");
long count = meter.getCount();
log.info("ConnectionTimeoutRate : " + count);
SortedMap<String, Timer> timers = ((MetricRegistry) metricRegistry).getTimers();
Timer timer = timers.get(indexName + "Wait");
long count1 = timer.getCount();
log.info("Wait : " + count1);
return "";
}
五、常见数据库连接池对比
5.1 功能对比
1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。
2:druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性。
3:综合性能,扩展性等方面,可考虑使用druid或者hikariCP连接池。
4:可开启prepareStatement缓存,对性能会有大概20%的提升。
功能角度考虑,Druid 功能更全面,除具备连接池基本功能外,还支持sql级监控、扩展、SQL防注入等。最新版甚至有集群监控
单从性能角度考虑,从数据上确实HikariCP要强,但Druid有更多、更久的生产实践,它可靠。
单从监控角度考虑,如果我们有像skywalking、prometheus等组件是可以将监控能力交给这些的 HikariCP也可以将metrics暴露出去。
5.2 数据库连接池优化
数据库连接池优化配置(druid,dbcp,c3p0)
主要描述了数据库连接池参数配置的准则,针对常用的数据库连接池(c3p0,dbcp,druid)给出推荐的配置。
考虑因素
- 1当前连接DB的规模
- 2:并发情况
- 3:执行db的响应时间
-
初始化连接:可考虑设置为3个连接 。对于db规模特别大的情况下可考虑设置为1个。避免启动时间过长;
-
最小连接:可考虑该值的设置和初始化连接保持一致;
-
最大连接:对于有较大DB规模,最大连接不要设置过大,避免本地维护的db太大。 如果对应到数据源的并发数过高,可考虑增大最大连接数。
-
获取连接的超时时间:如果连接全部被占用,需要等待的时间。可以根据当前系统的响应时间判定,如果容忍度较高,可以大点。容忍度较低,设置小点。
-
当获取连接和释放连接心跳检测:建议全部关闭,否则每个数据库访问指令会对数据库生产额外的两条心跳检测的指令,增加数据库的负载。连接有效性的检查改用后台空闲连接检查。
-
连接有效性检测时间:该值需要结合数据库的wait_timeout,interactive_timeout值进行设置。假如数据库为120s,则心跳检测时间在120s以内越大越好。如果太小,心跳检测时间会比较频繁。建议设置为90s。
-
最大空闲时间:如果连接超过该时间没有使用过,则会进行close掉。 该值不要太小,避免频繁的建立连接关闭连接。也不要太大,导致一直无法关闭。
-
心跳检查的sql语句:尽量使用ping命令,ping的性能较查询语句高。大部分的数据库连接池不配置query语句,便会调用ping命令。
-
prepareStatement缓存:可以根据自己的业务来判定是否开启。开启后对性能的影响依赖于具体业务和并发情况。可考虑暂时不开启。
-
连接使用超时:业务拿到一个连接,如果超过指定的时间未归还,是否把该连接给给回收掉。超时时间等和具体的业务关联。暂时建议先不开启。
六、常见数据库配置参数
6.1 druid配置
配置说明:
-
minEvictableIdleTimeMillis(最大空闲时间):默认为30分钟,配置里面不进行设置。
-
testOnBorrow ,testOnReturn 默认为关闭,可以设置为不配置。
-
testWhileIdle(在获取连接后,确定是否要进行连接空闲时间的检查)。默认为true。配置里面不再进行设置。
流程说明:
-
在第一次调用connection的时候,才会进行 initialSize的初始化。
-
心跳检测时间线程,会休眠timeBetweenEvictionRunsMillis时间,然后只对(没有borrow的线程 减去 minIdle)的线程进行检查,如果空闲时间大于minEvictableIdleTimeMillis则进行close。
-
testWhileIdle必须设置为true,在获取到连接后,先检查testOnBorrow,然后再判定testwhileIdle,如果连接空闲时间大于timeBetweenEvictionRunsMillis,则会进行心跳检测。
-
不需要配置validationQuery,如果不配置的情况下会走ping命令,性能更高。
-
连接保存在数组里面,获取连接的时候,获取数组的最后一位。在timeBetweenEvictionRunsMillis时是从前往后进行检查连接的有效性。
6.2 dbcp配置
配置说明:
-
关于maxidle和maxTotal尽量保持一致。
-
numTestsPerEvictionRun 设置为-1,代表对所有的连接均进行检查。默认值为3。-1代表对全部idle的连接检查有效性。 否则有可能造成部分连接的有效性未进行检查。
-
testWhileIdle 也必须为true,代表需要检查有效性。
-
minEvictableIdleTimeMillis默认值为30分钟,可以不用进行设置。
-
testOnReturn默认值为false,可以不用设置。但是testOnBorrow必须进行设置为false,默认值为true。
-
validationQuery不配置默认走ping命令
流程说明:
-
在第一次调用connection的时候,才会进行 initialSize的初始化。
-
不需要配置validationQuery,如果不配置的情况下会走ping命令,性能更高。
-
连接保存在LinkedBlockingDeque 中。来做并发的控制。
-
后端会有一个定时任务,间隔为timeBetweenEvictionRunsMillis,先确定需要对多少线程进行检测(numTestsPerEvictionRun控制),然后判定是否超过minEvictableIdleTimeMillis,如果超过则close掉。没有超过,则判定testWhileIdle为true的话,进行心跳检查。如果检查失败则关闭连接。
-
在return连接的时候会判定maxIdle,如果当前空闲连接是否大于maxIdle,则会关闭掉连接。
6.3 c3p0配置
配置说明:
-
testConnectionOnCheckout和testConnectionOnCheckin默认为false,可不用配置
-
preferredTestQuery不用配置,默认走ping命令。
-
numHelperThreads 默认是开启3个线程。如果数据源较多,这里会存在较多线程。 这里设置为1,避免线程较多的情况。
流程说明:
-
在第一次调用connection的时候,才会进行 initialPoolSize的初始化。
-
在进行心跳检测的时候,会对所有的空闲连接进行心跳检测。如果发现总连接小于最小连接数,则会创建连接,保持最小的连接数。
更多推荐
所有评论(0)