available system memory

Here is what I use:

<cfset runtime = CreateObject("java", "java.lang.Runtime").getRuntime()>
<cfset freeMemory = runtime.freeMemory() / 1024 / 1024>
<cfset totalMemory = runtime.totalMemory() / 1024 / 1024>
<cfset maxMemory = runtime.maxMemory() / 1024 / 1024>

Max Memory Available to JVM: #Round(maxMemory)# MB<br>
Total Memory Allocated: #Round(totalMemory)# MB<br>
Free Allocated Memory: #Round(freeMemory)# MB

You could just copy and paste the JVM memory code from Dan G Switzer's site.

Can you expand on your issue overall? 

Java can return how much memory it is consuming, or for the server (on windows) you could use perfmon to log the memory usage.

If we know the end game we might be able to help further.

Byron Mann

mannb@hostmysite.com

byronosity@gmail.com

Software Architect

hosting.com | hostmysite.com

http://www.hostmysite.com/?utm_source=bb

A user-level process cannot reliably query "system memory," and even if it did, it's not going to get a true and useful accounting.  There are a several conceptual reasons why this is so:

• Many of the memory-segments will be shared segments.  In other words, a single copy of the information is being used simultaneously by many different processes.
• At any particular moment in time, the private memory segments might be "swapped-in" or "swapped-out," or somewhere in-between.  (If you are dealing with a so-called NUMA configuration, as a really big server might do, different CPUs might have their own picture of "what's in memory.")
• Operating systems are, by design, "lazy."  If there is no pressure on the virtual-memory subsystem, "it's not going to go out of its way to clean-up its dorm room."  It will leave those chunks of memory lying around exactly as they were left, until the day before the parents drop by for a visit.   That's done because there's actually a very good chance that "anything that was used recently" will very soon be needed again, even if there are no particular references to it at this very nanosecond.  This means that, in a system that's doing absolutely nothing, "memory" is probably completely "full."

There's also something to be said for "the Greyhound Principle," viz:  "Leave the driving to us."  Application programs are supposed to just be "along for the ride."  It's really none of their concern how busy or how crowded the system(s) as a whole might be.  Their only concern should be that they must fairly state to the system how many resources they individually need, and to make good and efficient use of the resources they have been given.  The application's design should be such that it is "a good neighbor," built with an awareness of how the operating system goes about its business but without being nosy or trying to second-guess what the system is doing.  (If you try too hard to do that, you can actually create a "negative feedback loop" effect which makes your app harder for the operating system to manage properly!)