mysql - Slick with Hikari 在需要时不要使用更多连接

Question

我想了解 Slick-Hikari 的工作原理，我已经阅读了很多文档，但我有一个我不理解其行为的用例。

我在默认配置下将 Slick 3 与 Hikari 一起使用。我已经有一个同时连接约 1000 个用户的生产应用程序。我的应用程序与 websockets 一起工作，当我部署新版本时，所有客户端都会重新连接。 (我知道这不是处理部署的最佳方式，但我目前没有集群。)当所有这些用户重新连接时，他们都开始查询以获取他们的用户状态(dog-pile 效应)。当它发生时，Slick 开始抛出很多错误，例如:

java.util.concurrent.RejectedExecutionException: Task slick.backend.DatabaseComponent$DatabaseDef$$anon$2@4dbbd9d1 rejected from java.util.concurrent.ThreadPoolExecutor@a3b8495[Running, pool size = 20, active threads = 20, queued tasks = 1000, completed tasks = 23740]

我认为正在发生的事情是等待查询的光滑队列已满，因为它无法处理所有从数据库请求信息的客户端。但是，如果我看到 Dropwizard 提供给我的指标，我会看到以下内容:

接近 16:45 我们进行了部署。在旧实例终止之前，我们可以看到连接数从 20 增加到 40。考虑到部署过程的完成方式，我认为这是正常的。

但是，如果 Slick 的查询队列由于狗桩效应而变满，为什么它有 20 个可用连接时它不使用超过 3-5 个连接？数据库的性能非常好，所以我认为瓶颈在 Slick。

对于改进此部署过程，您有什么建议吗？我现在只有 1000 个用户，但几周后我会有更多用户。

Answer 1

基于“被拒绝”的异常，我认为很多slick Action 被并发提交给slick，超过了slick嵌入队列的默认大小(1000)。

所以我认为你应该:

1. 增加队列大小 (queueSize) 以容纳更多未处理的操作。
2. 增加 slick 中的线程数 (numThreads) 以同时处理更多操作。 You can get more tips here