Practical Limitations of Jvm Memory and CPU Usage

Practical limitations of JVM memory and CPU usage?

A single instance can try to acces all the memory, however NUMA regions mean that things such as GC perform badly accessing memory in another region. This is getting faster and JVM has some NUMA support but it needs to improve if you want scalability. Even so you can get 256 MB of heap and use 700 of native/direct memory without this issue. ;)

The biggest limitation if you have loads of memory is that arrays, collections and ByteBuffer (for memory mapped files) are all limited to a size of 2 billion. (2^31-1)

You can work around these problems with custom collections, but its really something Java should support IMHO.

BTW: You can buy a Dell R910 with 1 TB of memory and 24 cores/48 threads with Ubuntu for £40K.

BTW: I only have experience of JVMs up to 40 GB in size.

Process memory and CPU limitations on 64-bit Linux?

Yes, a JVM can take advantage of that much RAM and processors. In fact I have a machine with a nearly identical configuration as you describe except it's running RedHat. Keep in mind that your application would need to be multithreaded to use all the processor cores.

As for hardware limitations, there are always caching issues that can be pretty complicated, but a rule of thumb is that if all your threads are randomly accessing multiple areas of RAM, you're likely to get low cache coherency. If they're hitting roughly the same areas of RAM, it's likely you'll get better cache hits.

For specifics, it would be nice to know what sort of applications you're planning on writing.

Limit RAM usage Eclipse

Set the VM arguments for a specific run configuration they can be found at

Run → Run Configurations → Arguments Tab → VM arguments

you can do something like -Xms512

JVM consumes 100% CPU with a lot of GC

I learned to check this on GC problems:

• Give the JVM enough memory e.g. -Xmx2G
• If memory is not sufficient and no more RAM is available on the host, analyze the HEAP dump (e.g. by jvisualvm).
• Turn on Concurrent Marc and Sweep:
  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
• Check the garbage collection log: -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

My Solution:

But I solved that problem finally by tuning the cache sizes.
The cache sizes were to big, so memory got scarce.

---

Related Topics