JVM Heap Summary

Shows per-generation stats. The MidoNet Agent has very specific memory-usage constraints because it aims for a low memory and CPU footprint. At the same time, simulations generate a significant amount of short-lived garbage.

  • The Eden is configured as the largest generation trying to hold as much garbage as possible. However, it is likely that it fills up frequently under high traffic, which may imply that some short-lived objects get promoted to the old generation and garbage is collected soon afterward.
  • The Old Generation is expected to contain a baseline of long-lived objects that get reused during simulations. An amount of short-lived objects may also be pushed from the young generation, eventually also filling the old generation and triggering a GC event that will collect them. This will show as a see-saw pattern in the "Old used". The see-saw should converge to oscillating between stable maximum/minimum values on top of the long-lived objects baseline.

    • Large spikes indicate higher CPU consumption in GC and are usually associated with a certain throughput degradation. You may slightly alleviate this by increasing the size of the Eden.
  • JVM GC times: shows the duration of the last garbage collection performed by the JVM G1 collector. It is closely associated with the see-saw pattern described above.

    • Note that these times do not stop the application completely, because part of the work is done concurrently. The main impact is in CPU "stolen" from the agent.
Questions? Discuss on Mailing Lists or Chat.
Found an error? Report a bug.

loading table of contents...