-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jvm metrics for mendix 8/java 11 are not retrieved correctly. #52
Comments
This should be part of #51 |
igor-mendix
added a commit
to igor-mendix/m2ee-tools
that referenced
this issue
May 8, 2020
Issue mendix#52 For Java 11, use memory pool names as returned by runtime to extract values instead of relying on their specific order. m2ee used to take Compressed Class Space as permanent type. However, according to http://performantcode.com/jvm/permgen-and-metaspace/, permanent (PermGen) was renamed to metaspace. And according to https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html, which says "The MaxMetaspaceSize applies to the sum of the committed compressed class space and the space for the other class metadata.", compressed class space seems to be part of metaspace. Thus, there is a significant difference in what is considered 'permanent' in this new code. This could also be applicable for older Java versions but for now let's keep old behavior as it is not sufficiently tested. It would, however, be great to clean this up a bit, so we can consider this a TODO.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In munin.py:get_stats_from_runtime the Java JVM memory values are retrieved from the runtime statistics. The response on Mendix 8 (with Java 11) is this:
The methods make a decision based on the existence of memory.memorypools which exists and then retrieves values from the response. But, comparing the variable names with the assignment we see a mismatch.
This results in internal ticket DEP-2484.
The text was updated successfully, but these errors were encountered: