ITPub博客

首页 > Linux操作系统 > Linux操作系统 > WebSphere的池设置——线程池、连接池

WebSphere的池设置——线程池、连接池

原创 Linux操作系统 作者:hashei 时间:2009-05-19 20:40:58 0 删除 编辑

池(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)。关于MinSpareServersMaxSpareServers, 和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池大小的一些经验值,但是真正合适的大小还要参考实际的情况,总之调优是个循序渐进的过程。


转载自: 聚沙成塔-小哈的记事薄
http://www.hashei.me/2009/05/adjust-proper-pool-size.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11605445/viewspace-600491/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2009-03-23

  • 博文量
    1
  • 访问量
    18826