最大连接池是否也限制到数据库的最大连接数？

Question

我正在使用hikari cp和spring boot应用程序，它有超过1000个并发用户。我已经设置了最大池大小-

spring.datasource.hikari.maximum-pool-size=300

当我使用

show processlist;

它显示的最大值为300，等于池大小。它永远不会增加超过最大池。这是故意的吗？我认为池大小意味着保持连接，以便在将来需要数据库请求时可以重用连接，但在需要时可以进行更多连接。

另外，当我删除max pool配置时，我会立即得到-

HikariPool-0-连接不可用，请求在30000ms后超时。

如何解决这个问题。提前谢谢。

Answer 1

是的，这是有意的。引用留档：

此属性控制池允许达到的最大大小，包括空闲连接和正在使用的连接。基本上，该值将确定到数据库后端的实际连接的最大数量。合理的值最好由您的执行环境决定。当池达到此大小且没有空闲连接可用时，对getConnection（）的调用将在超时前阻塞最多connectionTimeout毫秒。请阅读有关池大小的信息。默认值：10

因此，基本上，当所有300个连接都在使用中，并且您正试图建立301^st连接时，Hikari不会创建新的连接（因为maximumPoolSize是绝对最大值），而是会等待（默认情况下为30秒），直到连接再次可用。

这也解释了为什么会出现您提到的异常，因为默认值（在未配置maximumPoolSize时）是10个连接，您可能会立即到达。

为了解决这个问题，你必须找出为什么这些连接被阻塞超过30秒。即使在有1000个并发用户的情况下，如果您的查询需要几毫秒或最多几秒钟，也应该没有问题。

如果调用非常复杂的查询需要很长时间，那么有几种可能性。第一个是增加池的大小。但不建议这样做，因为计算最大池大小的建议公式为：

connections = ((core_count * 2) + effective_spindle_count)

引用关于池大小的文章：

一个多年来在许多基准测试中保持良好的公式是，为了实现最佳吞吐量，活动连接的数量应该接近（（core_count*2）effective_spindle_count）。核心计数不应包括HT线程，即使启用了超线程。如果活动数据集被完全缓存，有效主轴数为零，并且随着缓存命中率的下降而接近实际主轴数。...到目前为止，还没有任何关于这个公式在固态硬盘上的效果的分析。

正如同一篇文章中所描述的，这意味着一个4核服务器和一个硬盘应该只有大约10个连接。即使你可能有更多的核心，我假设你没有足够的核心来保证你正在建立的300个连接，更不用说进一步增加了。

另一种可能是增加连接超时。如前所述，当所有连接都在使用时，默认情况下会等待30秒，即连接超时。

您可以增加此值，以便应用程序在超时前等待更长时间。如果复杂查询需要20秒，并且连接池中有300和1000个并发用户，则理论上应将连接超时至少配置为20*1000/300=67秒。

但是请注意，这意味着您的应用程序可能需要很长时间才能向用户显示响应。如果您有67秒的连接超时，并且在复杂查询完成之前还有20秒，那么您的用户可能需要等待一分半钟。

如前所述，您的主要目标是找出查询花费如此长时间的原因。连接池为300，连接超时为30秒，并发用户为1000，这意味着您的查询至少需要9秒才能完成，这是很多。

尝试通过以下方式缩短执行时间：

• 添加适当的索引
• 正确地编写查询
• 改进数据库硬件（磁盘、核心、网络等）
• 通过引入分页来限制正在处理的记录数量
• 分工。看看是否可以将查询拆分为较小的查询，从而生成中间结果，然后在另一个查询中使用，依此类推。只要您不在事务中工作，就可以在事务之间释放连接，从而允许您以牺牲某些性能为代价为多个用户提供服务
• 使用缓存
• 预先计算结果：如果您正在进行一些资源密集型计算，您可以尝试在应用程序不经常使用的时刻（例如，在夜间）预先计算结果，并将这些结果存储在可以轻松查询的其他表中