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



我们有一个大型的知识管理应用程序,我们正在将它从JBoss EAP 4.3迁移到EAP 6.4。我们遇到了一个并行mdb驱动的进程失败的问题(在这个问题中引用了错误消息),这可以追溯到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-poolmdb-strict-max-pool任意大的值?我认识到这可能会增加峰值应用程序实例化时使用的内存分配大量的EJB实例,但是由于EJB只是按需实例化并添加到池中,那么它与不使用池的替代方案有什么不同呢?(对于上下文,我做了一个快速审计,并在我们的应用程序中计算了34个mdb和775个slsb。)
  • 是否最好将我的EJB池的max-pool-size与应用程序所需的EJB实例的预期数量紧密匹配,或者我可以在所有内容上设置一个大的max-pool-size值并保持不变?

对于20的max-poo-size,真的很难给出一个默认值。如果将其设置为100,那么单核系统上的用户很容易使CPU不堪重负。它归结为有多少内核可用,MDB工作负载是什么样子,以及应用程序中还发生了多少其他事情。

如果您有32个内核可供使用,那么在应用程序中没有任何其他操作,并且在MDB处理期间完成的工作非常小,那么20个内核池可能太小了。

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

您可以将池max设置为一个高值,这不会造成任何损害。请记住,对于mdb,激活需要JMS会话。缺省情况下,会话数为15。因此,对于mdb,您需要匹配会话数量和实例池大小,以便获得所需的激活mdb数量。会话数在MDB激活部署规范中配置。

相关内容

最新更新