Analyzing Java Application Problems
— This article discusses troubleshooting techniques for Java applications by analyzing Java thread dumps. We can use thread dumps to analyze situations like application hang, poor application response times, and application crash. Before getting into the details of analyzing the thread dumps, let's look briefly at the thread dump itself.
This one too is really arouses the readers interest -- By Ajay
A Sample Thread Dump
Thread Dump from a Deadlocked Application
Other Hang Scenarios
JVM Crash Scenarios
Sample Crash Dump
"NO END TO LEARNING, IT IS JUST THE BEGINNING"
Checklist/Tuning Guide for Optimizing the JRockit JVM by Steven Pozarycki -- In this article author Steven Pozarycki provides valuable information for tuning the BEA JRockit JVM using a checklist approach. He covers a lot of territory, from esoteric command-line options to iterative performance testing.
Use diagnostic commands to communicate with a running BEA JRockit process. These commands tell BEA JRockit to for example print a heap report or a garbage collection activity report, or to turn on or off a specific verbose module. This chapter describes how to run diagnostic commands and lists the available commands. The following sections are included:
REFER TO THIS LINK
----------------------------------------------------------------------------------------
MAKE USE OF THESE GREAT TOOLS AT THIS WEB PAGE AND YOU RULE
http://dev2dev.bea.com/utilitiestools/monitoring.html
----------------------------------------------------------------------------------------
| Note: | Execute Queues are deprecated in this release of WebLogic Server. BEA recommends migrating applications to use work managers. |
In previous versions of WebLogic Server, processing was performed in multiple execute queues. Different classes of work were executed in different queues, based on priority and ordering requirements, and to avoid deadlocks. See Using the WebLogic 8.1 Thread Pool Model.
The easiest way to conceptually visualize the difference between the execute queues of previous releases with work managers is to correlate execute queues (or rather, execute-queue managers) with work managers and decouple the one-to-one relationship between execute queues and thread-pools.
For releases prior to WebLogic Server 9.0, incoming requests are put into a default execute queue or a user-defined execute queue. Each execute queue has an associated execute queue manager that controls an exclusive, dedicated thread-pool with a fixed number of threads in it. Requests are added to the queue on a first-come-first-served basis. The execute-queue manager then picks the first request from the queue and an available thread from the associated thread-pool and dispatches the request to be executed by that thread.
For releases of WebLogic Server 9.0 and higher, there is a single priority-based execute queue in the server. Incoming requests are assigned an internal priority based on the configuration of work managers you create to manage the work performed by your applications. The server increases or decreases threads available for the execute queue depending on the demand from the various work-managers. The position of a request in the execute queue is determined by its internal priority:
Work managers provide you the ability to better control thread utilization (server performance) than execute-queues, primarily due to the many ways that you can specify scheduling guidelines for the priority-based thread pool. These scheduling guidelines can be set either as numeric values or as the capacity of a server-managed resource, like a JDBC connection pool.
****
MANY OF US DONT KNOW WHAT IS A MUXER????
DONT MISS THIS ARTICLE
WebLogic Server uses software modules called muxers to read incoming requests on the server and incoming responses on the client. These muxers are of two primary types: the Java muxer or native muxer.
A Java muxer has the following characteristics:
Native muxers use platform-specific native binaries to read data from sockets. The majority of all platforms provide some mechanism to poll a socket for data. For example, Unix systems use the poll system and the Windows architecture uses completion ports. Native provide superior scalability because they implement a non-blocking thread model. When a native muxer is used, the server creates a fixed number of threads dedicated to reading incoming requests. BEA recommends using the default setting of selected for the Enable Native IO parameter which allows the server automatically selects the appropriate muxer for the server to use.
If the Enable Native IO parameter is not selected, the server instance exclusively uses the Java muxer. This maybe acceptable if there are a small number of clients and the rate at which requests arrive at the server is fairly high. Under these conditions, the Java muxer performs as well as a native muxer and eliminate Java Native Interface (JNI) overhead. Unlike native muxers, the number of threads used to read requests is not fixed and is tunable for Java muxers by configuring the Percent Socket Readers parameter setting in the Administration Console. See Changing the Number of Available Socket Readers. Ideally, you should configure this parameter so the number of threads roughly equals the number of remote concurrently connected clients up to 50% of the total thread pool size. Each thread waits for a fixed amount of time for data to become available at a socket. If no data arrives, the thread moves to the next socket.
****
The type of garbage collector (GC) that the Virtual Machine is using.
JRockit provides the following types of GCs:
Generational Copying, which is suitable for testing applications on a desktop machine with a small (less then 128 MB) heap.
Single Spaced Concurrent, which reduces or eliminates pauses in the VM that are due to garbage collection. Because it trades memory throughput for reduced pause time, you generally need a larger heap size than with other GC types. If your ordinary Java threads create more garbage than this GC can collect, the VM will pause while the Java threads wait for the garbage collection to finish.
Generational Concurrent, which creates a "nursery" space within the heap. New objects are created within the nursery. When the nursery is full, JRockit "stops-the-world," removes the dead objects from the nursery, and moves live objects to a different space within the heap. Another thread runs in the background to remove dead objects from the non-nursery space. This GC type has a higher memory throughput than a single spaced concurrent GC.
Parallel, which allocates all objects to a single spaced heap. When the heap is full, all Java threads are stopped and every CPU is used to perform a complete garbage collection of the entire heap. This behavior causes longer pause times than for the concurrent collectors but maximizes memory throughput.
MBean Attribute:JRockitRuntimeMBean.GcAlgorithm
