(转)websphere线程池 链接池设置

原文：http://www.talkwithtrend.com/Article/207511

池（Pool）是WebSphere中最常涉及的概念之一。从网络、Web 服务器、Web 容器、EJB 容器，一直到数据源，每个环节都线程池、链接池的影子。要想恰当配置这些池的大小，首先要了解漏斗模型。

 

一般，WebSphere应用中的一个请求到达服务器，到真正开始处理，要通过一系列的链接池。广域网上可能有大量的并发用户同时访问Web服务器，Web服务器上同时活动（Active）的链接可能高达10000个。但Web服务器到应用服务器（Web容器）的链接池大小可能只有200。Web容器到EJB容器的链接池更小，多是80。而后，通过数据源（Data source）到数据库的链接最大可能只有25个。从Web服务器的链接池到数据库的链接池尺寸逐渐变小，像一个漏斗（funnel），因此称为漏斗模型。

摘自《构建高性能WebSphere企业级应用》第二章

IBM 000-253中有这么一道题：

According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?

A Web Server=75, Web container=75, Datasource =25

B Web Server=75, Web container=50, Datasource =25

C Web Server=50, Web container=50, Datasource =50

        D Web Server=25, Web container=50, Datasource =75

根据漏斗模型，那么很显然应该选B。

那么实际生产环境中就如此依样画葫芦就能够了么？后面的池必定比前面的小么？若是当前性能不行，增大池的大小就能提升么？

绝没有那么简单。后面的池小于前者，好比数据库链接池小于web线程池，默认的假定是：并不是每一个JSP和Servlet都须要访问数据库。若是你的应用是数据库密集型的应用，基本上每一个JSP和Servlet都须要访问一次或屡次数据库，并且系统中还有一些不通过jsp或Servlet的后台进程。那么数据源的链接池就必须大于web容器线程池，不然会报没法获得链接的错。

下面按照个人经验讲述一下每层池大小设置值

对于Web服务器

IBM HTTP Server的优化就是对Apache的优化。通常须要调整httpd.conf中以下参数：

MaxClients：用来定义Web服务器能够同时支持的最大并发链接数或并发用户数，默认值是600。这个值须要根据你所但愿的同时支持的并发用户数来设置，通常是峰值的120%。固然这个值不能设的太大，毕竟Apache吃内存也是很厉害。我遇到的项目通常是不用调整的，你们能够根据实际负载动态的调整MaxClients。

将 IBM HTTP Server 配置为显示状态页面：

• 编辑 IBM HTTP Server 的 httpd.conf 文件，今后文件的下列各行中注释注释字符（#）：

  #LoadModule status_module, modules/ApacheModuleStatus.dll,#<Location/server-status>#SetHandler server-status#</Location>

• 保存更改，而后从新启动 IBM HTTP Server。
• 在 Web 浏览器中，转至 http://yourhost/server-status。而且，单击从新装入以更新状态。
• （可选）若是浏览器支持刷新，那么转至 http://your_host/server-status?refresh=5 以便每 5 秒钟刷新一次。

 

上图给出了一些其它参数的推荐值。注意Windows平台和其它平台的不一样（ThreadsPerChild至关于Maxclients）。关于MinSpareServers,MaxSpareServers, 和StartServers 等的设置，以及MPM使用prefork或worker模块时的不一样，能够阅读Apache Performance Tuning。

若是你的应用访问量很大，那么也许你须要优化一下操做系统的tcp/ip相关参数。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

并修改“负载均衡”选项和“重试时间间隔”Web 服务器插件属性设置以提升性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

Web容器线程池

要点就是：“一般，对于每一个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（如今的一个cpu能够用核来代替）。好比你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server能够设置的最小值和最大值能够分别为40、80。可是通常考虑到能充分利用CPU和Memory，或者为不一样的应用启用不一样的application server，一台Pc Server上并不只有这么一个appserver，并且还有别的进程在占用着CPU，因此默认的10到50（Linux 系统上 25 个）是一个比较合适的值，固然更准确的值须要经过性能测试来肯定。

在进行性能测试的时候，若是吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要马上就调大线程池的设置——每每吞吐率会更一步降低。这时候要注意CPU占用率的状况、vmstat的r列值，特别是System状态占用率的状况，若是接近10%，甚至超过10%，那么能够确定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提高吞吐率，并且会因为吞吐率的提高下降页面平均响应时间。

这篇文章也许会使你对线程池大小对性能的影响有个感性的认识。

设置的地方你们应该都晓得，单击服务器 > 应用程序服务器 >server_name > 线程池。

数据库链接池

链接池的最小值，应该和性能测试时TPV观察到的jdbc平均大小同样，最大值根据实际须要设置，每次增加能够设置成大于1，增加一次到位。总之尽可能避免链接池频繁的增加和收缩，减小wait的状况发生。

可使用 Tivoli Performance Viewer 查找池中最优链接数。若是并发等待者的数目大于 0，可是 CPU 负载未接近 100%，那么考虑增长链接池大小。若是使用百分比值一直低于正常工做负载，那么考虑减小池中的链接数。

Application Server 将在使用该数据源的每一个应用程序服务器中建立链接池的单独实例。例如：

• 若是运行包含三个服务器的集群，这三个服务器都使用myDataSource，而且 myDataSource 的“最大链接数”设置为 10，那么可生成多达 30 个链接（3 个服务器乘以 10 个链接）

这是须要考虑的，别数据库端的链接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。

总结

这篇文章参考了IBM的inforcenter和developworks，给出了优化WebSphere池大小的一些经验值，可是真正合适的大小还要参考实际的状况，总之调优是个按部就班的过程。