Best practice to monitor memorypool code cache of JVM

Solution Unverified - Updated -

Environment

  • OpenJDK

Issue

Please tell me the best practice to monitor memorypool code cache of JVM. We are using zabbix to monitor JBoss EPP, and often get following alert.
~
Trigger: java 70% memorypool code cache used on c19-78
Trigger status: PROBLEM
Trigger severity: High
Trigger URL:

Item values:

  1. java memorypool code cache used (c19-78:jmx[java.lang:type=MemoryPool,name=Code Cache][Usage.used]): 33.6 MB
  2. java memorypool code cache max (c19-78:jmx[java.lang:type=MemoryPool,name=Code Cache][Usage.max]): 48 MB
  3. UNKNOWN (UNKNOWN:UNKNOWN): UNKNOWN
    ~
    If this alert has serious meaning, please tell us how to fix. As I said, if the setting for this alert needs tuning, please tell me the best practice. By the way, This is the JVM option to run JBoss EPP.
    ~
    JAVA_OPTS="-Duser.dir=$JBOSS_HOME/server/$PROFILE/log -Djava.awt.headless=true -Djboss.shutdown.forceHalt=false -Dexo.prifiles=cluster -Djgroups.bind_addr=$JGROUPS_BIND_ADDRESS -Djboss.messaging.ServerPeerID=1 -Xms3072m -Xmx3072m -Xss1024k -XX:MaxPermSize=512m -verbosegc -Xloggc:$JBOSS_HOME/server/$PROFILE/log/date +%Y-%m-%d-%H:%M:%S_gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$JBOSS_HOME/server/$PROFILE/log/date +%Y-%m-%d-%H:%M:%S_heapdump.log -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+PrintClassHistogram -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true"
    ~

Resolution

JVM uses CodeCache to store method information after compile optimization.

The default CodeCache size is 240m.

Flushing is enabled by default and is triggered when CodeCacheMinimumFreeSpace is reached (500k default).

Monitoring should be aligned with flushing to avoid continuous alerts. Also, if the code cache does fill and entries are not flushed, the JVM will simply continue to operate without further compiling, continuing to interpret code as it has already been doing. So that is not likely to have a critical impact but it could be possible that it prevents the JVM from reaching a more optimal performing state with additional compiled code for more frequently used methods. You can increase the space with -XX:ReservedCodeCacheSize=#mbs if you wish to provide more space for compiled code.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments