weblogic性能优化
- 格式:doc
- 大小:116.50 KB
- 文档页数:14
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为中间件的社区应用层,有以下性能优化设置供参考。
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 配置文件(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启动设置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是一种常用的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.关注数据库增量,对⽤户操作响应时间的影响。
优化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 JDBC配置 JDBC 数据源本部分包括以下信息:∙了解 JDBC 数据源∙创建 JDBC 数据源∙事务选项∙连接缓冲池功能∙设置数据库安全凭据∙调整数据源连接缓冲池选项∙在服务器和群集上部署数据源∙最大程度地减少由不响应的数据库引起的服务器启动暂停∙JDBC 数据源的安全∙JDBC 数据源工厂(不赞成使用)了解 JDBC 数据源在 WebLogic Server 中,可通过将数据源添加到您的 WebLogic 域来配置数据库连接。
WebLogic JDBC 数据源提供了数据库访问和数据库连接管理。
每个数据源都包含一个数据库连接缓冲池,其中的数据库连接是在创建数据源时和启动服务器时创建的。
应用程序会通过在 JNDI 树中或在本地应用程序上下文中查找数据源,然后调用 getConnection()来保留来自数据源的数据库连接。
完成连接后,应用程序应尽早调用 connection.close(),该方法会将数据库连接返回缓冲池以供其他应用程序使用。
数据源及其连接缓冲池可以提供有助于保持系统运行和性能的连接管理进程。
可以设置数据源中的选项以满足您的应用程序和您的环境的需要。
以下部分描述了这些选项以及如何启用这些选项。
创建 JDBC 数据源要在您的 WebLogic 域中创建 JDBC 数据源,可以使用管理控制台或 WebLogic 脚本工具 (WLST)。
有关详细信息,请参阅以下部分:∙"“管理控制台联机帮助”中的创建 JDBC 数据源∙"“WebLogic 脚本工具”中的创建 JDBC 资源注意:WLST 已取代了 weblogic.Admin 命令行实用工具。
WebLogic Server 示例(可选择将其随 WebLogic Server 一起安装)包含了可用来代替weblogic.Admin JDBC 命令的示例脚本。
如果已安装了上述示例,则这些示例脚本可从WL_HOME\samples\server\examples\src\examples\wlst\online 获得,其中,WL_HOME 指 WebLogic 主目录,如 C:\bea\weblogic91。
WebLogic Server Performance and TuningWebLogic Server性能调整Tuning Java Virtual Machines (JVMs)调整java虚拟机Garbage Collection垃圾回收VM Heap Size and Garbage Collection虚拟机堆大小和垃圾回收java堆是java对象存活的地方。
其中存有live对象,dead对象和空闲内存。
当正运行的程序中某个对象不可达时,它就被认为是“garbage”并且准备被回收。
一个最优方法是调整垃圾回收时间在执行时间的5%之内。
java虚拟机的堆大小决定了虚拟机垃圾回收的频率和用时。
要在分析垃圾回收的时间运行时间和频率后再将对大小调整到一个可接受的比率。
如果堆设置的大了,full GC 一次就变慢,但发生频率低。
如果根据你的需要设置堆大小,则full GC一次就变快,但是发生频率高。
调整堆大小的目标是,使给定时间内weblogic server能服务的客户数最大化,与此同时,使java虚拟机花在垃圾回收上的时间最小化。
在benchmarking内为了确保性能,你可能设置很大的堆大小以确保在整个benchmark运行中都不发生垃圾回收。
如果在没有堆空间的情况下运行,你会看到如下错误:ng.OutOfMemoryError <<no stack trace available>>ng.OutOfMemoryError <<no stack trace available>> Exception in thread "main"Choosing a Garbage Collection Scheme选择垃圾回收计划根据所使用的java虚拟机,可以从几个垃圾回收计划来管理你的系统内存。
例如,某些垃圾回收计划更适合特定应用。
WebLogic 12C——实现你的“云”计划将应用构建在云基础架构之上Oracle 帮助你构建云的基础架构User EngagementIdentity Management & SecurityBusiness Process Management Content Management Business IntelligenceService Integration Data IntegrationDevelopmentToolsEnterprise ManagementWebSocialMobileCloud ApplicationFoundationCloud Application FoundationTraffic DirectorExalogic Elastic CloudOracle PublicCloudWebLogic ServerCoherenceTuxedoVirtual Assembly BuilderWhy WebLogic 12 C构建弹性云•• • 传统应用向“云”过渡•OVAB ——虚拟环境装配生成器,快速配置企业多层应用并部署到虚拟和云环境中 •ActiveCahce ——零代码修改分布式缓存 •Seamless Upgrade ——无缝升级管理、诊断、维护“云”•APM ——应用性能管理 •SLM ——服务水平管理 •内存网格管理实现“云”计划的WebLogic 12CActive GridLink —— 增强应用服务器与数据库连接的弹性 Active Cahce —— 零代码修改分布式缓存 Traffic Management —— 流量控制增强服务器弹性 Self-tuning —— 自调优增强应用、模块、用户体验的适应性Why 12CWhats Newin 12C新一代的WebLogic 与Oracle RAC 的整合:Active GridLink构建弹性云•••向“云”过渡•OVAB•ActiveCahce•Seamless Upgrade管理 “云”•APM •SLM•内存网格管理Active GridLink ActiveCahceTraffic Management Self-tuning •通过支持Oracle SCAN 方式,通过一个名字访问后端多个RAC 节点,向应用层屏蔽RAC 节点的变化,是弹性云数据访问的基础;•为自适应的池管理提供基于事件的 模型(ONS and FAN),获悉RAC 主动发出的状态信息;•快速连接故障切换(FCF) –支持数据库计划内停机–支持数据库计划外停机 –动态增加新数据库实例•运行时的负载均衡能力 •提供Http 客户端对RAC 全局事务访问的亲和能力,提高数据访问性能集成最好的分布式内存网格构建弹性云•••向“云”过渡•OVAB•ActiveCahce•Seamless Upgrade管理 “云”•APM •SLM•内存网格管理Active GridLink ActiveCahceTraffic Management Self-tuning •分布式缓存为“云”架构提供更高的吞吐能力 •跨应用的共享内存网格 •动态增减内存网格节点,支持线性增加上千节点 •通过内存网格集群增强业务可用性 •减少对后端的IO 提供更强的并行访问能力“云”访问的流量控制12c 集成流量管理构建弹性云•••向“云”过渡•OVAB•ActiveCahce•Seamless Upgrade管理 “云”•APM •SLM•内存网格管理Active GridLink ActiveCahceTraffic Management Self-tuning •集成Oracle Traffic Director (基于软件的负载均衡) •路由,负载均衡,流量控制 •高可用 •高性能•可屏蔽WebLogic 集群的动态变化 • 3.5X 于Apache 的吞吐,并降低 28% 的CPU 消耗 •反向代理•内存中的HTTP 1.1缓存 •支持Infiniband/SDP •支持OVM/OVABWhy 12CWhats Newin 12C划分“云” 服务的优先级自调优与工作管理器构建弹性云•••向“云”过渡•OVAB•ActiveCahce•Seamless Upgrade管理 “云”•APM •SLM•内存网格管理Active GridLink ActiveCahceTraffic Management Self-tuning 云中的服务、用户需要有不同的SLA 。
【转】Weblogic挂起、宕机问题分析及优化出处: /entry/id/2d66195f2b556337012b55bc34a500b1.htmlWeblogic挂起、宕机问题分析及优化1) 中间件weblogic简介1.略2) weblogic挂起1.表现现象∙服务器不在响应请求,页面很久还打不开∙请求超时∙请求处理的时间越来越长通常,服务器挂起不会表现为服务器崩溃,进入控制台查看server实例状态,仍然是RUNNING状态,进到请求队列里面查看,发现空闲执行线程没有了,如下图:查看server状态:访问WebLogic中文博客查看所有队列:访问WebLogic中文博客⒉分析服务器挂起的原因⑴ webloigc各线程队列工作原理Execute Queueweblogic.admin.HTTP: 供与管理控制台的通信用weblogic.admin.RMI: 管理服务器和被管理服务器上都有这个队列,它是供管理的交通之用weblogic.kernel.Default: 执行队列线程weblogic.kernel.System: weblogic自用访问WebLogic中文博客即ListenThread传入àsocket reader线程池(本地性能包) à执行线程池,对每个server做threaddump的时候正常可以看到如下图线程信息,如果没有看到socket reader或者是ListenThread,那么这个server工作是不正常的,此时server可能处于fail状态访问WebLogic中文博客访问WebLogic 中文博客 ListenThread负责响应所有请求,然后传入给socket reader 线程,Socket Reader 线程接受来自监听线程队列的传入请求,并将该请求放入执行线程队列,执行线程负责执行具体任何。
上面其中任何一个环节工作不正常均有可能造成挂起的现象。
weblogic restful参数摘要:1.Weblogic 介绍2.RESTful API 概述3.Weblogic RESTful 参数详解4.应用Weblogic RESTful 参数的实例5.总结正文:1.Weblogic 介绍Weblogic 是美国Oracle 公司出品的一个application server,它是一个基于Java 的、分布式的、支持多协议的、与平台无关的Web 应用服务器。
Weblogic 能够部署和运行Java EE 应用,支持的服务包括Servlet、JSP、JavaBean、EJB 等,同时也支持HTML、XML 等网络协议。
2.RESTful API 概述REST(Representational State Transfer)是一种基于HTTP 协议的Web 服务架构风格。
它强调简单性、可扩展性和可维护性,通过使用HTTP 协议的方法(如GET、POST、PUT、DELETE)和资源(如URL)来实现客户端与服务器之间的通信。
RESTful API 是一种遵循REST 原则的Web 服务接口设计风格,广泛应用于现代Web 应用开发。
3.Weblogic RESTful 参数详解Weblogic RESTful 参数是指在Weblogic 中配置和优化RESTful Web 服务的相关设置。
主要包括以下几方面:(1)端口号:Weblogic RESTful 服务默认监听8080 端口,用户可以根据需要修改为其他端口。
(2)协议:Weblogic RESTful 服务支持多种协议,如HTTP、HTTPS 等。
用户可以根据需要进行选择。
(3)服务名称:用于标识Weblogic RESTful 服务,方便客户端调用。
(4)虚拟主机:设置Weblogic RESTful 服务所在的虚拟主机,用于区分不同的服务实例。
(5)是否启用安全:根据需要设置Weblogic RESTful 服务是否启用安全策略,如认证、授权等。
weblogic线程池释放机制WebLogic线程池是WebLogic服务器中的一个重要组件,用于处理来自客户端的请求。
线程池的作用是控制并发请求的数量,有效地利用服务器资源,提高系统的性能和吞吐量。
然而,如果线程池没有得到正确的释放,就会导致系统出现性能问题甚至崩溃。
因此,WebLogic线程池的释放机制非常重要。
WebLogic线程池的释放机制是指线程池在完成任务后如何释放线程资源,以便其他请求能够继续使用。
在WebLogic中,线程池的释放机制主要有两种方式:主动释放和被动释放。
主动释放是指线程池在任务完成后主动释放线程资源。
这种释放机制通常使用空闲线程超时时间来实现。
当线程池中的线程处于空闲状态一定时间后,系统会自动释放这些线程资源。
这样可以确保线程池中的线程数量始终保持在一个合理的范围内,避免资源浪费。
被动释放是指线程池在任务执行期间发生异常或超时时,被动释放线程资源。
当任务执行出现异常或超时时,线程会被中断并释放资源,以便其他请求能够得到处理。
这种释放机制可以避免因为某个任务的异常导致整个线程池无法正常工作。
WebLogic线程池的释放机制还可以根据应用程序的需要进行配置。
可以设置线程池的最小线程数和最大线程数,以及线程空闲时间等参数。
通过合理配置这些参数,可以达到最佳的性能和资源利用效果。
除了线程池的释放机制,还可以通过其他方式来优化线程池的性能。
例如,可以使用线程池管理工具来监控线程池的状态和性能指标,及时进行调整和优化。
还可以使用任务队列来缓冲请求,减轻线程池的压力。
此外,还可以使用线程池的拒绝策略来处理超过线程池容量的请求,避免系统崩溃。
WebLogic线程池的释放机制对于系统的性能和稳定性非常重要。
通过合理配置和优化线程池的释放机制,可以提高系统的性能和吞吐量,确保系统的稳定运行。
同时,还可以通过监控和调整线程池的状态和性能指标,及时发现和解决问题,保证系统的可靠性和稳定性。
WEBLOGIC启动JVM参数设置经验2011-11-01 08:41:46分类:Linux1. 堆大小设置JVM 中最大堆大小有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制。
32位系统下,一般限制在1.5G~2G;64为操作系统对内存无限制。
我在Windows Server 2003 系统,3.5G物理内存,JDK5.0下测试,最大可设置为1478m。
典型设置:o java -Xmx3550m -Xms3550m -Xmn2g -Xss128k-Xmx3550m:设置JVM最大可用内存为3550M。
-Xms3550m:设置JVM促使内存为3550m。
此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g:设置年轻代大小为2G。
整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。
持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。
此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。
-Xss128k:设置每个线程的堆栈大小。
JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。
更具应用的线程所需内存大小进行调整。
在相同物理内存下,减小这个值能生成更多的线程。
但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。
o java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。
设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。
ezoffice性能的优化调整1、ezOFFICE2007安装后需要进行oracle和weblogic的优化,经验证明,只有优化才能提高性能、避免以下问题:●weblogic不定期自动关闭,或者运行一段时间就要重起服务,否则用户登录不了系统。
●页面打开慢,如公文处理标签。
或者较多用户同时在线时,系统资源消耗大,不能承受起码的访问压力。
2、如果ezOFFICE需要重新迁移,直接拷贝bea目录即可。
不过,这样会带来性能低下的问题,如果重新部署weblogic,则可能提高性能。
在ezOFFICE项目实施中,必须依照本配置说明进行性能优化。
一、Oracle配置【必配】1.进入Oracle Enterprise Manager Console,选择独立启动2.用具有sysdba角色的用户登陆,如下图,选择身份拦选择sysdba:3.进入数据库展开例程,点击配置,点击主窗口的内存栏,进入内存设置页:4.一般SGA的大小为物理内存的一半左右,当系统在线用户在100人左右时,SGA大小应为1G左右,也可以点击建议按纽,根据系统建议设置各参数大小。
调整后高速缓存命中率应不小于95%,最好在100%以服务器物理内存2G为例,各参数配置如下:共享池:600m缓冲区高速缓存:400m大型池:64mJava池:32m总计PGA目标:64m以上也许数据并非最优,应根据数据库使用情况及时调整注意:在调整参数前先修改SGA的最大大小,否则有可能保存不成功调整参数后数据库有可能需要重新载入,与客户端的连接将关闭以服务器物理内存4G为例,各参数配置如下:二、Weblogic配置【必配】Weblogic 安装后设置均为默认,并非最忧,应做适当调整1.数据库连接池的调整100人左右在线时,默认数据库连接池已不能满足需求进入JDBC Connection Pools>PoolName 点击connections栏,参数修改如下:Initial Capacity:40Maximum Capacity:60Capacity Increment:1Statement Cache Size:502.如果应用服务器CPU是双线程,则操作系统要使用win2003其性能才能发挥出来;如果是win2000系统,请换成win2003。
优化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重编译,在部署用例期间,这个设置不会被丢失。