精华内容
下载资源
问答
  • WAS优化

    2014-08-28 17:55:07
    对于一般的J2EE应用程序而言,WAS中最重要的优化参数包括针对JVM、Web Container和Data Source等的。 JVM  Heapsize(-Xms和-Xmx):heapsize的大小依赖于系统平台和具体的应用等多种因素。最大heapsize...

    http://microjava.iteye.com/blog/521261


    1. WAS 的重要优化参数有哪些?

    答:

    在着手进行应用程序服务器的优化之前,首先进行应用程序和操作系统的优化是一个更好的选择。尤其是应用程序的优化,通过对应用程序中影响性能的部分进行重新的设计和调整,往往能够带来比单纯的参数调优更为巨大的性能提升。对于一般的J2EE应用程序而言,WAS中最重要的优化参数包括针对JVM、Web Container和Data Source等的。

    JVM 
    Heapsize(-Xms和-Xmx):heapsize的大小依赖于系统平台和具体的应用等多种因素。最大heapsize需要小于机器的物理内存,一般来说,设置最大heapsize为512m是一个常见的起点。同时,在生产环境中,最好将Xms设置为小于Xmx的值。 
    GC(Garbage Collection):一般来说,良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的。 
    Heap Fragmentation:heap碎片的问题在JVM中存在大对象的情况下尤为突出。减少碎片的方法包括调整pCluster(-Xp)和kCluster(-Xk)参数。
    更多的JVM调优参数内容,参考JDK diagnostic Guide。 
    以及WAS V6.1信息中心的相关内容: 
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html

    Web Container 
    对Web Container的调优是通过对Web Container传输链中各个通道(TCP、HTTP、WebContainer)的参数调整进行的。这些参数包括诸如ThreadPool的最大最小值,buffer大小,timeout时间的大小,keep-alive的值等等。各个参数的含义及具体调整方法参见WAS V6.1信息中心: 
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunechain.html
    Data Source 
    对Data Source的优化包括两个方面。一是JDBC Driver的选取,尽可能应使用Type 4的JDBC driver,这种driver是纯java的,适用于client/server模式,并提供比type2和legacy/CLI的driver更好的性能。另一方面是Database连接池的参数设置,主要包括最大和最小连接以及timeout的设置。具体的设置于应用程序的特性和并发用户量相关,一般来说,可设置最小连接为1且最大连接为30,作为一个继续调优的起点。
    除了JVM,Web Container和Data Source之外,WAS的性能调优还包括很多其他方面的内容,如JMS、EJB、Session、Dynamic Cache等等。关于性能优化的更多内容,可参见WAS V6.1信息中心: 
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6toptuning.html

    另外,WAS 提供了若干工具,可以用于帮助衡量其性能。WAS 中免费提供的 Tivoli® Performance Viewer(TPV)允许客户对关键资源(如 JVM、Web 容器和 EJB 容器以及远程连接池)进行监视。这款工具使用非常方便,可以用于确定应用程序使用可用资源的方式,还可以提供针对行为不正常的远程资源的信息。例如,如果数据库连接池显示为了获得连接进行了多次尝试,则可能表示远程数据过载,或者需要优化数据库,或者需要向不够大的池中添加更多的连接。与此类似, WAS还提供了 Runtime Performance Advisor 功能,可以就系统中的潜在优化问题向管理员提供反馈。

    WAS Information Center (http://www.ibm.com/software/webservers/appserv/was/library/)包含了一个优化参数列表,还包括一个优化参数“热点列表”,其中描述最常用的经过调整的参数。这是一份不错的参考资料,有助于您了解在该产品内调整内存和资源的基本知识。

    其他的不错的参考资料包括 IBM® 红皮书,如 WebSphere Application Server V6 Scalability and Performance Handbook》。 



    2. 性能调优的基本步骤是怎样的?

    答:

    部署在WAS上的J2EE应用程序,其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用,一个请求到来时,往往需要经过多次转发:网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发,都可能造成请求处理的瓶颈,使得应用程序整体性能下降。如果我们把每一次转发的待处理资源都看成一个队列,如图3:


    图3 待处理资源队列


    对于WAS调优,要记住的一个基本原则就是,使得在队列中等待的请求的数量最小化。在实践中我们发现,为了达到这个目的,最有效的配置方式就是使得队列成为一个“漏斗”。也就是说,越靠近客户端的队列,其容量越大,而后面的队列,其容量要略小于或等于前面的队列。按照这个原则,调优的基本步骤如下:

    设置的是Web Server的最大并发用户:
    这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中,对应的属性是MaxClient;在Windows系统中,对应的属性是ThreadsPerChild。
    设置Web Container的最大、最小并发用户:
    在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer,根据观察的性能情况和应用情况输入合适的最小、最大进程数。
    对象请求代理(ORB)的线程池大小:
    在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池,根据观察的性能情况和应用情况输入合适的最小、最大进程数。
    设置数据库的连接池属性:
    JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池 ,根据观察的性能情况和应用情况输入合适的最小、最大连接数。
    JVM堆参数设置的性能调优:
    应用程序服务器 > server1 > 进程定义 > Java 虚拟机,根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。
    ORB参数调用方式的性能调优:
    应用程序服务器 > server1 > ORB 服务>选中按引用传递。
    关闭动态加载开关:
    企业应用程序 > 应用名称 > 关闭启动类重新装入开关。
    关闭会话序列化,应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。
    这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能,实际上性能的好坏很大部分是取决于应用的设计。好的性能源自好的代码设计。一般说来,性能调优大概可以提高10%-40%效率,而糟糕的代码设计却会使得性能几倍的下降。



    3. 如何合理的使用缓存机制?

    答:

    WAS 中可以用很多种手段实现缓存。其中最常见的一种,就是在应用中使用开发的手段缓存一些中间结果。但这种缓存是一把双刃剑。用好了可以很好地提高性能,如果掌握不好,使用过度了,则会对底层 JVM 的 Heap 造成很大的威胁。一般 JVM Heap 出现OutOfMemery(内存泄漏)的问题,都是应用中直接或者间接的缓存技术滥用的后果。所以缓存技术拿捏得当非常重要,也比较不容易。

    下面主要谈谈 WAS 产品本身提供的缓存功能。 
    WAS 提供动态缓存机制,可以对 Web 命令、 Servlet 输出和 JavaServer Pages(JSP)文件进行高速缓存,从而提高应用程序的性能。动态高速缓存服务在应用服务器 JVM 中工作,拦截对可高速缓存对象的调用。例如,它通过 servlet 的 service 方法或命令执行方法拦截调用,以及将对象的输出存储到高速缓存,或者对来自于动态高速缓存的对象内容进行处理。

    在 WAS 中可以通过配置实现常用的高速缓存对象、功能和模块有:

    Servlet 高速缓存
    Portlet 片段高速缓存
    Edge Side Include 高速缓存
    Web 命令高速缓存
    Web Service 高速缓存
    Web Service 客户机高速缓存
    关于WAS的缓存功能,详细信息请参见: 
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_dyn.html

    对于WAS中的缓存机制,和应用开发中的缓存类似,也要掌握好缓存的“度”,避免滥用,即题目中问的“如何合理的使用”?原则有如下几点:

    1. 不是缓存用得越多越好。只要是 WAS 中提供了缓存机制的环节,统统都用上。这是错误的。


    对于这一原则,有一个非常简单的方法可以确定是否采用缓存,采用哪些缓存技术:如果实现缓存本身相对于您的拓扑结构或者您所掌握的技术来说,显得非常的复杂,那么完全可以不用。举例来说,虽然 Edge Component 中提供了很好的缓存技术,但您的生产环境中,原本就没有考虑 Edge Component,现在为了缓存而缓存,非要把 Edge Component 加进去,使得拓扑偏离了原先的设计,变得更复杂化,就很没有必要了。

    2. 确认您想缓存的对象是否真的需要缓存。这一点事先比较难以判断。因为生产环境真实的使用情况是千变万化的。最佳的方法就是在真实环境中对缓存进行监控,查看被缓存对象的命中率。如果某些缓存环节利用率极低,或者某个对象命中缓存的概率非常小,则完全可以取消这样的缓存。对于利用率高的缓存,可以在内存使用比较平稳的前提下适当增大力度。

    关于缓存监控的方法,请参考WAS的InfoCenter,利用高速缓存监视器器对动态高速缓存进行适当调整。网址如下: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/cdyn_cachemonitor.html 



    4. WAS 性能差的几种表现和解决方法?

    答:

    系统性能差一般的情况下有以下表现: 

    1. CPU使用不高, 用户感觉交易响应时间很长。 

    2. CPU使用很高,用户感觉交易响应时间很长。

    对于第一种情况,可以断定是由于系统的某一小部分造成了瓶颈,导致了所有的请求都在等待。简单举例来说,线程池的数量开的太小,导致所有的请求都在排队等待进入线程池,因为没有可用的线程使用,所以这个交易请求一直在排队,导致交易响应时间很长。如果数据库连接池开的太小,也会有同样的表现。 

    对于第二种情况,比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下: 用性能分析器,如RAD或JProfiler, 对运行环境进行分析,分析哪个类甚至于哪个函数消耗了这么多的CPU,并找到相应的解决方案。

    有关 WebSphere 性能的更多资源,请参阅 developerWorks 中国站点的文章《专家访谈:Stacy Joines 和 Gary Hunt 谈 WebSphere 性能》。 




    5. 我应该怎样去判断应用程序服务器的性能是否满足要求,都有哪些指标?

    答:

    在遇到性能问题时,尝试使用Tivoli Performance Viewer,并一一察看如下最重要的10个监视项目:

    Servlets 和Enterprise JavaBeans 

    1. 平均响应时间 

    2. 请求数(事务) 

    3. 活的HTTP Session数
    线程池 

    4. web 服务器线程 

    5. web容器和EJB容器线程池
    数据源 

    6. 数据源连接池大小
    Java 虚拟机 

    7. JVM内存,垃圾收集统计
    Web,应用程序,和数据库服务器上的系统资源 

    8. CPU利用率 

    9. 磁盘和网络I/O 

    10. Paging活动
    同时,可配合使用Tivoli Performance Advisor,它们可帮助您调整您的系统,对设置不足给出建议。

    有关 WebSphere 调优工具的更多资源,请访问 developerWorks 中国站点文章和教程:

    《Ruth Willenborg 关于性能工具的提示:选择 WebSphere 性能工具》
    《性能监测,诊断和优化》
    《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》



    6. 系统中产生大对象对性能的影响怎样?

    答:

    我们经常遇到如下的例子,如果一个报表系统运行在WAS里,用户经常抱怨系统的响应时间太长,反应太慢的情况。问题的根本原因是报表系统会产生一些大对象,而这个大对象的数值如果超过2M, JVM一定要在有限的空间里为对象找到连续的空间。如果JVM为这个对象找不到连续的空间,就会对整个内存空间进行整理,如果大对象比较多,由于JVM对内存空间的频繁整理会对系统的性能有着急剧的影响。造成系统的响应时间非常慢,所以应用程序应尽量避免产生大对象,或者用一个链表的结构来表达大对象,本质上把一个大对象拆成几个可以联接的小对象,让JVM可以很容易的分配内存空间。




    7. 如何解决内存泄漏问题?

    答:

    由于系统的复杂性,不可能通过程序来确定内存泄漏的根源,因为内存泄漏的根源可以是来源于自己写的应用,开放源码的组件,JDBC组件,甚至可以怀疑WAS本身也能造成内存泄漏。但也有一个解决思路,就是在应用程序已经发生内存泄漏时,把当前的内存中的所有对象做一个快照。从这些所有的对象中做分析,找到怀疑的地方,并写测试案例来进行验证。正常的情况下,要在不同的时间点上做几个内存快照。IBM提供了几个分析工具,MemDumpDiag,HeapRoots,利用这些工具可以对系统内存的使用进行辅助分析。另外一个有效的办法是WebSphere还可以把GC(Garbage Collection)的log打印到SystemErr.log上,通过分析GC的日志可以得到很多的直观上的对内存的使用,如内存的随着时间的变化情况等。IBM 提供的工具是“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”,这个工具可以对GC进行分析统计。

    有关在 WAS 中解决内存泄漏的更多资源,请参阅 developerWorks 中国站点的文章:

    《WebSphere Application Server 中的内存泄漏检测与分析:第 1 部分:内存泄漏概述》
    《WebSphere Application Server 中的内存泄漏检测与分析:第 2 部分:用于泄漏检测与分析的工具和功能》
    《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》




    8. 如何解决系统宕机问题?

    答:

    WAS系统不会轻易的宕机,因为WAS 容器能对它的内存和线程进行控制,大部分的情况是由于内存问题造成系统宕机,如果这种情况发生,WAS缺省的情况下会产生JavaCore文件和Heap Dump文件,需要对这两个文件进行分析。 另外的能导致系统宕机的情况是WAS调用外部程序,如对C/C++程序的调用,这些JNI调用也有可能造成系统宕机,如遇这种情况,从WAS出发找不到问题的根源的,需要从外部程序(C/C++)进行查找问题的根源。 



    9. WAS 运行在什么平台上性能最好?是Intel、UNIX、pSeries/AIX、Sun/Solaris,还是 zSeries/zOS?

    答:

    这里有几个关于WAS在不同平台上的性能总结。当然您要清楚,在选择WAS运行的平台时需要考虑众多的因素,不仅是性能。

    WAS 几乎完全是一个Java应用程序(除了有一小部分平台相关的代码),基础代码对任何平台都是一样的(除了zSerires/zOS)。因此,性能的任何差别主要依赖底层硬件、操作系统和JVM的性能。
    WebSphere的性能主要依赖于JVM的性能。JVM是本地代码,由IBM或者操作系统提供者提供。IBM开发的JVM具有非常好的性能和可扩展性。pSeries平台上WebSphere 正是使用IBM的JVM,它有着相当突出的性能和可扩展性。关于JVM性能基准的更多资源,请访问以下站点:http://www.spec.org。
    WAS代码对SMP(对称多处理,Symmetrical Multi-Processing)处理器的可量测性做了优化,通常的规则是:基于UNIX,iSeries/OS400和zSeries/zOS的SMP 扩展结果比基于Intel的更强。而在UNIX操作系统中,AIX有最高的SMP扩展特性。

    展开全文
  • was优化

    2009-11-20 15:26:40
    1. WAS 的重要优化参数有哪些? 答: 在着手进行应用程序服务器的优化之前,首先进行应用程序和操作系统的优化是一个更好的选择。尤其是应用程序的优化,通过对应用程序中影响性能的部分进行重新的设计和...
    1. WAS 的重要优化参数有哪些? 

    答:

    在着手进行应用程序服务器的优化之前,首先进行应用程序和操作系统的优化是一个更好的选择。尤其是应用程序的优化,通过对应用程序中影响性能的部分进行重新的设计和调整,往往能够带来比单纯的参数调优更为巨大的性能提升。对于一般的J2EE应用程序而言,WAS中最重要的优化参数包括针对JVM、Web Container和Data Source等的。

    JVM
    Heapsize(-Xms和-Xmx):heapsize的大小依赖于系统平台和具体的应用等多种因素。最大heapsize需要小于机器的物理内存,一般来说,设置最大heapsize为512m是一个常见的起点。同时,在生产环境中,最好将Xms设置为小于Xmx的值。
    GC(Garbage Collection):一般来说,良好的GC状态需要保证相邻两次垃圾回收的平均间隔时间应当是单次垃圾回收所需时间的至少5-6倍。GC的调优是通过在模拟压力的情况下不断调整最大最小heapsize来实现的。
    Heap Fragmentation:heap碎片的问题在JVM中存在大对象的情况下尤为突出。减少碎片的方法包括调整pCluster(-Xp)和kCluster(-Xk)参数。
    更多的JVM调优参数内容,参考JDK diagnostic Guide。
    以及WAS V6.1信息中心的相关内容:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunejvm_v61.html

    Web Container
    对Web Container的调优是通过对Web Container传输链中各个通道(TCP、HTTP、WebContainer)的参数调整进行的。这些参数包括诸如ThreadPool的最大最小值,buffer大小,timeout时间的大小,keep-alive的值等等。各个参数的含义及具体调整方法参见WAS V6.1信息中心:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunechain.html
    Data Source
    对Data Source的优化包括两个方面。一是JDBC Driver的选取,尽可能应使用Type 4的JDBC driver,这种driver是纯java的,适用于client/server模式,并提供比type2和legacy/CLI的driver更好的性能。另一方面是Database连接池的参数设置,主要包括最大和最小连接以及timeout的设置。具体的设置于应用程序的特性和并发用户量相关,一般来说,可设置最小连接为1且最大连接为30,作为一个继续调优的起点。
    除了JVM,Web Container和Data Source之外,WAS的性能调优还包括很多其他方面的内容,如JMS、EJB、Session、Dynamic Cache等等。关于性能优化的更多内容,可参见WAS V6.1信息中心:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc6toptuning.html

    另外,WAS 提供了若干工具,可以用于帮助衡量其性能。WAS 中免费提供的 Tivoli® Performance Viewer(TPV)允许客户对关键资源(如 JVM、Web 容器和 EJB 容器以及远程连接池)进行监视。这款工具使用非常方便,可以用于确定应用程序使用可用资源的方式,还可以提供针对行为不正常的远程资源的信息。例如,如果数据库连接池显示为了获得连接进行了多次尝试,则可能表示远程数据过载,或者需要优化数据库,或者需要向不够大的池中添加更多的连接。与此类似, WAS还提供了 Runtime Performance Advisor 功能,可以就系统中的潜在优化问题向管理员提供反馈。

    WAS Information Center (http://www.ibm.com/software/webservers/appserv/was/library/)包含了一个优化参数列表,还包括一个优化参数“热点列表”,其中描述最常用的经过调整的参数。这是一份不错的参考资料,有助于您了解在该产品内调整内存和资源的基本知识。

    其他的不错的参考资料包括 IBM® 红皮书,如 WebSphere Application Server V6 Scalability and Performance Handbook》。



    2. 性能调优的基本步骤是怎样的?

    答:

    部署在WAS上的J2EE应用程序,其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。对于一个标准的J2EE应用,一个请求到来时,往往需要经过多次转发:网络 > Web服务器Web容器 > EJB容器 > 数据库。而每一次转发,都可能造成请求处理的瓶颈,使得应用程序整体性能下降。如果我们把每一次转发的待处理资源都看成一个队列,如图3:


    图3 待处理资源队列


    对于WAS调优,要记住的一个基本原则就是,使得在队列中等待的请求的数量最小化。在实践中我们发现,为了达到这个目的,最有效的配置方式就是使得队列成为一个“漏斗”。也就是说,越靠近客户端的队列,其容量越大,而后面的队列,其容量要略小于或等于前面的队列。按照这个原则,调优的基本步骤如下:

    设置的是Web Server的最大并发用户:
    这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中,对应的属性是MaxClient;在Windows系统中,对应的属性是ThreadsPerChild。
    设置Web Container的最大、最小并发用户:
    在管理控制台中点击应用程序服务器 > server1 > 线程池 >WebContainer,根据观察的性能情况和应用情况输入合适的最小、最大进程数。
    对象请求代理(ORB)的线程池大小:
    在管理控制台中点击应用程序服务器 > server1 > ORB 服务 > 线程池,根据观察的性能情况和应用情况输入合适的最小、最大进程数。
    设置数据库的连接池属性:
    JDBC 提供者 >数据库JDBC驱动名称 > 数据源 > 数据源名称> 连接池 ,根据观察的性能情况和应用情况输入合适的最小、最大连接数。
    JVM堆参数设置的性能调优:
    应用程序服务器 > server1 > 进程定义 > Java 虚拟机,根据硬件物理内存和应用情况输入合适的初始堆大小、最大堆大小。
    ORB参数调用方式的性能调优:
    应用程序服务器 > server1 > ORB 服务>选中按引用传递。
    关闭动态加载开关:
    企业应用程序 > 应用名称 > 关闭启动类重新装入开关。
    关闭会话序列化,应用程序服务器 > server1 > 会话管理 > 分布式环境设置 > 分布式会话选择无即可。
    这个调优的步骤只是涉及了利用WAS服务器参数的调整来优化应用程序的性能,实际上性能的好坏很大部分是取决于应用的设计。好的性能源自好的代码设计。一般说来,性能调优大概可以提高10%-40%效率,而糟糕的代码设计却会使得性能几倍的下降。



    3. 如何合理的使用缓存机制?

    答:

    WAS 中可以用很多种手段实现缓存。其中最常见的一种,就是在应用中使用开发的手段缓存一些中间结果。但这种缓存是一把双刃剑。用好了可以很好地提高性能,如果掌握不好,使用过度了,则会对底层 JVM 的 Heap 造成很大的威胁。一般 JVM Heap 出现OutOfMemery(内存泄漏)的问题,都是应用中直接或者间接的缓存技术滥用的后果。所以缓存技术拿捏得当非常重要,也比较不容易。

    下面主要谈谈 WAS 产品本身提供的缓存功能。
    WAS 提供动态缓存机制,可以对 Web 命令、 Servlet 输出和 JavaServer Pages(JSP)文件进行高速缓存,从而提高应用程序的性能。动态高速缓存服务在应用服务器 JVM 中工作,拦截对可高速缓存对象的调用。例如,它通过 servlet 的 service 方法或命令执行方法拦截调用,以及将对象的输出存储到高速缓存,或者对来自于动态高速缓存的对象内容进行处理。

    在 WAS 中可以通过配置实现常用的高速缓存对象、功能和模块有:

    Servlet 高速缓存
    Portlet 片段高速缓存
    Edge Side Include 高速缓存
    Web 命令高速缓存
    Web Service 高速缓存
    Web Service 客户机高速缓存
    关于WAS的缓存功能,详细信息请参见:
    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/welc6tech_dyn.html

    对于WAS中的缓存机制,和应用开发中的缓存类似,也要掌握好缓存的“度”,避免滥用,即题目中问的“如何合理的使用”?原则有如下几点:

    1. 不是缓存用得越多越好。只要是 WAS 中提供了缓存机制的环节,统统都用上。这是错误的。


    对于这一原则,有一个非常简单的方法可以确定是否采用缓存,采用哪些缓存技术:如果实现缓存本身相对于您的拓扑结构或者您所掌握的技术来说,显得非常的复杂,那么完全可以不用。举例来说,虽然 Edge Component 中提供了很好的缓存技术,但您的生产环境中,原本就没有考虑 Edge Component,现在为了缓存而缓存,非要把 Edge Component 加进去,使得拓扑偏离了原先的设计,变得更复杂化,就很没有必要了。

    2. 确认您想缓存的对象是否真的需要缓存。这一点事先比较难以判断。因为生产环境真实的使用情况是千变万化的。最佳的方法就是在真实环境中对缓存进行监控,查看被缓存对象的命中率。如果某些缓存环节利用率极低,或者某个对象命中缓存的概率非常小,则完全可以取消这样的缓存。对于利用率高的缓存,可以在内存使用比较平稳的前提下适当增大力度。

    关于缓存监控的方法,请参考WAS的InfoCenter,利用高速缓存监视器器对动态高速缓存进行适当调整。网址如下: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/cdyn_cachemonitor.html



    4. WAS 性能差的几种表现和解决方法?

    答:

    系统性能差一般的情况下有以下表现:

    1. CPU使用不高, 用户感觉交易响应时间很长。

    2. CPU使用很高,用户感觉交易响应时间很长。

    对于第一种情况,可以断定是由于系统的某一小部分造成了瓶颈,导致了所有的请求都在等待。简单举例来说,线程池的数量开的太小,导致所有的请求都在排队等待进入线程池,因为没有可用的线程使用,所以这个交易请求一直在排队,导致交易响应时间很长。如果数据库连接池开的太小,也会有同样的表现。

    对于第二种情况,比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下: 用性能分析器,如RAD或JProfiler, 对运行环境进行分析,分析哪个类甚至于哪个函数消耗了这么多的CPU,并找到相应的解决方案。

    有关 WebSphere 性能的更多资源,请参阅 developerWorks 中国站点的文章《专家访谈:Stacy Joines 和 Gary Hunt 谈 WebSphere 性能》。




    5. 我应该怎样去判断应用程序服务器的性能是否满足要求,都有哪些指标?

    答:

    在遇到性能问题时,尝试使用Tivoli Performance Viewer,并一一察看如下最重要的10个监视项目:

    Servlets 和Enterprise JavaBeans

    1. 平均响应时间

    2. 请求数(事务)

    3. 活的HTTP Session数
    线程池

    4. web 服务器线程

    5. web容器和EJB容器线程池
    数据源

    6. 数据源连接池大小
    Java 虚拟机

    7. JVM内存,垃圾收集统计
    Web,应用程序,和数据库服务器上的系统资源

    8. CPU利用率

    9. 磁盘和网络I/O

    10. Paging活动
    同时,可配合使用Tivoli Performance Advisor,它们可帮助您调整您的系统,对设置不足给出建议。

    有关 WebSphere 调优工具的更多资源,请访问 developerWorks 中国站点文章和教程:

    《Ruth Willenborg 关于性能工具的提示:选择 WebSphere 性能工具》
    《性能监测,诊断和优化》
    《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》



    6. 系统中产生大对象对性能的影响怎样?

    答:

    我们经常遇到如下的例子,如果一个报表系统运行在WAS里,用户经常抱怨系统的响应时间太长,反应太慢的情况。问题的根本原因是报表系统会产生一些大对象,而这个大对象的数值如果超过2M, JVM一定要在有限的空间里为对象找到连续的空间。如果JVM为这个对象找不到连续的空间,就会对整个内存空间进行整理,如果大对象比较多,由于JVM对内存空间的频繁整理会对系统的性能有着急剧的影响。造成系统的响应时间非常慢,所以应用程序应尽量避免产生大对象,或者用一个链表的结构来表达大对象,本质上把一个大对象拆成几个可以联接的小对象,让JVM可以很容易的分配内存空间。




    7. 如何解决内存泄漏问题?

    答:

    由于系统的复杂性,不可能通过程序来确定内存泄漏的根源,因为内存泄漏的根源可以是来源于自己写的应用,开放源码的组件,JDBC组件,甚至可以怀疑WAS本身也能造成内存泄漏。但也有一个解决思路,就是在应用程序已经发生内存泄漏时,把当前的内存中的所有对象做一个快照。从这些所有的对象中做分析,找到怀疑的地方,并写测试案例来进行验证。正常的情况下,要在不同的时间点上做几个内存快照。IBM提供了几个分析工具,MemDumpDiag,HeapRoots,利用这些工具可以对系统内存的使用进行辅助分析。另外一个有效的办法是WebSphere还可以把GC(Garbage Collection)的log打印到SystemErr.log上,通过分析GC的日志可以得到很多的直观上的对内存的使用,如内存的随着时间的变化情况等。IBM 提供的工具是“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector”,这个工具可以对GC进行分析统计。

    有关在 WAS 中解决内存泄漏的更多资源,请参阅 developerWorks 中国站点的文章:

    《WebSphere Application Server 中的内存泄漏检测与分析:第 1 部分:内存泄漏概述》
    《WebSphere Application Server 中的内存泄漏检测与分析:第 2 部分:用于泄漏检测与分析的工具和功能》
    《WebSphere应用服务器内存泄漏探测与诊断工具选择最佳实践》




    8. 如何解决系统宕机问题?

    答:

    WAS系统不会轻易的宕机,因为WAS 容器能对它的内存和线程进行控制,大部分的情况是由于内存问题造成系统宕机,如果这种情况发生,WAS缺省的情况下会产生JavaCore文件和Heap Dump文件,需要对这两个文件进行分析。 另外的能导致系统宕机的情况是WAS调用外部程序,如对C/C++程序的调用,这些JNI调用也有可能造成系统宕机,如遇这种情况,从WAS出发找不到问题的根源的,需要从外部程序(C/C++)进行查找问题的根源。



    9. WAS 运行在什么平台上性能最好?是Intel、UNIX、pSeries/AIX、Sun/Solaris,还是 zSeries/zOS?

    答:

    这里有几个关于WAS在不同平台上的性能总结。当然您要清楚,在选择WAS运行的平台时需要考虑众多的因素,不仅是性能。

    WAS 几乎完全是一个Java应用程序(除了有一小部分平台相关的代码),基础代码对任何平台都是一样的(除了zSerires/zOS)。因此,性能的任何差别主要依赖底层硬件、操作系统和JVM的性能。
    WebSphere的性能主要依赖于JVM的性能。JVM是本地代码,由IBM或者操作系统提供者提供。IBM开发的JVM具有非常好的性能和可扩展性。pSeries平台上WebSphere 正是使用IBM的JVM,它有着相当突出的性能和可扩展性。关于JVM性能基准的更多资源,请访问以下站点:http://www.spec.org。
    WAS代码对SMP(对称多处理,Symmetrical Multi-Processing)处理器的可量测性做了优化,通常的规则是:基于UNIX,iSeries/OS400和zSeries/zOS的SMP 扩展结果比基于Intel的更强。而在UNIX操作系统中,AIX有最高的SMP扩展特性。
    展开全文
  • WAS优化之集群会话分布式设置举例

    千次阅读 2015-11-18 00:47:21
    下面对was集群环境下的分布式会话设置做一个简单的操作举例。找到应用服务器,如下: 先点击进入其中一个节点,如下: 选择“分布式环境设置”,如下: 初次设置时,需要进行新建后,选择“内存到内存复制...

    原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明出处,否则追究版权法律责任。
    深蓝的blog:http://blog.csdn.net/huangyanlong/article/details/49897615
    下面对was集群环境下的分布式会话设置做一个简单的操作举例。

    找到应用服务器,如下:
    这里写图片描述
    先点击进入其中一个节点,如下:
    这里写图片描述
    选择“分布式环境设置”,如下:
    这里写图片描述
    初次设置时,需要进行新建后,选择“内存到内存复制”,如下:
    这里写图片描述
    然后完成常规属性配置,可参考如下:
    这里写图片描述
    点击确定后,完成节点间配置同步,该节点的会话分布式设置就完成了。同理,另外一个节点进行相同的操作即可。

    小知识点,简而记之。

    蓝的成长记系列:

    原创作品,出自 “深蓝的blog” 博客

    蓝的成长记——追逐DBA(1):奔波于路上,挺进山东

    蓝的成长记——追逐DBA(2):安装!安装!久违的记忆,引起我对DBA的重新认知

    蓝的成长记——追逐DBA(3):古董上操作,数据导入导出成了问题

    蓝的成长记——追逐DBA(4):追忆少年情愁,再探oracle安装

    蓝的成长记——追逐DBA(5):不谈技术谈业务,恼人的应用系统

    蓝的成长记——追逐DBA(6):做事与做人:小技术,大为人

    蓝的成长记——追逐DBA(7):基础命令,地基之石

    蓝的成长记——追逐DBA(8):重拾SP报告,回忆oracle的STATSPACK实验

    蓝的成长记——追逐DBA(9):国庆渐去,追逐DBA,新规划,新启程

    蓝的成长记——追逐DBA(10):飞刀防身,熟络而非专长:摆弄中间件Websphere

    蓝的成长记——追逐DBA(11):回家后的安逸,晕晕乎乎醒了过来

    蓝的成长记——追逐DBA(12):七天七收获的SQL

    蓝的成长记——追逐DBA(13):协调硬件厂商,六个故事:所见所感的“服务器、存储、交换机……”

    蓝的成长记——追逐DBA(14):难忘的“云”端,起步的hadoop部署

    蓝的成长记——追逐DBA(15):以为FTP很“简单”,谁成想一波三折

    蓝的成长记——追逐DBA(16):DBA也喝酒,被捭阖了

    蓝的成长记——追逐DBA(17):是分享,还是消费,在后IOE时代学会成长

    蓝的成长记——追逐DBA(18):小机上WAS集群故障,由一次更换IP引起

    蓝的成长记——追逐DBA(19):路上的插曲:触碰“框架”与“软件系统”

    蓝的成长记——追逐DBA(20):何故缘起,建库护航

    其它篇章:

    足球与oracle系列(1):32路诸侯点兵,oracle32进程联盟 之A组巴西SMON进程的大局观

    足球与oracle系列(2):巴西揭幕战预演,oracle体系结构杂谈

    足球与oracle系列(3):oracle进程排名,世界杯次回合即将战罢!

    足球与oracle系列(4):从巴西惨败于德国,想到,差异的RAC拓扑对比!

    足球与oracle系列(5):fifa14游戏缺失的directX库类比于oracle的rpm包!

    足球与oracle系列(6):伴随建库的亚洲杯——加油中国队

    展开全文
  • WAS安装优化笔记.doc

    2009-03-03 13:56:06
    非常有用的was优化心得,积累在实际使用中存在的一些调优方法,很有作用
  • WAS性能优化

    千次阅读 2018-12-04 08:37:59
    登录WAS控制台:   修改初始堆大小,与最大堆大小。这里根据机器性能调整,通常情况下,机器资源是足够的,因此请调整为: 1536至3072  或者直接修改server.xml文件 /was/IBM/WebSphere/AppServer/profiles/...

    1、JVM堆大小配置

    登录WAS控制台:

     

    修改初始堆大小,与最大堆大小。这里根据机器性能调整,通常情况下,机器资源是足够的,因此请调整为:

    1536至3072

     或者直接修改server.xml文件

    /was/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/loopbackNode01Cell/nodes/liaobinNode01/servers/server1/server.xml

    在<jvmEntries>元素中,如下属性:表示最小堆1536M,最大堆3072M

    initialHeapSize="1536" maximumHeapSize="3072"

    2、开启GC日志

    登录WAS控制台:

    勾选详细垃圾回收。

    或者直接修改server.xml文件

    /was/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/loopbackNode01Cell/nodes/liaobinNode01/servers/server1/server.xml

    在<jvmEntries>元素中,如下属性

    verboseModeGarbageCollection="true"

    3、WebContainer线程池

    登录WAS控制台:请直接调整为 200至200(这里也可以调整100至200)

    或者直接修改server.xml文件

    /was/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/loopbackNode01Cell/nodes/liaobinNode01/servers/server1/server.xml

    在< threadPools name=”WebContainer”>元素中,如下属性

    minimumSize="100" maximumSize="200"

    4、连接池属性

    登录WAS控制台:可以直接调整为200至200(这里也可以调整100至200)

    5、语句高速缓存大小

    对于OLTP应用,调整为50最佳。

    6、日志调整

    根据需要调整日志生成的规则,这里采用每天一次备份,保留50天(按应用提的要求设置,如果没有要求,请设置为50天)。SystemErr.log 也可以采取这样的方式。

    诊断跟踪服务调整为无

    IBM服务日志不要勾上

    PMI性能监控设置为扩展。

    7、 在native_stderr.log中生成超过20m的大对象的信息,便于后期分析。对性能影响不大。(为了方面内存溢出问题处理,本条不是必须的

     打开管理控制台, 点击 服务器 > 应用程序服务器 >server1, 点击 > java和进程管理> 进程定义 . 

    . 点击java虚拟机. 

    . 将-Xdump:stack:events=allocation,filter=#20m参数以空格相隔,添加到JVM通用参数一栏中,然后点击确定并保存. 

    展开全文
  • WAS7或WAS8性能优化

    2016-01-08 21:47:27
    was的性能优化主要从JVM、线程池、数据库连接池入手处理
  • WAS性能优化分析工具

    2015-10-23 14:40:09
    WAS性能优化分析工具被分析的文件heapdump1654900.1272355258.phd 文件javacore1654900.1272355269.txt文件ga395.zipI:\IBM_WAS\IBMToolsForHeadDump\IBMGarbageCollectorAnalysishttp://dl.iteye....
  • WAS中性能优化配置

    千次阅读 2015-05-12 22:38:32
    一般web项目都要放在服务器上,在代码没有极大的漏洞的情况下,可以通过优化was来提供项目系统的性能,或者找出系统的性能瓶颈。 一般都是配置was的线程池(即最大线程数),数据库的连接池(即数据库连接数),且...
  • WAS & IHS 优化

    千次阅读 2013-08-21 20:24:43
    WAS配置概要  描述 参数 缺省值 设置原则 JVM堆栈 服务器 > 应用程序服务器 > server1 > Java 虚拟机 无 最小值为总内存1/8,最大值为总内存1/2至3/4 ...
  • IBM WAS 性能优化

    2010-08-31 12:59:05
    WebSphere Application Server 故障诊断的资源以及相关工具的介绍: http://www.ibm.com/developerworks/cn/websphere/library/techarticle...
  • WAS集群系列(14):举例WAS集群优化

    千次阅读 2014-09-09 17:32:20
    优化配置 (1)、连接数
  • websphere优化

    2013-09-25 10:19:13
    was优化方案,让你的服务器访问的更快、更稳定,提高客户体验度!
  • IBM was 8.5中间件,支持多节点,用于大型业务系统
  • -Xshareclasses:none -agentpath:/home/ap/was/AppServer/profiles/AppSrv01/cj/jprofiler9/bin/linux-x64/libjprofilerti.so=port=10010,nowait  但是我试过很多次,只要加上nowait就起不来。不知道什么。 ...
  • was和ihs的优化文档

    千次阅读 2010-05-09 16:11:00
    为了优化性能,设置“未使用超时”值高于“收集超时”值。如果当前连接数超过最小连接数设置,则仅废弃未使用的物理连接。例如,如果未使用超时值设置为 120,并且启用池维护线程(收集时间不是 0),则...
  • 内存整理优化器 This installation was built with Inno Setup: http://www.innosetup.com
  • websphere参数配置 1,更改http server的配置文件参数KeepAlive。 原因:这个值说明是否保持客户与HTTP SERVER的连接,如果设置为ON,则请求数到达MaxKeepAliveRequests设定值时请求将排队,导致响应变慢。...
  • was部署手册

    2016-07-22 16:49:59
    包括was的集群部署、jndi设置、应用服务器配置优化和web服务器http.conf的配置
  • was性能调整方案

    2013-10-09 10:13:00
    IBM was 配置优化,参数设置方案,值得一看
  • WebSphere优化

    2015-02-07 10:34:00
    优化WebSphereWebSphere里的profile刚配完,一般默认的heapsize即Xms与Xmx值只有256mb,而IBM WAS是几个J2EE服务器中最吃内存的机器,在布署一些EAR应用时,如果你的EAR中使用的lib即jar files较多,加载时往往会...
  • 针对WASM二进制文件大小进行了优化,压缩后的压缩大小为161.98 KB(未压缩的244.40 KB)。 在移动设备和台式机上完美运行 演示版 尝试使用相机扫描条形码: : 在命令行中查找找到的条形码。 安装 npm install zbar...
  • was常见问题

    千次阅读 2015-10-14 15:54:34
    1. WAS 的重要优化参数有哪些? 2. 性能调优的基本步骤是怎样的? 3. 如何合理的使用缓存机制? 4. WAS 性能差的几种表现和解决方法? 5. 我应该怎样去判断应用程序服务器的性能是否满足要求,都有哪些...
  • 新手如何设置和优化关键词by Mario Hoyos 通过马里奥·霍约斯(Mario Hoyos) 网站优化新手指南 (A beginner...I am a beginner, and I was able to achieve 99/100 in Google’s optimization ranking. If I can d...
  • 优化EF的性能

    千次阅读 2013-07-10 15:42:40
    Entity Framework的性能优化: 1.使用MergeOption.NoTracking (发现添加这个代码后, 导致"The object cannot be deleted because it was not found in the ObjectStateManager."错误,解决办法为, 先调用entity...
  • cargo wasi 项目 一个轻量级的Cargo子命令,用于为wasm... cargo wasi build --release —构建您的*.wasm的优化版本。 cargo wasi run -执行二进制文件。 cargo wasi test —在wasm32-wasi运行测试。 cargo wasi be
  • Websphere优化设置

    2016-06-12 11:55:08
    Websphere优化的四个方面举例 一、简介 环境 名称 版本 服务器操作系统 Centos 5.6 应用服务器操作系统 Windows 7 Websphere...
  • mysql优化

    2016-04-21 14:50:32
     ...#This File was made using the WinMySQLAdmin 1.4 Tool #2004-2-23 16:28:14 #Uncomment or Add only the keys that you know how works. #Read the MySQL Manual for instructions
  • NC631和WAS8.5安装步骤

    2019-04-19 08:42:36
    文档图文详细介绍NC631和WAS8.5的水平集群安装部署步骤,以及参数优化内容!
  • Tomcat 优化

    2014-11-22 13:02:00
    1.apr许多朋友可能在启动tomcat的时候都会...org.apache.catalina.core.AprLifecycleListener init信息: The Apache Tomcat Native library which allows optimal performance in production environments was not f...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 504
精华内容 201
关键字:

was优化