我们已经在生产环境中安装了Webpshere 9。我的问题与WebContainer线程池有关
WebContainer线程池大小是否超过最大尺寸设置，即使我们没有允许线程分配超出最大线程大小未选中。由于我们已经观察到最大WebContainer线程数量超过162，最大尺寸设置为150，最小值设置为50。
Can webcontainer thread pool size exceed beyond maximum size set even if we dont have allow Thread allocation beyond maximum thread size unchecked. Since we have observed maximum webcontainer thread count exceed to 162 with maximum size set at 150 and minimum to 50.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下，您如何确切地观察线程数？虽然在您的配置中，池一次不应超过150个线程，而线程索引（线程名称的一部分，如“ WebContainer：162”）可能高于150。每当它在池中创建一个新线程时，无论当前是否正在使用每个较低的数字。由于最小尺寸小于最大尺寸的池可以删除未使用的螺纹，因此通过删除/创建周期的磁性周期，这使您的索引高于最大尺寸，这一点并不少见。
如果您仍然担心线程池行为不当，则可以通过强制Javacore（运行
kill -3针对该过程ID，或在管理控制台或在管理控制台或请求Javacore）或请求Javacore来仔细检查池大小。通过服务器的JVM MBEAN），并用名称中的“ WebContainer”计数线程。其中不可能有150多个，如果有的话，我可能建议将其报告给IBM作为可能的产品错误。How exactly did you observe the thread count in this case? While in your configuration, the pool should never have more than 150 threads at one time, the thread index (part of the thread name, as in "WebContainer : 162") could be higher than 150. The WebSphere thread pool increments the thread index every time it creates a new thread in a pool, regardless of whether every lower number is currently in use. Since a pool with a minimum size smaller than the maximum size can delete unused threads, it's not at all uncommon to go through delete/create cycles that leaves you with an index higher than the maximum size.
If you are still concerned that the thread pool is misbehaving, you could double-check the pool size by forcing a javacore (running
kill -3against the process ID, or requesting a javacore in the administrative console or through the server's JVM MBean) and counting the threads with "WebContainer" in the name. It should be very unlikely that there are more than 150 of them, and if there are, I'd probably recommend reporting that to IBM as a possible product bug.正如贾里德（Jarid）提到的一种检查方法是进行线程转储，但另一个，也许有点侵入性的是从Web控制台使用Tivoli Perf Viewer并监视WebContainer Thead Pool Stats。然后，您将轻松地看到如何利用池的最小/最大/AVG统计数据。
As Jarid mentioned one way to check is doing thread dump, but the other, maybe a little less invasive is to use Tivoli Perf Viewer from the web console and monitor the WebContainer thead pool stats. Then you will easily see min/max/avg stats of how the pool is utilized.