问题
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 and
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
but unfortunately unsucess
Does anyone have any suggestions on how to determine the root cause?
thanks in advance
回答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.
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).
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>
There is a detailed script for Linux with more options at this link.
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)
Invoke the jython script using wsadmin:
wsadmin -lang jython -f ThirtyThreadDumps.py
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.
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.
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.
来源：https://stackoverflow.com/questions/58526450/how-how-to-solve-slow-in-websphere-9-0-0-2