Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

An Introduction to WebSphere Application Server Performance Tuning Toolkit

Part2: Analyzing Problem Scenarios

Shishir Narain (, IT Architect, IBM
Shishir Narain photo
Shishir Narain is Open Group certified Master IT Specialist with mature skills in IBM middleware products. He works in IBM Lab Services for WebSphere at India Software Labs, Gurgaon. He has 12 years of experience developing solutions for multiple clients. He has a Master of Technology degree from Indian Institute of Technology, Kanpur.
(An IBM developerWorks Contributing Author)
Tao Zhang (, Software Engineer, IBM
author photo
Zhang Tao (Jordan) joined IBM in 2009. He works in IBM China Software Development Lab WebSphere Application Server SVT team in Beijing. He is interested in WebSphere Migration, Intelligent Management, and high availability.
Wang Yu (, Software Engineer, IBM
author photo
Wang Yu (Edward) is a software engineer at the IBM China Software Development Lab in Beijing. He is a member of WebSphere Application Server SVT team. He is also interested in WebSphere Application Server performance analysis, performance tuning, problem diagnosis, and high availability.

Summary:  WebSphere® Application Server is a key component of enterprise architecture, and performance bottlenecks can affect multiple applications. This tutorial series introduces WebSphere Application Server Performance Tuning Toolkit, which can be used for uncovering performance bottlenecks and tuning the WebSphere Application Server infrastructure. This part presents several more problem scenarios and shows how PTT can help in detecting and resolving the issues.

Date:  24 Oct 2012
Level:  Intermediate PDF:  A4 and Letter (1646 KB | 21 pages)Get Adobe® Reader®

Activity:  9957 views

High CPU usage problems

In this scenario, a thread is consuming a large amount of CPU time.

Triggering the problem

Listing 2 shows the required code changes in the TradeAppServlet to trigger high CPU usage.

Listing 2: Code for triggering high CPU usage

//For High CPU Usage
    			try {
    	        	CPUConsumer cc = new CPUConsumer();
    	        } catch (Exception e) {
    class CPUConsumer extends Thread{
        public void run() {
          }catch(Exception e){

In the Server tab of the Daytrader application (see Figure 6), select the High CPU Usage checkbox and click Update Configuration. A loop thread is started to consume the CPU resources. If you find that the CPU usage is not high enough to trigger the HighCPU health policy, increase the thread number appropriately.

Figure 6: DayTrader configuration screen
DayTrader                         configuration screen

Monitoring and investigating the problem

When a high CPU usage problem occurs, you can see CPU alerts in the dashboard. See Figure 7.

Figure 7: PTT dashboard with alerts
dashboard                         showing alerts

Double click the Server panel to switch to the monitoring page; you can see that the CPU usage is very high (Figure 8).

Figure 8: CPU usage monitor
graph of                         CPU usage

To investigate the problem further, you need to determine which threads are taking up the CPU's cycles. Getting thread details is operating system dependent. In a Windows environment, you can use the Process Explorer (see the Resources section) to locate the threads that are consuming the CPU. Select the WebSphere Application Server process ID in Process Explorer, switch to Properties view, and then choose the thread tab. As you can see in Figure 9, Process Explorer lists all threads along with their respective CPU percentages. The two high CPU threads you started can be seen in Process Explorer.

Figure 9: Identifying high CPU threads using Process Explorer
Process                         Explorer screen

Note the thread IDs and convert them to hexadecimal (the thread dump uses hexadecimal). Search for these hexadecimal thread IDs (0x9D4 and 0xEB4 in this example) in the thread dump.

The details in the thread dump corresponding to this thread ID clearly show that the problem is due to the method in TradeAppServlet..

3XMTHREADINFO "Thread-40" J9VMThread:0x1C3E4D00,
                        j9thread_t:0x17E572B0, java/lang/Thread:0x069B5D70, state:CW,
3XMTHREADINFO1 (native thread ID:0x9D4, native priority:0x5, native
3XMTHREADINFO3 Java callstack:
3XMTHREADINFO3 Native callstack:
4XENATIVESTACK KiFastSystemCallRet+0x0 (0x7C90E514
4XENATIVESTACK WaitForSingleObject+0x12 (0x7C802542
4XENATIVESTACK monitor_wait_original+0x239 (j9thread.c:3727,
                        0x7FFA3829 [J9THR24+0x3829])
4XENATIVESTACK monitor_wait+0x31 (j9thread.c:3573, 0x7FFA42F1
4XENATIVESTACK j9thread_monitor_wait+0x14 (j9thread.c:3443,
                        0x7FFA4484 [J9THR24+0x4484])
4XENATIVESTACK internalAcquireVMAccessNoMutexWithMask+0x1a
                        (vmaccess.c:238, 0x7FF2879A [j9vm24+0x3879a])
4XENATIVESTACK internalAcquireVMAccessNoMutex+0xf (vmaccess.c:253,
                        0x7FF287DF [j9vm24+0x387df])
4XENATIVESTACK javaCheckAsyncMessages+0x7a (async.asm:135,
                        0x7FEF1BAA [j9vm24+0x1baa])
4XENATIVESTACK javaCheckAsyncEvents+0x68 (javamisc.asm:426,
                        0x7FEFF558 [j9vm24+0xf558])
4XENATIVESTACK javaProtectedThreadProc+0x7d (vmthread.c:1653,
                        0x7FF2C5CD [j9vm24+0x3c5cd])
4XENATIVESTACK j9sig_protect+0x41 (j9signal.c:144, 0x7FECBFA1
4XENATIVESTACK javaThreadProc+0x35 (vmthread.c:260, 0x7FF2CDF5
4XENATIVESTACK thread_wrapper+0xbf (j9thread.c:947, 0x7FFA3F2F
4XENATIVESTACK _endthread+0xaa (0x7C34940F [msvcr71+0x940f])
4XENATIVESTACK GetModuleFileNameA+0x1ba (0x7C80B729

This information shows that the method is causing high CPU usage.

The script to determine the CPU consuming threads for Linux is provided in the download archive. Scripts for other UNIX environments can be written on similar lines.

3 of 8 | Previous | Next


TutorialTitle=An Introduction to WebSphere Application Server Performance Tuning Toolkit