Hot questions for Using GlassFish in jvm
I have deployed a web app on a glassfish server, which just consists of a bunch of JAX-RS REST services and database handling through JPA. The WAR file I used for deployment is about 2MB, and it has very little traffic (just a couple of requests for testing). Out of curiosity, I ran a jmap to have a look at the memory usage and I got this
using thread-local object allocation. Parallel GC with 2 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 21757952 (20.75MB) MaxPermSize = 201326592 (192.0MB) G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 99090432 (94.5MB) used = 36256552 (34.576942443847656MB) free = 62833880 (59.923057556152344MB) 36.589357083436674% used From Space: capacity = 38797312 (37.0MB) used = 13067872 (12.462493896484375MB) free = 25729440 (24.537506103515625MB) 33.68241593644426% used To Space: capacity = 37748736 (36.0MB) used = 0 (0.0MB) free = 37748736 (36.0MB) 0.0% used PS Old Generation capacity = 70254592 (67.0MB) used = 59577728 (56.8177490234375MB) free = 10676864 (10.1822509765625MB) 84.80261048274254% used PS Perm Generation capacity = 135266304 (129.0MB) used = 88929544 (84.80982208251953MB) free = 46336760 (44.19017791748047MB) 65.74404812598414% used
I was quite surprised to see that Perm Gen takes about 84MB of memory for such a small app. This number went down when I restarted the server (it was like 100MB before, which already looks strange since I read that perm gen is never garbage collected, so how can it go down?). My doubt is: is it normal to get such a high number with such a small app? I actually deployed and redeployed the app quite a lot of times during the past weeks, so could it be due to that? The app works perfectly so I have no particular issues to solve, I just wondered if this could cause problems in the future. Even the number for Eden space looks big to me, 34MB used for an app that has one user for the moment, with an empty database, which is basically doing nothing relevant!
EDIT: I now undeployed the app and restarted the server (which now runs under a differend pid). Surprisingly to me, I ran another jmap and I got very similar numbers for perm gen (like 70MB used). Is it possible that this is just related to glassfish and it has nothing to do with my app?
One problem with Perm Gen is static things. The statics are allocated from Perm Gen, but are not released until the container (Glassfish, Tomcat, ...) is restarted.
If the static points to a another class (even if the class is not static), then the other class will never be released either. If the application is restarted without restarting the container, then the memory for that class will not be released and another instance of the class will be allocated for the new instance of the application.
Many classes have static pointers to other classes. You can try to eliminate the problem in your code, but many Java classes have this issue, so it may be beyond your control.
Here is an excellent post on the subject: Classloader Leaks.
Response to Glassfish comment:
Yes, it could be due to Glassfish. Each class is allocated to the Perm Gen, so lots of classes implies lots of Perm Gen. Even though your class is small, it stands on the shoulders of giants.
I'm trying to add the keystore and truststore passwords in the domain.xml for glassfish 18.104.22.168 as jvm options.
Using aliases seems to not be working.
Any ideas how this can achieved ?
For future readers who reach this question, hoping to do this for Glassfish 3.1.2.x, this is not possible due to the bug GLASSFISH-18961 :
The bug has been fixed. The fix referenced in the above ticket is here : https://java.net/projects/glassfish/sources/svn/revision/55379, but it has not been backported to Glassfish 3.x
Also, according to this questions "does glassfish support password aliases in jvm args?", this works fine in Glassfish 4.
GC overhead limit exceeded will come, if your application is spending too much of time on GC.
This error means that the GC tried to free memory but was pretty much unable to get anything done. By default it happens when the JVM spends more than 98% of the total time in GC and when after GC less than 2% of the heap is recovered.
You neeed to examine your application and close the resources so that they can be freed by GC