Garbage Collection, or in big applications I call it dumpster diving, is not new to the java world. But, without a basic understanding of it, garbage collections can leave you chasing problems with being able to put your finger on the cause. I am no way a programmer like the great minds just down the hall from me. But, I always knew that the world of the hardware tech would come in line with the coding world. I have never been one to look at the endless log files that can be generated by an error. And not being the one that writes this stuff, finding what makes a java engine die for no particular reason can make may day a bit more….. Challenging.
Over my short portal career I have had some interesting challenges. One that I know most of the admins come over with is my portal restarted or died for no reason. (Except this one line that says “out of memory error”) OOM errors tends to be the joy of trouble shooting but, for the most part it is a program that is attempting to access information that just is not there any more.
Huh, it was just there wasn’t it?
It sure was, and that brings me to Garbage Collections and this handy utility from Tagtaum called gcviewer. Once configured it will visually show you what is going on in your java engines.
Your max memory (total heap) is on the left side and time is across the top. In this case, this is a snapshot of one of my engines. The pink area is the tenured generations. The yellow area across the time is the young generation. The blue line is actually a tight graph. The blue indicated the amount of memory that is being consumed vs the max you have allocated. (The total of tenured and young generations) In this case, this is a 3 gig java engine.
As I zoom in you can better see the blue graph coinciding with the green below. Here you will be able to visually see the garbage collection process.
A garbage collection in java is the process of cleaning out objects that are no long being used in memory. A minor garbage collection happens every time the young generations become full. Objects that are still addressed are moved into the tenured generation. The blue line will go down and a saw tooth pattern is seen. The green represents the amount of time the processor had to spend doing a garbage collection. Now you can see how much heap is being used and how much time it is taking to scrub it.
Once the tenured memory is to the point that it is full, a major garbage collection happens.
So now a large amount of memory has been freed up and we can keep on going, or maybe not. My example here is of a 3 gig engine. That is a lot but, we need that because of a special application that we are using on the portal. Before, we had 1/3 of that, 1 gig and we had problems. OOM errors would hit and the engine would crash bringing down the portal. What could be going on to do this? Without this utility I would have never have found out. The java engine would crash every time a major garbage collection would happen. But, in a perfect world the major garbage collections are not supposed to take memory that still access objects! Guess what, it does. The collection is going to try NOT to take it in this situation but, if you do not have enough heap (RAM) to go around it is going to take something that is being used. And this is what makes the OOM error that crashes the engine and restarts the portal.
How that issue was solved might be in another blog.
Use the link above to go to Tagtraum.
In your configtool java parameters settings, add –verbose:gc and -Xloggc:
The .gc file will appear in the server0 folder (or serverX folder) when you restart the engine. In the folder that you installed the files you will see cgviewer.jar. Right click and open it with javaw.