Originally Posted by michelangelo
how can i increase contiguous mem size? (if this is the problem...)
The issue is contiguous virtual address space within the process started by that java command.
Having less than 2GB contiguous at startup seems a little strange, but it isn't implausible.
When you start java successfully with java -Xmx1950m do you do something to make that process stay around (preferably waiting for input or other event)? If so, you can find out its pid and the look in /proc/
to see the detailed layout of virtual memory. After the big chunk allocated for the heap there must be some other mappings (probably .so files) that fragment the virtual address space preventing a larger contiguous mapping. There are methods (I don't recall them, but they exist) to control the load address of all the .so files and maybe whatever else gets in before that contiguous mapping is attempted. You should be able to get everything that now loads near the middle of the 3 or 3.6 GB virtual space to load near the beginning or near the end.
Originally Posted by syg00
If all that is true, try doing the last command immediately after a re-boot to get an indication if it is a contiguous problem.
Since it is the virtual address space of a new process created by the java command, not anything that needs to be physically contiguous, trying it right after a reboot should make no difference.
I'm not 100% sure about the rules for virtual load address of .so files. If a .so file is already loaded by something at some address convenient to the first process that loaded it, there would be some performance advantage to loading it at the same virtual address in another process that subsequently needs it, assuming that virtual address is available. I don't know whether Linux does that kind of optimization. If it does then use of some .so before the java command might influence the virtual layout and maybe your reboot idea could have some useful effect. But I'm not sure that is possible and if it is possible it is still a difficult indirect blind approach to an issue that can be viewed directly by looking in the process maps and then attacked directly.