|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Java EE (Java Platform, Enterprise Edition) applications, regardless of the application server they are deployed to, tend to experience the same sets of problems. As a Java EE tuner, I have been exposed to a variety of environments and have made some observations about common problems. In this capacity, I see my role as similar to that of an automobile mechanic: you tell your mechanic that the engine is chirping; then he asks you a series of questions that guide you in quantifying the nature, location, and circumstances of the chirp. From this information, he forms a good idea about a handful of possible causes of the problem.
In much the same way, I spend the first day of a tuning engagement interviewing my clients. During this interview, I look for known problems as well as architectural decisions that may negatively affect the performance of the application. With an understanding of the application architecture and the symptoms of the problem, I greatly increase my chances of resolving the problem. In this chapter, I share some of the common problems that I have encountered in the field and their symptoms. Hopefully, this article can serve as a troubleshooting manual for your Java EE environment.
One of the most common problems that plagues enterprise applications is the dreaded OutOfMemoryError. The error is typically followed by one of the following:
Regardless of the symptoms, you will most likely need to reboot the application server before performance returns to normal.
Before you attempt to resolve an out-of-memory error, first understanding how it can occur is beneficial. If the JVM runs
out of memory anywhere in its process memory space, including all regions in the heap as well as the permanent memory space,
and a process attempts to create a new object instance, the garbage collector executes to try to free enough memory to allow
the new object's creation. If the garbage collector cannot free enough memory to hold the new object, then it throws an OutOfMemoryError.
Out-of-memory errors most commonly result from Java memory leaks. Recall from previous discussions that a Java memory leak
is the result of maintaining a lingering reference to an unused object: you are finished using an object, but because one
or more other objects still reference that object, the garbage collector cannot reclaim its memory. The memory occupied by
that object is thus lost from the usable heap. These types of memory leaks typically occur during Web requests, and while
one or two leaked objects may not crash your application server, 10,000 or 20,000 requests might. Furthermore, most objects
that are leaked are not simple objects such as Integers or Doubles, but rather represent subgraphs within the heap. For example, you may inadvertently hold on to a Person object, and that Person object has a Profile object that has several PerformanceReview objects that each maintain sets of data. Rather than losing 100 bytes of memory that the Person object occupies, you lose the entire subgraph that might account for 500 KB or more of memory.
Archived Discussions (Read only)