java Xmx limitation on 32bit with PAE enabled
PAE enabled: cpu flags : fpu vme de pse tsc msr pae
no limit on user: virtual memory (kbytes, -v) unlimited
15Gb RAM (physical)
Mem: 14967976 (from free command).
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4194303
max total shared memory (kbytes) = 13500000
min seg size (bytes) = 1
1)the c program: malloc about 3.6Gb RAM. GREAT!
2)java -Xmx1950m is OK; WHILE from
3)java -Xmx1960m says
*** panic: JVMST062: Cannot allocate memory in initializeFRBits()
how can i increase contiguous mem size? (if this is the problem...)
Do you really not have the lm flag or do you have some other reason to not switch to a 64 bit build of Linux?
That means you have the build of Linux that I think is called "Hugemem" by old versions of RHEL that included it, that has kernel virtual memory separate from user virtual memory. That has a lot of overhead compared to a 64 bit build. That is a bad idea if you have a choice.
I don't know Java memory issues, so maybe there is a fix for that problem and still fit in 32 bit virtual memory. But if you want to go far beyond that, you may need 64 bit.
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.
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/pid/maps 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.
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.
|All times are GMT -5. The time now is 08:55 PM.|