如何解决Websphere 9.0.0.2中的缓慢问题 [英] How how to solve slow in websphere 9.0.0.2
问题描述
我正在使用Websphere 9.0.0.2开发一个项目 而且我在部署和应用程序方面遇到问题 更新时间.我的申请大约需要15-20 分钟即可部署.
Hi I'm working an a project with websphere 9.0.0.2 and I have problem with deployment and application update times. my application takes around 15-20 minutes to deploy.
I perform the informed at site https://www.ibm.com/developerworks/community/forums/html/topic?id=92094a07-b456-4f6f-89cd-7b6e59a0b1a3 setting these properties in the JVM
com.ibm.ws.cdi.enableImplicitBeanArchives = false和
com.ibm.ws.cdi.enableImplicitBeanArchives=false and
com.ibm.ws.cdi.enableImplicitBeanArchives = false com.ibm.ws.amm.scan.context.filter.archives = fastjson-1.1.37.jar，flexjson-2.1.jar，guava-18.0.jar，mvel2-2.2.0.Final.jar
too com.ibm.ws.cdi.enableImplicitBeanArchives=false com.ibm.ws.amm.scan.context.filter.archives=fastjson-1.1.37.jar, flexjson-2.1.jar, guava-18.0.jar, mvel2-2.2.0.Final.jar
但不幸的是没有成功
有人对如何确定根本原因有任何建议吗?
Does anyone have any suggestions on how to determine the root cause?
预先感谢
推荐答案
首先，有时候，如果您安装了最新的修订包，您的问题将简单地解决. V9.0.0.2非常旧. 9.0早期的版本中存在一些性能问题.当前的修订包是9.0.5.1.
First, sometimes your problem will simply go away if you install the latest fix pack. V9.0.0.2 is very old. There were some performance issues in the early 9.0 versions. The current fix pack is 9.0.5.1.
要调试性能问题，请关闭所有跟踪并定期收集Java线程转储.我希望至少看到10个，但是更好.只需将您关心的时间间隔至少除以10.对于需要15分钟的时间，请至少每1.5分钟(90秒)生成一次线程转储.
To debug performance issues, turn off all traces and collect java thread dumps periodically. I like to see at least 10, but more is better. Simply divide the time interval that you are concerned about by at least 10. For something that takes 15 minutes, generate a thread dump at least every 1.5 minutes (90 seconds).
如果使用Linux，则可以使用watch命令.例如，要每30秒创建一个转储:
If using Linux, you could use the watch command. For example, to create a dump every 30 seconds:
watch -n 30 kill -3 <PROCESS_NUMBER_OF_APP_SERVER>
有一个针对Linux的详细脚本，其中包含更多选项在此链接.
There is a detailed script for Linux with more options at this link.
如果使用Windows，则可以使用wsadmin和Jython脚本自动执行线程转储.例如，将以下内容放入文件中 名为ThirtyThreadDumps.py(用"server1"替换正确的服务器名称):
If using Windows, thread dumps can be automated using wsadmin and a Jython script. For example, put the following contents in a file named ThirtyThreadDumps.py (substitute the correct server name for "server1"):
jvm = AdminControl.completeObjectName('type=JVM,process=server1,*')
for x in range(30):
AdminControl.invoke(jvm, 'dumpThreads')
Sleep(30)
使用wsadmin调用jython脚本:
Invoke the jython script using wsadmin:
wsadmin -lang jython -f ThirtyThreadDumps.py
在线程转储中，查找出现在多个转储中的堆栈.我发现部署期间相关的WebSphere堆栈至少有15个调用，通常更多.因此，我通常在转储的stacktrace部分中滚动，直到视觉上弹出一个深层堆栈为止.然后，我在堆栈中选择一行或2行并进行搜索(grep或findstr取决于平台).这样可以快速告诉您堆栈是否出现在多个线程转储中.
In the thread dumps, look for a stack that appears in multiple dumps. I find that the relevant WebSphere stacks during deployment are at least 15 calls deep and usually more. So I generally scroll through the stacktrace section of the dump until a deep stack visually pops out. Then I pick a line or 2 in the stack and search (grep or findstr depending on platform). That will quickly tell you if the stack appears in multiple thread dumps.
最终，这将向您显示哪个WebSphere代码是罪魁祸首，这可能会或可能不会帮助您，这取决于WebSphere类和方法的名称在堆栈中的质量.
Ultimately, this is going to show you which WebSphere code is the culprit, which may or may not help you depending on how good the names of the WebSphere classes and methods are in the stack.
下一步是致电IBM.如果您已经有了线程转储，那么您的案例应该会更快.
The next step would be to call IBM. If you already have thread dumps in hand, your case should move faster.
请记住，创建线程转储时不要运行任何日志记录/跟踪很重要.否则，您只会了解到日志记录和跟踪是性能问题.
Remember it is important to not run any logging/tracing when creating thread dumps. Otherwise, you will only learn that logging and tracing are a performance problem.
这篇关于如何解决Websphere 9.0.0.2中的缓慢问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
