使用 JDBC 设置高 maxPoolSize 时需要注意哪些风险/因素

Question

我的应用程序是Piwik Server，它接收来自放置在数百个网站上的跟踪代码的传入跟踪数据。当这些跟踪请求进来时，大部分工作负载是每秒数百次对数据库的小型写入。我正在使用带有 JDBC 和 Hibernate 的 MySQL 服务器。

我最近一直在逐渐增加我的应用程序的 maxPoolSize 设置以提高性能。似乎我设置的配置越高，应用程序的响应速度越快，磁盘队列深度越稳定。

我目前的配置：

jdbc.maxPoolSize=100
jdbc.minPoolSize=100
jdbc.maxStatements=1000 

基本上，我的问题是当我增加 maxPoolSize 时应该注意哪些风险？是否有任何特定的因素或指标需要我观察来判断我是否将此设置配置得太高？显然，如果增加 maxPoolSize 是解决性能问题的灵丹妙药，那么每个人都希望将它设置得尽可能高。如果这是重复的，请提前道歉，但我找不到任何解决如何评估您的连接池是否太大的答案。

我在 AWS RDS 实例上运行 MySQL。以下是我对可能存在的问题的猜测：

• 避免超过 RDS 实例类型允许的最大连接数

• 过高的设置是否会占用服务器上的所有内存并影响性能？

• 线程过多会导致表锁定并增加某些查询的排队时间吗？

非常感谢您在了解需要注意的因素方面提供的任何帮助。

Answer 1

避免超过 RDS 实例类型允许的最大连接数。

这是有道理的。

过高的设置是否会占用服务器上的所有内存并影响性能？

这是可能的。池中的每个活动连接都将具有关联的缓冲区等。但是我希望缓冲区是有界的。

线程过多会导致表锁定并增加某些查询的排队时间吗？

可能。但是，如果您主要进行小型写入，那么我不会想到锁定会成为其他写入的问题。但是，如果您正在执行需要表扫描的同时查询，那么锁定可能是一个问题。

---

但是，我没想到增加池大小（超过 100）可能会增加吞吐量。检查数据库实例上的 CPU 和/或磁盘 I/O 负载，或前端与数据库实例之间的网络流量。如果数据库是瓶颈所在，那么允许前端同时发出更多请求可能会降低性能。

您需要考虑如果系统上的负载（例如请求率）超过其可以维持的整体吞吐量会发生什么。如果池大小太大，那么前端负载峰值可能会变成数据库负载峰值，从而导致吞吐量下降。问题是您不知道何时会发生负载峰值，除非您事先对系统进行了负载测试并使用调整后的池大小，否则您将不知道（实际）池大小变化的影响将是...

Answer 2

我强烈建议设置DropWizard metrics 和/或JMX monitoring。

在 JMX 的情况下，随着时间的推移绘制“活动连接”，如果您的池从未超过（或很少超过）给定阈值，则将 maximumPoolSize 设置在该阈值之上只会浪费资源。

在 DropWizard 指标的情况下，“使用情况”测量——反映连接离开池的时间——会在使用 maximumPoolSize 时提供一个“可比较”供您检查.

如果在 maximumPoolSize 为 50（例如）与 40 相比时，连接离开池的时间更长，这表明数据库已过饱和，40更接近理想。

如果30 与40 的maximumPoolSize 之间没有区别（同样，只是一个示例），则 可能 意味着 40 是只是不必要的高，或这可能意味着收集这些指标的时间段只是需求的低谷期，40 可能仍然是正确的。

最好的方法是将上述指标与总网络请求服务时间相结合，并将它们叠加在图表上或至少并排叠加。

指标是分析的关键！尽可能多地查找和跟踪相关的；模式会出现。 最后，您可以尝试为minumumIdle=20 和maximumPoolSize=100 设置池，然后查看池一般 的位置，忽略偶尔出现的峰值。 RDS 不同于典型的数据库，您可以控制运行数据库的硬件。使用 RDS，您真的不知道 Amazon 是如何分散负载的，因此只需要进行试验即可。让每个实验运行足够长的时间（几个小时）以收集足够的数据，并为您的显示器截屏以进行比较。