weblogic性能优化
64位weblogic安装部署以及常见问题解决

64位weblogic11g安装部署以及常见问题解决方案目录(一) 安装 (1)在Windows 64位操作系统安装Weblogic的注意事项 (3)(二) 部署运行 (3)1. 包引入错误 (3)2.乱码现象 (3)3.mime-typeType配置问题 (4)4.应用不存在 (4)5.ClassNotFoundException: org.hibernate.hql.ast.HqlToken (4)6.weblogic部署war包action不能访问问题解决方法[There is no Action mapped fornamespace / and action name] (5)ng.StackOverflowError (5)(一)安装我们在64位的服务器上为提高性能要安装64位的weblogic。
经常在网上看到有人问,weblogic有64位的么?weblogic需要破解么?weblogic有专门的64位版本,这里安装的是weblogic11g,也就是10.3.6版本,12c的版本安装应该类似。
weblogic从bea被oracle收购后,不需要破解,就只有授权。
什么意思呢?就是说从oracle官网上下载的weblogic 就是全功能版本,不管是集群还是其他,功能没有任何限制。
但是如果要用于商业环境,必须要向oracle买license,当然可以偷偷的用,那就是盗版,侵权,有一天oracle可以告的破产……。
1、下载64位weblogic,打下这个地址::// oracle/technetwork/middleware/ias/downloads/wls-main-097127.html,在这里可以看到除了mac os X操作系统外,其他系统的64位都是同一个版本,wls1036_generic.jar。
如下列图,weblogic的下载需要注册一个oracle官网的帐号。
2、下载64位JDK,我们下载的文件wls1036_generic.jar文件里面不包括JDK,如有可能, 请尽量在Windows/Linux平台下使用JRockit虚拟机,下载地址::// oracle/technetwork/middleware/jrockit/downloads/index.html。
营销业务(系统)、系统级优化方案

目录1.项目简介 (3)2.项目定义 (4)2.1。
系统架构图 (4)2。
2.项目范围 (4)2。
3.项目目标 (4)2.4。
成功要素 (4)2.5.项目交付物 (4)2。
6.实施内容及风险防范措施 (5)2。
6.1。
..................................................................................................................................... 优化实施内容52。
6。
2。
.................................................................................................................................. 风险防范措施52.7.优化策略概述 (5)3。
系统瓶颈总结 (6)3.1.系统瓶颈简介 (6)4。
数据库缺陷消除 (7)4。
1。
..................................................................................................................................................... 死锁现象74。
2.ORA—7445现象 (8)5。
中间件优化 (9)5。
1。
....................................................................................................................................... 中间件基本配置95.2。
JDK优化 (11)5.3.堆栈优化 (11)5。
Weblogic应用层优化调试设置

社区Weblogic应用层优化调试设置
以Weblogic为中间件的社区应用层,有以下性能优化设置供参考。
1、设置为生产模式,增大连接数据
进入weblogic console 点击左边对应的域名,勾选右边的生产模式。
2、Weblogic登录超时时间
进入weblogic console界面,点击左边对应的域名,再点击监视,再点击服务器/子系统名称AdminServer ,再点击调整,可以看到如下图。
3、设置weblogic 占用的内存值
进入weblogic安装域名目录所在的bin文件夹,修改setDomainEnv.sh 文件根据物理机的实际情况设置内存值
4、设置应用服务数据库连接数据
打开应用程序xp-app 的jdbc数据连接文件
根据oracle实际连接数修改jdbc连接数
Oracle连接数据查看show parameter processes;
5、不限制事务数量
修改服务的事务处理数量限制,修改xp-app应用服务的jta.properties
超出默认的50会报错误
Caused by: ng.IllegalStateException: Max number of active transactions reached:50
6、优化程序代码
在weblogic安装域目录下的log日志可以看到严重超时方法。
WebLogic的日常操作和监控

WebLogic的启动
• Admin Server的启动
• startWebLogic.cmd/sh • 在Unix或Linux中为了在telnet退出后让WebLogic继续运行,需要使用 nohup和&符来调用启动命令:nohup ./startWebLogic.sh & • WebLogic的标准输出和标准出错信息会纪录在nohup.out文件中
WebLogic Server的停止- console方式
WebLogic Server的停止- 脚本方式
• Admin Server停止
• ./stopWebLogic.cmd/sh username password
• Managed Server停止
• ./stopManagedWebLogic.cmd/sh <servername> <t3://adminip:adminport> username password
在这条日志信息中,它们的格式是: 时间戳,错误级别,子系统 ,机器名,Server名称,线程号,用户号,事务号,.. 信息号 ,文本信息。 如果这信息包括跟踪堆栈的信息,这些信息将紧跟在这条信息 后面。
如何去分析日志
日志中出现错误,如何去请求帮助
如果日志中出现错误,您可以到BEA网站去查询相关 的错误信息和解决办法,如找不到,可以通过以下途径寻求帮助。
• 范围不同,信息内容也不同
• 涉及Domain范围内的日志写入Domain log(如Cluster,RMI 通讯等信息)
• Domain Log Filter
• 个或多个server按过滤条件过滤后的一些错误信息才传递给 Domain log
• 常见的错误也不同
WebLogic调优参数配置

WebLogic调优参数配置WebLogic 配置文件(config.xml)包含了大量很直观的与性能有关的参数,能通过配置环境与应用程序得到很好的优化。
基于系统的需要调整这些参数不仅能改善单个点的性能,而且能提高整个应用程序性能的可衡量性。
试着采用下列WebLogic配置方法,或许能使你的系统达到最佳状态:一. 修改运行队列线程数的值。
在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。
当任务加入一个WebLogic 实例,它就被放到执行队列中,然后分配给任务一个线程来运行。
线程消耗资源,因此要小心处理这个属性——增加不需要的值,会降低性能。
二. 如果可能,使用自带的性能包(NativeIOEnabled=true)。
三. 使用特定的应用程序执行队列。
四. 使用JDBC连接池时,修改下列属性:●驱动名称:使用小的驱动或者jDriver。
●初始容量:设为与最大容量相同的值。
●最大容量:其值至少应与线程数相同。
五. 把连接池的大小设为与执行队列的线程数相同。
六. 设置缓冲。
七. 为Servlet和JSP使用多个执行队列。
八. 改变JSP默认的Java编译器,javac 比jikes或sj要慢。
提要:为 WebLogic 启动设置 Java 参数。
设置与性能有关的配置参数。
调整开发与产品模式默认值。
使用WebLogic “自有的IO ”性能包。
优化默认执行队列线程。
优化连接缓存。
如何提高 JDBC 连接池的性能。
设置 Java 编译器。
使用 WebLogic 集群提高性能。
监视 WebLogic 域。
一、为 WebLogic 启动设置 Java 参数只要启动 WebLogic ,就必须指定 Java 参数,简单来说,通过 WebLogic.Server 域的命令行就可以完成,不过,由于这样启动的过程冗长并且易于出错, BEA 公司推荐你把这个命令写进脚本里。
为了简化这个过程,你可以修改样例脚本里的默认值,样例脚本是提供 WebLogic 启动服务器的。
weblogic优化指南

优化WebLogic一、为WebLogic启动设置Java参数垃圾收集(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堆栈内存优化,修改配置文件:WL_HOME=C:\bea\weblogic81 "%WL_HOME%\common\bin\commEnv.cmd":bea#如果采用的上bea的JDK# JVM Heap(堆内存)最小尺寸为96M,最大尺寸为256Mset MEM_ARGS=-Xms96m -Xmx256m:sun#如果采用的是sun的JDK# JVM Heap(堆内存)最小尺寸为32M,最大尺寸为200M#公共变量对象的内存限制: PermSize:最小尺寸, MaxPermSize :最大允许分配尺寸set MEM_ARGS=-Xms32m -Xmx200m -XX:MaxPermSize=128m监视堆栈使用情况:下载JRockit JDK,该JDK已经自带了JRockit Mission Control工具,目前好像还没有单独下载JRockit Mission Control的地方,于JRockit JDK进行了绑定下载;在C:\bea\jrockit81sp5_142_08\console目录里面运行:C:\bea\jrockit81sp5_142_08\bin\java –Xmanagement -jar ManagementConsole.jar 如何监控weblogic呢?修改weblogic启动脚本startWebLogic.cmd,在里面加入-Xmanagement启动参数:%JAVA_HOME%\bin\java -Xmanagement %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% =%SERVER_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE% -Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server二、设置与性能有关的配置参数在一个WebLogic域中,配置文件(config.xml)位于与管理服务器通信的机器里,提供WebLogic MBean的长期存储。
weblogic的使用

weblogic的使用
WebLogic是一种常用的Java应用服务器,它能够提供高度可扩展的企业级应用程序运行环境。
使用WebLogic可以简化应用程序开发、部署和管理过程,提高应用程序的可靠性和性能。
以下是WebLogic 的使用方法:
1. 安装WebLogic服务器:在官方网站下载WebLogic服务器安装包,按照安装向导完成安装过程。
2. 创建WebLogic域:WebLogic域是WebLogic服务器的逻辑管理单元,通过创建域可以管理应用程序、配置服务器等。
使用配置向导创建域。
3. 部署应用程序:将应用程序的WAR或EAR文件部署到WebLogic 服务器中,可以使用WebLogic控制台或命令行工具进行部署。
4. 配置服务器:通过WebLogic控制台或命令行工具可以配置WebLogic服务器,如配置JDBC数据源、安全设置、JMS等。
5. 启动和停止服务器:可以使用WebLogic控制台或命令行工具启动和停止WebLogic服务器。
6. 监控服务器:通过WebLogic控制台可以实时监控WebLogic 服务器的运行状态、应用程序状态、日志等信息。
7. 优化服务器性能:WebLogic服务器提供了多种性能优化选项,如配置缓存、调整线程池大小等。
8. 备份和恢复服务器:通过备份WebLogic域和应用程序,可以实现服务器数据的备份和恢复。
WebLogic的使用需要一定的Java和Web应用程序开发基础,但是通过学习官方文档和示例,可以快速掌握WebLogic的使用方法。
性能分析——精选推荐

性能分析性能结果分析是性能测试中的⼀个重要部分,同时也是⼀个难点。
由于不同的软件系统,不同的性能指标,结果分析⽅法都是不⼀样的。
需要具体问题具体分析。
下⾯将阐述⼀些性能分析的⽅法与建议。
1 性能分析的⽬的1)找出系统瓶颈(硬件、软件)2)提出性能优化⽅案3)达到合理的硬件和软件配置4)使系统资源使⽤达到最⼤平衡2 常见性能瓶颈征兆在性能测试执⾏过程中,我们需要观察和了解系统的运⾏状态,如果出现以下征兆,则表⽰系统可能存在瓶颈。
1) 持续缓慢:应⽤程序⼀直特别慢,改变负载,对整体响应时间影响很少;2) 随着时间推进越来越慢:负载不变,随着时间推进越来越慢,可能到达某个阈值,系统被锁定或出现⼤量错误⽽崩溃;3) 随着负载增加越来越慢:每增加若⼲⽤户,系统明显变慢,⽤户离开系统,系统恢复原状;4) 零星挂起或异常错误:可能是负载或某些原因,⽤户看到页⾯⽆法完成并挂起,⽆法消除;5) 可预见的锁定:⼀旦出现挂起或错误,就加速出现,直到系统完全锁定。
通常要重启系统才解决。
6) 突然混乱:系统⼀直运⾏正常,可能是⼀个⼩时或三天之后,系统突然出项⼤量错误或锁定。
3 性能数据解读建议性能分析过程也是⼀个解读数据的过程,读懂了数据你就能知道问题出在何处。
随着经验的累积将会很容易判断问题的根源,甚⾄在开发阶段就能对可能出现问题的点打预防针。
性能指标类型标准性能瓶颈征兆分析⼯具TPS及其波动范围1.Tps符合性能⽬标2.Tps轨迹波动平稳1.TPS有明显的⼤幅波动,不稳定。
例如TPS轨迹缓慢下降,缓慢上升后骤降,呈瀑布型,呈矩形,分时间段有规律的波动,⽆规律的波动等。
这些TPS的波动轨迹反映出被测试的性能点存在性能瓶颈,需要性能测试⼯程师与开发⼯程师查找性能瓶颈的原因。
2. TPS轨迹⽐较平稳,但是也存在波动现象。
该类波动不明显,很难直接确定是否存在性能瓶颈。
我们需要根据其他指标来进⾏判断。
Jmeter/loadrunner响应时间90%平均事务响应时间<性能⽬标1.关注⾼峰负载时,⽤户操作响应时间;2.关注数据库增量,对⽤户操作响应时间的影响。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
优化WebLogic 服务器性能参数WebLogic 配置文件(config.xml)包含了大量很直观的与性能有关的参数,能通过配置环境与应用程序得到很好的优化。
基于系统的需要调整这些参数不仅能改善单个点的性能,而且能提高整个应用程序性能的可衡量性。
试着采用下列WebLogic配置方法,或许能使你的系统达到最佳状态:一修改运行队列线程数的值。
在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。
当任务加入一个WebLogic 实例,它就被放到执行队列中,然后分配给任务一个线程来运行。
线程消耗资源,因此要小心处理这个属性——增加不需要的值,会降低性能。
二,如果可能,使用自带的性能包(NativeIOEnabled=true)。
三,使用特定的应用程序执行队列。
四,使用JDBC连接池时,修改下列属性:n 驱动名称:使用小的驱动或者jDriver。
n 初始容量:设为与最大容量相同的值。
n 最大容量:其值至少应与线程数相同。
五,把连接池的大小设为与执行队列的线程数相同。
六,设置缓冲。
七,为Servlet和JSP使用多个执行队列。
八,改变JSP默认的Java编译器,javac 比jikes或sj要慢。
优化WebLogic提要:n为WebLogic启动设置Java参数。
n设置与性能有关的配置参数。
n调整开发与产品模式默认值。
n使用WebLogic“自有的IO”性能包。
n优化默认执行队列线程。
n优化连接缓存。
n如何提高JDBC连接池的性能。
n设置Java编译器。
n使用WebLogic集群提高性能。
n监视WebLogic域。
一、为WebLogic启动设置Java参数只要启动WebLogic,就必须指定Java参数,简单来说,通过WebLogic.Server域的命令行就可以完成,不过,由于这样启动的过程冗长并且易于出错,BEA 公司推荐你把这个命令写进脚本里。
为了简化这个过程,你可以修改样例脚本里的默认值,样例脚本是提供WebLogic启动服务器的。
如果你用配置向导创建你的域,WebLogic启动脚本(startWebLogic.cmd)放在domain-name目录里。
默认情况下,这个目录是BEA_HOME\user_pr ojects\domain\domain-name,BEA_HOME表示安装路径,domain-nam e是在配置模板中设置的域名称。
备不过,如果你一定要用纯Java socket读在主机上运行,你仍然可以通过配置每个服务器实例和客户机中适当的socket读的线程数量,来提高socket 通信的性能。
设置性能包的操作方法:默认情况下,装载在config.xml中的是自有的性能包。
为了验证这个设置,在配置文件中检查NativeIOEnabled属性是否设为“true”(NativeIOEnable d=true)。
你也可以通过管理控制台来验证,步骤如下:1,启动管理服务器。
2,访问管理控制台。
3,展开左边面板的Servers 节点,显示域服务。
4,点击你要配置的服务实例。
5,选择Configuration->Tuning tab。
6,如果Enable Native IO复选框没有被选择,选中即可。
7,点击Apply。
8,重启服务器。
五、优化默认执行队列线程默认情况下,一个新的WebLogic实例配置了一个开发模式执行队列,we blogic.kernel.default,它包含15个线程。
另外,WebLogic提供了2个预配置队列:n weblogic.admin.HTTP——只在管理服务器上才有,这个队列供与管理控制台的通信用,你不能再配置它。
n weblogic.admin.RMI——管理服务器和被管理服务器上都有这个队列,它是供管理的交通之用,也不能再配置它。
如果你不配置额外的执行队列,并且指定应用给这些队列,web 应用程序和RMI对象就使用默认的队列weblogic.kernel.default。
注意;如果自带的执行包没有在你的平台上使用,你可能需要调整默认的执行队列线程数和担任socket读的线程的百分比,去实现最佳性能。
5.1你应该更改默认的线程数吗?增加更多的线程到默认的执行队列并不意味着你能处理更多的工作。
即使增加更多的线程,仍然被处理器的能力限制。
因为线程消耗内存,所以增加线程数属性的值不必要的降低了性能。
一个高的执行线程数导致更多的内存被占用并且增加了上下文转换程序,它也会降低性能。
线程数属性的值与应用程序处理的工作的类型关系密切。
例如,如果你的客户应用程序比较小,通过远程调用处理的工作较多,这样,客户端会花费更多的时间连接,因此,与能完成大量客户端任务的客户应用程序相比,会需要更多的线程数。
如果你的工作不需要使用超过15个线程(开发模式默认)或者25个线程(产品模式默认),就不要改变这个属性的值。
通常,如果你的应用程序访问数据库花很长时间才返回6.填下适当的线程数。
7.点击Apply,保存刚才的修改。
8.重启服务器,使新的执行队列设置生效。
5.4指派应用程序到执行队列虽然可以配置默认的执行队列,为所有的WebLogic应用程序提供最佳的线程数,但是为关键的应用程序配置多个执行队列可以提供更多的管理控制。
通过使用多执行队列,你可以保证应用程序有权占用固定的线程数,而不管Web Logic服务器有多大的负荷。
5.5创建执行队列一个执行队列代表执行线程的命名集,线程指向一个或多个Servlet、JSP、EJB、RMI对象。
执行队列在config.xml文件中描述,作为服务器元素的一部分。
如,在config.xml文件中描述一个有4个线程的队列,命名为CriticalAp pQueue,如下:...<ServerName="examplesServer"ListenPort="7001"NativeIOEnabled="true"/><ExecuteQueue Name="default"ThreadCount="15"/><ExecuteQueue Name="CriticalAppQueue"ThreadCount="4"/>...</Server>另一种创建队列的方法是通过管理控制台,配置步骤如下:1.启动管理服务器,访问控制台。
2.展开左边面板中Servers节点,显示域中要配置的服务。
3.右击你要增加队列的服务实例,从弹出菜单中选择View Execute Queues。
4.在队列配置标签中,点击配置新执行队列链接。
5.在队列配置标签中,更改下列属性或接受系统的默认值:n线程名称(Name):你可以输入线程名称,如CriticalAppQueue。
n队列长度(Queue Length):通常保留默认值65536,队列长度表明了同时发来请求的最大数,65536个请求是个很大的数,即使达到这个最大数,也是很少见的。
如果达到最大队列长度,WebLogic会自动成倍增长队列大小,以处理额外的工作。
注意:超过65536个请求预示队列中的线程有问题,不仅仅只是队列本身的长度问题,实践表明在队列中有堵塞线程或线程数不足的情况存在。
n队列长限制百分比(Queue Length Threshold Percent):达到队列长度百分比(1-99)时,就构成了溢出条件的产生。
实际队列大小在限制的百分比之下时才被认为是正常的;在限制百分比之上就会产生溢出。
当出现溢出,WebLogic日志就会产生一个错误消息,并且按线程数增量(Threads In crease)属性的值增加线程数,以帮助减少负载量。
默认的队列长限制百分比为90%。
一般情况下,应保留90%或其左右,以应对一些潜在的情况,使得有额外的线程可以去处理一些请求中的异常。
记住,队列长度限制百分比不是一定作为自动优化参数――因为正常运作情况下,这个限度从不会被触发。
n线程数(Tread Count):指派到这个队列的线程数。
如果你不需要使用超过15个线程(默认),就不必更改这个属性值。
n线程数增量(Threads Increase):是指WebLogic探测到有溢出时,增加到执行队列的线程数。
当你指定为0(默认),出现溢出时,WebLog ic会把运行良好状态改为“警告”,而且也不会指派额外的线程去减少负荷量。
注意:如果WebLogic实例的线程数响应了溢出,那么这些额外的线程就会滞留在执行队列,直到服务器重启。
监视错误日志,以判断溢出产生的原因,以便根据需要重配置线程数,防止以后类似情况产生。
不要同时使用线程数增量和队列长限制百分比作为自动优化的手段。
如此做通常结果会产生比正常需要还多的线程被指派到执行队列,这样上下文转化程序的增多会使服务器遭受很差的性能。
n最大线程数:是指执行队列中能运行的,这个值保护WebLogic为了响应频繁溢出,创建过多的线程数。
默认情况下,最大线程数为400。
n线程优先级:线程优先级与此队列相关。
默认值为5。
6.点击Create,创建队列。
7.重启服务器。
5.6指派Servlet和JSP到执行队列你可以把servlet或JSP分配到指定的配置执行队列,只需在初始参数中标识执行队列的名称。
初始参数出现在Servert或JSP的部署描述文件web.x ml中的init-param元素里。
为了分配一个队列,可以把队列名作为wl-dispa tch-policy参数的值。
如:<servlet><servlet-name>MainServlet</servlet-name><jsp-file>/myapplication/critical.jsp</jsp-file><init-param><param-name>wl-dispatch-policy</param-name><param-value>CriticalAppQueue</param-value></init-param></servlet>5.7指派EJB和RMI对象到执行队列为了把EJB分配到指定的队列,可以使用weblogic-ejb-jar.xml文件中d ispatch-policy元素。
然而你也可以通过使用appc编译器-dispatchPolicy选项来设置派遣策略,BEA强烈推荐使用部署描述元素。
因为用这种方式,如果EJB重编译,在部署用例期间,这个设置不会被丢失。