JBoss EAP 6 中的 EJB 池 - 为 max-pool-size 设置一个非常大的值有什么缺点吗？答案

【问题标题】：EJB pooling in JBoss EAP 6 - Are there any downsides to just setting a really large value for max-pool-size?JBoss EAP 6 中的 EJB 池 - 为 max-pool-size 设置一个非常大的值有什么缺点吗？
【发布时间】：2016-09-16 08:35:11
【问题描述】：

我们有一个大型知识管理应用程序，正在从 JBoss EAP 4.3 迁移到 EAP 6.4。我们遇到了一些问题，即并行 MDB 驱动的进程失败（在this question 中引用了错误消息），这可以追溯到 SLSB 池的耗尽。 MDB 线程正在请求一个特定的无状态会话 bean 三层深（以打开新事务），因此 10 个并发进程足以耗尽池并导致死锁，默认 max-pool-size 为 20。

解决方案是将特定的 SLSB 分配给它自己的池，并确保 max-pool-size 设置得足够大，以便始终有足够的 bean 实例可用（在我们的例子中是 75 个，因为罪魁祸首 MDB 进程本身限制为 25 个实例）。毫无疑问，我们会在我们的应用程序中发现许多其他情况，这些情况可能需要或至少受益于设置类似的自定义池大小。

关键是，JBoss EAP 中 MDB 和 SLSB 最大池大小的默认值——每个 bean 20 个实例——似乎低得离谱。我想做一些分析，看看在应用程序的典型使用期间我们有多少 EJB 实例在运行，这样我就可以知道我们需要允许的池大小。

max-pool-size 默认值为 20 的原因是什么？
只设置max-pool-size会不会有什么坏处？默认 slsb-strict-max-pool 和 mdb-strict-max-pool 给一些任意大值？我认识到这可能会增加峰值应用程序实例化时使用的内存分配很多 EJB 实例，但是由于 EJB 只是根据需要实例化并添加到池中，它与不使用池的替代方案有何不同？（作为上下文，我进行了一次快速审核，计算了我们应用程序中的 34 个 MDB 和 775 个 SLSB。）
最好将我的 EJB 池的 max-pool-size 与应用程序所需的 EJB 实例的预期数量紧密匹配，还是我可以在所有内容上设置一个较大的 max-pool-size 值并保持不变？

【问题讨论】：

标签： jboss-eap-6

【解决方案1】：

max-poo-size 是 20，很难想出一个默认值。如果将其设置为 100，那么单核系统上的用户很容易使 CPU 不堪重负。这取决于有多少内核可用、MDB 工作负载是什么样的，以及应用程序中还有多少其他内容。

如果您有 32 个内核可用，应用程序中没有其他任何事情发生，并且在 MDB 处理期间完成的工作非常少，那么 20 个内核可能太小了。

MDB 将始终被池化，无状态会话 bean 也是如此。

您可以将池最大值设置为较高的值，这不会造成任何损失。请记住，对于 MDB，激活需要 JMS 会话。默认会话数为 15。因此，对于 MDB，您需要匹配会话数和实例池大小，以获得所需的激活 MDB 数。会话数在 MDB 激活部署规范中配置。

【讨论】：

您好，谢谢您的回答。关于 MDB，我还发现了 15 个会话的默认限制，因此为我们之前为 25 个实例配置的一个 MDB 创建了一个特殊池。想知道我可能需要覆盖多少个独特的池来满足我们所有 800 多个 bean 的使用要求（以及我是否应该专注于制作一些不同大小的合并池，或者只是增加默认池）是引发问题的原因。
我们首先关心的是应用程序应该像在旧平台下一样工作；我们的第二个是希望我们不会因为使用 EAP 6 而变得更糟。我理解池化是一种性能策略 - 将 EJB 实例消耗的内存换成不重新实例化它们所节省的计算。但是，您的回答似乎暗示选择一个小的默认值的一个问题是限制正在工作的 EJB 实例的数量（而意外的限制是我现在对我们的应用程序关心的问题）。那么，是要快还是慢？
MDB 实例的数量和池大小是高度特定于应用程序和部署的。如果 MDB 很轻，并且您拥有 800 个线程的硬件，那么请务必使用它。我个人的经验是，我经常看到人们试图启动大量线程并淹没他们的处理器。请注意。实际上知道并测试在什么时候增加线程数会适得其反。
好的。这似乎仍然是交叉目的。毕竟，在 EAP 4.3 中，我们没有池化，EJB 是按需实例化的，并且我们实现了我们自己的线程数量限制，我们发现这会带来好处。所有关于 EJB 池的文档都只讨论了性能意图。然而，当我们将应用程序放入新框架时，使用默认设置，我们会发现池耗尽和整个应用程序受到限制的错误。因此，当我们只是希望它像以前一样工作时，它引起了一些悲伤。但它就是这样，我现在可以接受它作为调整我们应用程序的另一个工具。