Symptom:
An application is not responding to incoming requests. The application server process is no longer running.
When we encounter application
server crash or hang.
In both cases, the application server is
unresponsive. The difference is that for a crash
the application server process dies
unexpectedly and for a hang the
process is still running.
You should check to see if the application server
process is running to determine if you are experiencing a crash or a hang. To
do this, you need to know the process ID of the application server. You can
then use the appropriate operating system command to check to see if the process is running. If it is
not running, the problem is a crash. If it is running, the problem is a hang.
If a problem does occur
that might negatively impact your business, you need to be able to respond
quickly and effectively.
To quickly identify the
root cause of problems that does occur to minimize the business impact.
Most problems are caused by
configuration issues, environment issues, application code defects, or a
misunderstanding of WebSphere Application Server. Many of these problems can be
resolved easily without calling IBM Support to open a problem management record
(PMR).
àTypes of Problem Symptoms:
Here are the common types of symptoms that you might see. Almost every symptom falls into one of these categories:
a. We cannot install or
migrate WebSphere Application Server or install an application into WebSphere Application Server.
b. We experience
difficulties in WebSphere Application Server system management or
configuration.
c. An application or
WebSphere Application Server process (for example, an application server, node
agent, or deployment manager) is unable to start.
d. An application does not
respond to incoming requests.
This could occur due to
·
Web server, Edge component, or Web server plug-in problem,
·
Application Server Crash, Hang,
·
Out of memory condition or 100% CPU utilization condition.
Determine the Root cause of the Problem:-
e. An application produces unexpected results (possibly errors or exceptions).
f. An application cannot connect to an external system or resource.
g. An application performs slowly or its performance degrades over time.
à Applying WebSphere maintenance:
Solution Terminology Changes
V5 terms V6 terms
Fix pack à Refresh pack
Cumulative Fix à Fix Pack
Fix packs for Version 6 are
delivered on a regular basis, about once every three months. They only contain
fixes for APARs (authorized program analysis report), and they do not introduce any new features or
functionality to the product. You can think of a fix pack as preventive
maintenance. Fix packs do not contain upgrades to the Java Software Development
Kit (SDK).
Refresh packs for Version 6
are considerably larger upgrades than fix packs. In addition to containing
fixes for APARs, all refresh packs contain some
new features and functionality. They also upgrade the Java
SDK. However, you should never install a refresh pack immediately on a
production system. All applications should be fully regression tested with the
new refresh pack. Upgrading to a new refresh pack level should be planned when
there is sufficient time in the development cycle to test it.
à Checking the Prerequisites:
Another strategy for
preventing problems is to ensure that all software and hardware in your
environment meets the prerequisites of WebSphere Application Server V6.
I.e. processor, Minimum
disk Space for installation, Physical memory (free Command in UNIX) 1 GB
recommended.
à Monitoring:
You can monitor for
configuration problems and runtime events within the administrative console. To
do this:
1. Log onto the administrative console.
2. Expand Troubleshooting.
3. Expand Configuration Problems or Runtime Messages.
You can view errors,
warnings, and informational messages directly in the administrative console.
You can select each message
that you see to get more details about the message, the source of the message,
and the reason why it occurred.
Another way to monitor your
application is by using the Tivoli Performance Viewer; you can observe performance
metrics, such as
·
Average response time,
·
Number of requests,
·
Thread pool sizes,
·
Connection pool sizes,
·
JVM memory, CPU, I/O,
·
And system paging,
to monitor the health of WebSphere Application Server and your applications.
à Many of the most severe problems, such as application server crashes,
hangs, and out of memory conditions, require the largest amount of diagnostic
data.
àConfigure the thread monitor for hang detection. WebSphere Application
Server V6 includes a thread monitor feature. By default, the thread monitor
checks the status of all active threads every three minutes. If it finds a thread that has been active for more than ten
minutes, it outputs a warning to the SystemOut log, similar to the
following:
WSVR0605W: Thread
threadname has been active for hangtime and may be hung.
There are totalthreads threads in total in the server that may be hung.
There are totalthreads threads in total in the server that may be hung.
The thread monitor makes it
easier to determine that a problem has occurred. If you see a WSVR0605W warning
in your SystemOut log, you out know that a thread has stopped responding. You
can then perform further diagnostic steps to determine the cause of the hung
thread.
No comments:
Post a Comment