- 论坛徽章:
- 59
|
Weblogic内存遗漏,不外乎也就两种情况,一种是虚拟机内存参数设置不合理,造成Weblogic运行一段时候后内存分配不足,而造成内存遗漏的发生;第二种情况不外乎就是我们的程序写的不好,分配的内存没有及时的释放而造成内存泄漏情况的发生。
关于内存泄漏问题,我们一般会从应用程序出发,去审核代码,做到代码级的优化,然后再调整应用服务器(BEA WebLogic8.1)和数据库 (Oracle9i)的参数,最后当然是调整操作系统和网络的性能(包括硬件升级)。这是一种MDA的先进做法。
2、Goldengate数据迁移注意事项及常见问题
这个我没有做过,暂时不知道。
1. 非图形界面下的安装
./tuxedo81_aix_32bit.bin -i console 加入 -i console则不需要图形支持
2.察看版本和patch信息
$TUXDIR/bin/tmadmin -v
3.对ubb文件只做语法检查(不真正的load成TUXCONFIG 真正tmloadcf -y)
tmloadcf -n ubb
4.tmboot/tmshutdown中的几个参数介绍
-A 只启动/停止Tuxedo管理服务,如BBL
-S 所有服务被启动/停止
-g grpname 只启动/停止属于制定组名的服务
-i svrid 只启动/停止制定ServID的服务
-s svrname 只启动/停止制定服务名的服务
5. tuxedo有关域(domain)管理的命令
$ dmadmin
>pd -d LocalTUXDomainID 显示与本地域关联的其他域
>co -d LocalTUXDomainID -R RemoteDomainID 手动连接远程域
6.如何清除IPC资源
如果你不想用tmshutdown停止或者当$TUXCONFIG文件被误删除而无法shutdown TUXEDO服务时,可以尝试直接删除当前用户的ipc资源,如下:
ipcs | grep `logname` | awk '{print "ipcrm -"$1,$2}' |sh -x
7.反编译tuxconfig 生成 ubb文件
a) tmunloadcf 查看当前TUXCONFIG中的ubb内容
b) export TUXCONFIG=`pwd`/tuxconfig 比较简单的设置TUXCONFIG的命令
8.Tuxedo非正常状态下的关闭
1) 执行tmshutdown -y,如果shutdown不成功,转入下一步(此时一般来说,TUXEDO的状态已经处于
不正常了)。
2)执行tmipcrm -y,如果shutdown不成功,转入下一步。
3)要用到AWK,所以要求在Unix下,或者在WINDOWS下装了Cygwin。
3)执行ipcrm `ipcs|grep $USER|awk '{print " -"$1" "$2}'`。
执行了3)肯定就可以关闭掉了。
一般情况下,我也懒得那么麻烦,在非生产机上经常来一个killall -9,将该用户所有的进程都杀掉。
9.隐藏显示服务
隐藏服务
unadvertise (unadv) {-q qaddress [-g groupname] [-i srvid] |
-g groupname -i srvid} service
显示服务
advertise (adv) {-q qaddress [-g groupname] [-i srvid] | -g groupname -i srvid}
service[:func]
上面两个命令只能在单独登录tmadmin时使用。
重复登录tmadmin后出现
TMADMIN_CAT:199: WARN: Cannot become administrator.Limited set of commands available.
提示不能使用上面命令。
10.sh命令直接执行tuxedo操作
如
$echo pclt |tmadmin
$echo pq |tmadmin |grep Machine
11.WSL配置参数
WSL的配置重点要注意其CLOPT中几个关键参数的指定:
-m, -M, -x, WSH启动的最大、最小个数,及每个WSH可同时处理的并发请求数,
"-M" * "-x" = MAXWSCLIENTS;
-I, 客户端与服务器端建立连接的超时时间;
-N, 客户端发起请求的响应超时时间;
-T, 客户端在与服务器端建立连接后,允许最大的空闲时间;
-H, 穿防火墙时,防火墙的ip
-p, WSH分配的起始端口
-P, WSH分配的结束端口。 -p 9901 -P 9915 指定端口范围 9901-9915
12.UBB文件中MAX。。的配置
MAXWSCLIENTS <= Tuxedo license
MAXSERVERS = SUM (MAX setting of servers)
MAXACCESSERS = (MAXSERVERS+MAXWSCLIENTS) * 117%
2.1 JVM调优
2.1.1 垃圾收集和堆大小
垃圾收集(GC)是指JVM释放Java堆中不再使用的对象所占用的内存的过程,而Java堆(Heap)是指Java应用程序对象生存的空间。堆大小决定了GC的频度和时间。堆越大,GC频度低,速度慢。堆越小,GC频度高,速度快。所以GC和堆大小是一组矛盾。为了获取理想的Heap堆大小,需要使用-verbosegc参数(Sun jdk: -Xloggc:<file>)以打开详细的GC输出。分析GC的频度和时间,结合应用最大负载所需内存情况,得出堆的大小。
通常情况下,我们建议使用可用内存(除操作系统和其他应用程序占用之外的内存)70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:-Xms=-Xmx。而为了防止内存溢出,建议在生产环境堆大小至少为256M(Platform至少512M),实际环境中512M~1G左右性能最佳,2G以上是不可取的,在调整内存时可能需要调整核心参数进程的允许最大内存数。对于sun和hp的jvm,永久域太小(默认4M)也可能造成内存溢出,应增加参-XX:MaxPermSize=128m。建议设置临时域-Xmn的大小为-Xmx的1/4~1/3, SurvivorRatio为8。
为了获得更好的性能,建议在启动文件设置WebLogic为产品模式,此时sun和hp jvm JIT引擎为-server,默认情况下打开JIT编译模式对性能也有帮助。调整Chunk Size和Chunk Pool Size也可能对系统的吞吐量有提高。此外还需关闭显示GC: -XX:+DisableExplicitGC。
当然在Intel平台上使用jRockit(使用参数-jrockit)无疑大大提高WebLogic性能。
2.1.2 jRockit调优
jRockit支持四种垃圾收集器:分代复制收集器、单空间并发收集器、分代并发收集器和并行收集器。默认状态下,JRockit使用分代并发收集器。要改变收集器,可使用-Xgc:<gc-name>,对应四个收集器分其他为gencopy, singlecom, gencon以及parallel。为得到更好的响应性能,应该使用并发垃圾回收器:-Xgc:gencon,可使用-Xms和-Xmx设置堆栈的初始大小和最大值,要设置护理域-Xns为-Xmx的10%。而如果要得到更好的性能,应该选用并行垃圾回收器:-Xgc: parallel,由于并行垃圾回收器不使用nursery,不必设置-Xns。
如果你的线程大于100或者在linux平台下,可以尝试使用瘦线程模式:-Xthinthread,同时关闭Native IO:-Xallocationtype:global。
jRockit 还提供了强大的图形化监控工具Jrockit Management Console。欲详细了解JRockit可访问:http://edocs.bea.com/wljrockit/docs81/index.html。
2.2 Server调优
WebLogic Server的核心组件由监听线程,套接字复用器和可执行线程的执行队列组成。当服务器由监听线程接收到连接请求后,将对它的连接控制权交给等待接收请求的套接字复用器。然后套接字复用器读取离开套接字的请求,并将此请求及相关安全信息或事务处理环境一起置入适当的执行队列中(一般为默认的执行队列)。 当有一个请求出现在执行队列中时,就会有一个空闲的执行线程从该队列中取走发来的该请求,并返回应答,然后等待下一次请求。因此要提高WebLogic的性能,就必须从调整核心组件性能出发。
2.2.1 尽量使用本地I/O库
WebLogic Server有两套套接字复用器:Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置。
2.2.2 调整默认执行线程数
理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总线体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。WebLogic生产环境下默认的线程为25个,随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多,花费在线程切换的时间也就越多,线程数越小,CPU可能无法得到充分利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPUs为基准进行调整。当空闲线程较少,CPU利用率比较低时,可以适当增加线程数的大小(每五个递增)。对于PC Server 和Window 2000,则最好每个CPU小于50个线程, 以CPU利用率为90%左右为佳。由于目前WebLogic执行线程没有缩小线程数的功能,所以应将参数Threads Increase设置为0,同时不应改变优先级的大小。
2.2.3 调整连接参数
WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小,默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。这些参数可以在Console Server Tuning Configration配置栏里找到。
2.2.4 创建新的执行队列
创建新的执行队列有助于解决核心业务优先、避免交叉阻塞、死锁和长时间处理的业务等问题。通常会将自己的执行队列和默认的执行队列设置不同的优先级,这里优先级不应设为9或者10。 定义一个新的执行队列很容易,利用View Excute Queue选项中的Configure a new Excute Queue链接即可定制新的执行队列。创建新的执行队列后,用户需要为应用程序的J2EE组件配置分配策略,以便它可以找到新的队列。举个例子:要将servlet或jsp捆绑到一个特定的执行队列,必须替换web.xml文件项,将wl-dispatch-policy初始化参数设置为自己的执行队列名。
<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>
我们可以为一个jsp或者servlet乃至一个WEB应用设置自己的执行队列。同时也可以为EJB设置自己的执行队列。对于执行时间比较长的MDB,建议使用自己的执行队列。
2.3 JDBC调优
2.3.1 调整连接池配置
JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗,建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。
增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。
尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。
最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology ... tdocs/jdbc9201.html。
2.4 WEB调优
2.4.1 调整WEB应用描述符
WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。 同时生产环境下无需检查Jsp和servlet:JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSPKeep Generated 和JSPVerbose对性能也有帮助。此外,还可以对jsp进行预编译,有两种方法:激活precompile选项;使用weblogic.appc事先编译,建议采用后者。
2.5 JMS调优
1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在jRockit上增加-XXenablefatspin以减少加锁冲突;
2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
3. 使用分布式目的地时,激活连接工厂Load Balancing Enabled ,Server Affinity Enabled;
4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下,则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置;
5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enabled和Bytes Paging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
6. 在运行WebLogic Server进程之外的生产者务必使用流控制, 并增大Send Timeout;
7. 将JMS Server Expiration Scan Interval设很大的值,能禁止主动扫描过期消息;
8. 使用FIFO或者LIFO方式处理目的地消息;
9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。
2.6 EJB调优
2.6.1 调整pool和cache
initial-beans-in-free-pool定义SLSB启动时实例的个数,默认为0,可以调大到正常并发数的大小,以减少初始响应时间。max-beans-in-free-pool为最大个数,默认1000对SLSB来说,在频繁创建和删除实例的情况下很有帮助,一般不用调整,至少设为默认线程数,过大容易造成内存溢出。而对Entity Bean来说,由于是匿名的,所以当频繁使用finder、home和create方法时可以调大。
对SFSB来说,尽量将max-beans-in-cache参数设置得足够的大,以满足Bean实例对最大并发用户数的要求,可以避免有状态会话Bean过多的钝化行为。而idle-timeout-seconds尽量设置小,如果SFSB不用于存储Web应用会话状态可以设置为0。
对于Entity Bean来说, max-beans-in-cache同样可以首先采用默认值1000,监控实例缓存和钝化的情况,再做适当调整。
并行策略concurrency-strategy定义了实体Bean如何管理锁,有四种策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,尽量避免使用互斥策略,如果Bean无需更新操作,使用只读策略,更甚的是,如果Bean的内容不会改变,可设置read-timeout-seconds为0,乐观并行策略时采用事务间缓存策略,在entity-cache描述符中将cache-between-transactions元素设为true。
2.6.2 优化事务隔离级别和事务属性
对EJB组件来说,有四种事务隔离水平:
TRANSACTION-SERIALIZABLE:在处理完成之前拒绝其他处理的读入、可扩展性或插入数据操作;
TRANSACTION-REPEATABLE-READ:防止处理修改正在被其他处理调用的数据;
TRANSACTOIN-READ-COMMITTED:防止对正在被其他处理修改的数据执行写锁定;
TRANSACTION-READ-UNCOMMITTED:允许处理读入未受权的数据以及允许在向结果中添加记录时可以忽略处理。
以上隔离水平依次降低,效率和性能依次提高。因此,建议选用满足在业务数据完整性要求前提下水平最低的隔离级别。
对于事务属性的设置也是如此,对于删除、修改和插入操作设置为Required,而对于只读操作设置为Supports或者NotSupports。
2.6.3 其他一些小技巧
1. 利用finders-load-bean的默认值true,既可以避免“n+1”的查询问题,又可以提高系统的性能;
2. 使用delay-updates-until-end-of-tx参数的默认值true,除非应用程序对某些变化有特别的要求;
3. 应用程序在每个业务方法调用后不需要进行存在性检查,将check-exists-on-method设定为false,以提高程序的性能;
4. 同一应用内, 将enable-call-by-reference设置为 true;
5. reentrant设置为false,避免事先加载子数据。
|
|