Nope, it would not. Again, the problem started only with FR 9.2.0.
So as for your issue, I'll say again that your graph does not look worrisome to me, but I realize it does do you. So let's do this: rather than judge just from "how high" the FR heap graph goes (or how high your OS memory for the CF process reportt to be), please go to the Metrics>Web Metrics page in FR, and click the "garbage collection" button below the bottom right CPU graph.
This requests a "major GC" (whereas the frequent drops you see are usually about "minor GCs".) A GC tells the JVM to release any objects that are in that "used" amount but aren't really any longer in use. (We as developers don't tell Java--or CF--to allocate or deallocate memory. That's handled "for us".)
The point is: does that dark orange ("heap used") value drop dramatically? Your graph shows your heap max to be about 4g (the lightest orange). If the dark orange/heap used falls to 1g (half of what was your highpoint of 2g, which is 1/4 that max size), then really I'd not worry about any of this if I was you. You'd have 3g of headroom.
If you feel the highest values of the dark orange were about 1g before and you wish it "stayed there", well that's not how the JVM works. If you set the heap max to 4g, it could get lazy and let memory rise to nearly that max before it would (on its own, then or earlier) do a GC. We don't need to baby-sit the heap--and we DEFINITELY do not to "click the GC button all the time". It's there just for this diagnostic purpose above.
And if your focus is indeed more on the OS (Task Manager on Windows) reporting that the coldfusion process is "using a lot more memory", note that's caused (mostly) by the "allocated memory" (which is the middle orange color). That will rise as heap use rises--and it will fall over time when heap use falls. It will NOT fall just because you do a GC. It could take minutes or longer before the JVM "lets go" of memory that had been marked as "used".
Finally, if you still just have angst about "why is memory use higher" (even if not high enough to really worry), there can be any number of things to cause it. For instance, perhaps some automated requests are being made against your site/app, and such automated requests would each create a new CF session (because they present no cookie, to connect to an existing session). And that would trigger your onsessionstart code in application.cfc (or the equivalent in application.cfm). Perhaps you load up session scope vars, whether with CFC instantiations or queries you want to "cache" for that session, etc.
Note that FusionReactor keeps track of your session count over time (even graphing it) on its
"UEM & Sessions>Sessions" page on the left. See if that may be rising "high" in recent days. If you have not restarted CF in a week, the graph can go back that far so that you can compare over time.
/Charlie (troubleshooter, carehart.org)
7
Replies
AdChoices
