tl;dr: don't panic
Just wanted to share this interesting post about JVM memory
http://blogs.amd.com/developer/2010/04/12/better-uptime-for-long-running-...
In jconsole in the memory tab, there is a drop down about the individual regions, and
there is
one entry for the code cache as well:
So the marked spots on the graph are when I invoked "plugins update" on the
agent command line. In all cases, the plugins
on the agent were up-to date. So this can't come from loading a new plugin that is
much "fatter" than the older one.
Looking at those figures, we indeed seem to have a tiny code cache leak in the agent.
Most of the times no one will see it, as the max code cache size is (here) 48M, while the
agent starts with 8MB and a plugins update
(even if all plugins are already up to date) adds ~1.5MB. So users that run the agent in
production will never do 20 plugin upadate
cycles as production agents are not constantly updated.
And developers usually don't have the agent running to long enough to ever run into
it
Interestingly the invocation of "Perform GC" had no influence here. What
happened though is that a longer time after
I took above graph, a gc collected some of the added memory in the code cache (but not
back to the original 8MB)
but the committed value did not go down. Overall it is mostly stable though (doing some
plugin redeploys with
changed code base right now):
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera