(1)前台修改方法:
服务器-》服务器类型-》WebSphere Application Server-》 SuiteServer -》 进程定义 -》 Java 虚拟机
通用 JVM 参数-》-Dfileencoding=UTF-8 -Ddefaultclientencoding=UTF-8
(2)后台修改方法:
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/10Cell01/nodes/10Node01/servers/SuiteServer
修改其中的serverxml中的
参数genericJvmArguments="-Dfileencoding=UTF-8 -Ddefaultclientencoding=UTF-8"
2更换合适的db2驱动jar包:
数据源驱动配置位置:资源-》JDBC-》JDBC提供程序,双击可进入查看驱动的具体内容,其中的驱动位置通过环境变量指定;
环境变量配置位置:环境-》Websphere变量一、对外表现
1应用访问速度慢、应用报错(WAS性能差)
2应用(server)停止对外服务无法访问(WAS服务挂起或者服务器宕机)
二、xxx系统我们发现过的问题
1WAS内存处理大对象内存分配bug(大报文(20M)-小报文(20M)-20M)
2内存回收碎片(java heap free memory很多,一个很小的报文都申请不到内存)
3WAS MDB侦听MQ队列问题
三、排查思路
思路:
1查看收集服务器性能指标,内存使用、CPU使用包括磁盘I/O等。
2查看收集 *** 作系统级日志。
3根据服务器的性能指标以及 *** 作系统级日志,基本定位是否存在影响性能的瓶颈,通过排除那些不是导致问题发生的因素,以缩小问题的范围,可以使问题简单化,并且避免浪费时间。举例:
CPU使用不高,用户感觉交易响应时间很长,可以断定是由于系统的某一小部分造成了瓶颈,导致了所有的请求都在等待。我们可以考虑,线程池的数量开的太小,导致所有的请求都在排队等待进入线程池,因为没有可用的线程使用,所以这个交易请求一直在排队,导致交易响应时间很长。数据库连接池开的太小,也会有同样的表现。
CPU使用很高,用户感觉交易响应时间很长,比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下:用性能分析器, 对运行环境进行分析,分析哪个类甚至于哪个函数消耗了这么多的CPU,并找到相应的解决方案。
4收集分析WAS日志
当应用服务器发生挂起、或者发生out-of-memory等现象时,为了更好的全面分析问题,则需要收集一定的日志信息,一般情况下我们需要收集以下这些日志:
1)收集垃圾回收日志native_stderrlog或者native_stdoutlog。
2)收集应用服务器(install_root/profiles/profile_name/logs/server_name)下所有的日志(systemout)。
3)收集install_root/profiles/profile_name/目录下的JavaCore文件和Heapdump文件,如果没有这些文件,可以在服务器没有响应的时候,运行命令来生成这些文件,对于IBM JDK中可以运行kill -3 PID_Java_jvm,然后每隔两分钟,重复执行该命令,至少3次,通过该命令生成的JavaCore文件会在install_root/ profiles目录下。
4)收集首个故障数据捕捉日志/logs/ffdc。
5)收集Web server服务器,插件Plug-in(plugin-cfgxml and >先说说如何部署到NC_HOME:
1把你的UAP项目导出modules,然后把你定义的wsdl和xsd文件导出放入public对应目录下(wsdl对应接口,xsd对应VO)
2把你引入的外部jar包放入对应模块lib文件夹下面(如果有的话,例如wsdj包)
3重启中间件,访问>WAS内部的东西你不要管,发布成功了,能正确访问了,这就够了。
IBM内部的东西不是我们能掌握的,WAS不是TOMCAT,内部的东西你越以为知道得多了可以走后门,不用IBM给你的wsadmin或者WAS CONSOLE发布了,越是容易犯错。IBM的工程师我见得多了,对于自作聪明发布应用遇到问题的客户他们理都不理,马上问你为什么不用正确方式发布应用。方法/步骤
将WAS安装程序上传到服务器,并解压
# tar -zxvf WAS Network Deployment V61 for Linux on x86-64, 64-bittargz
解压后在WAS文件夹下有个responsefilendtxt文件,这个文件是WAS静默安装的配置文件,编辑该文件,并修改如下内容:
-OPT silentInstallLicenseAcceptance="true" 接受License
-OPT allowNonRootSilentInstall="true" 是否允许非root用户安装
-OPT disableOSPrereqChecking="true" 取消对系统的检测
-OPT installType="installNew" 是否全新安装
-OPT feature="noFeature" 不安装示例
-OPT installLocation="/opt/IBM/WebSphere/AppServer" 安装路径
-OPT profileType="none" 不生成概要
-OPT PROF_enableAdminSecurity="false" 不设置管理员安全
注:也可以按照上面内容自行编辑文件,当静默安装时指明该文件即可
文件编辑完成后,执行install命令开始安装。格式如下:
# /install -options responsefilendtxt -silent
由于是静默安装,并且编辑好了配置脚本,因此安装时程序没有什么提示,耐心等待一会,直到安装完成。
如果没有安装成功,如何检查。
由于静默安装没有提示,我们不知道有没有安装成功,尤其是刚执行安装命令后,程序什么提示都没有,就很快结束。这通常都是没有安装成功。这里提供一个检查问题的方法。在用户文件夹下有个waslogs文件夹,这是执行静默安装时自动生成的日志文件,记录了没有安装成功的事件,可以通过日志来判断系统或配置文件哪方面出现了问题。我这里采用root用户安装的,因此在/root文件夹下有waslogs文件夹。
检查日志文件发现是由于配置文件中的安装路径问题,如下图:
安装完成后,如何判断是否安装成功。
安装完成后,会生成一个隐含的文件夹ibm。
AIX系统改文件存在于/usr路径下。
linux等系统存在于/opt路径下。
# ls -alF
通过创建profiles来验证是否安装成功。
# /opt/IBM/WebSphere/AppServer/bin/manageprofilessh -create -profileName testpro -profilePath /opt/IBM/WebSphere/AppServer/profiles/testpro/ -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/default
启动profiles 并检查监听是否运行:
进入新创建的概要testpro/bin文件夹执行下面命令
# sh startServersh server1
# netstat -an |grep 906
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)