最大连接池是否还会限制与数据库的最大连接？

Question

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

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

当我使用mysql查看processlist时

show processlist;

它显示最大300等于池大小。它永远不会增加到最大池。我认为池大小意味着要维护连接，以便在将来需要对数据库的请求时可以重用连接，但是当需要时可以建立更多的连接。

另外，当我删除最大池配置时，我立即获得-

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

如何解决此问题。

Answer 1

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

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

所以基本上，当所有300个连接都在使用，而你试图让你的301
ST连接，阿光不会创建一个新的（因为maximumPoolSize是绝对最大值），但它会宁愿等待（默认为30秒），直到连接再次可用。

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

要解决此问题，您必须找出阻止这些连接超过30秒的原因。即使在有1000个并发用户的情况下，如果您的查询最多花费几毫秒或几秒钟也没有问题。

增加泳池大小

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

connections = ((core_count * 2) + effective_spindle_count)

引用关于池大小调整文章：

多年来在许多基准测试中保持良好状态的公式是，为了获得最佳吞吐量，活动连接的数量应接近((core_count * 2) + effective_spindle_count)。即使启用了超线程，核心数也不应包括HT线程。如果完全缓存了活动数据集，则有效主轴数为零，并且随着高速缓存命中率的降低，有效主轴数将接近实际主轴数。…到目前为止，尚未对该公式与SSD的配合情况进行任何分析。

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

增加连接超时

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

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

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

缩短执行时间

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

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

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