Max addressable memory for 64bit JVM Process
Hi,
Im running ubuntu 10.04 64bit on an machine with 12gb physical memory (2x4, 2x2. I wanna upgrade to 32gb of memory because its cheap right now and i need it (don't ask why :p). My mainboard is the "Gigabyte GA-MA790FXT-UD5P" CPU is : AMD Phenom II x4 955BE before I buy the ram, i wanna be sure that my machine can actually handle the 32gig and that i can use it with a programm running on an 64bit jvm. I think the cpu and mainboard should be able to handle it. Are there any software limitations that i'm not aware of, should i check any system settings before i upgrade? thanks |
Quote:
You want to know how much physical ram your motherboard can use. But asking how much physical ram a 64bit jvm can use is pretty much meaningless. A process uses virtual memory. It does not directly use physical memory. The kernel uses physical memory as a resource in implementing the virtual memory. You might reasonably want to know how much virtual memory a 64bit jvm can use. I think that is controlled by parameters you can set, but I don't recall the details. An ordinary 64 bit process can use a nearly unlimited amount of virtual memory, but I think the jvm has limits designed into it. Before buying more ram, you could increase your swap space and then try whatever jvm based operation you think should use more ram and distinguish between four likely results. 1) The JVM refuses to allocate enough virtual memory and the operation fails. So you need to identify and adjust jvm parameters before more ram would be usable. 2) The large operation works correctly with acceptable performance using swap space. Even if much more than 12GB of virtual memory is used, the access pattern might be localized enough that paging overhead is insignificant and swap space is almost as good as ram. 3) The large operation works correctly using swap space, but is unacceptably slow, but you look at swap in stats and see that paging is a not a significant component of the slow down. Then you know you need to improve the algorithm of whatever big jvm based operation you are running before more ram would be useful. 4) The large operation works correctly using swap space, but is unacceptably slow, and you look at swap in stats to verify that paging is a significant component of the slow down. Then you know that more ram would actually be useful. As for how much ram a Gigabyte GA-MA790FXT-UD5P can support, I haven't a clue. I was burned years ago by a Gigabyte motherboard which was advertised with many misrepresentations of its actual capabilities, including overstating the amount of physical ram it supported. I haven't bought any Gigabyte products since then and so know nothing about the capabilities of their current products. |
Hi thanks for your detailed answer.
I know that the jvm works with -Xmx16g so i guess it should work with 32g too. I tried to increase my swap space before with a swap file, but that made everything even slower. Seems like a swap partition is faster then a file. But my swap partition is to small and i can't increase it. I haven't looked at swap stats yet but i guess that point 4 is the case because the algorithm is pretty simple and runs fine for about 30-40minutes until all physical memory is used and it starts swapping. |
Quote:
I think you ought to look at swap in statistics (and CPU time stats), so you can determine for sure that swapping is the problem rather than the algorithm doesn't scale well and gets slower when it needs more memory regardless of swapping. When it starts swapping do both user and system CPU time go down (indicating it is waiting for page swap in)? If user CPU time stays high, the problem is much more likely algorithm. If system CPU time goes up as user CPU time goes down, you may have a soft faulting issue that might or might not be improved by more physical ram. |
hey I did a testrun with -Xmx32g (I created a new swap partition with 32g by deleting an old unused vista partition on my pc)
thats the output of Code:
vmstat 20 Code:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- Code:
0 2 3389420 67684 228 32908 54 81 348 113 51 889 21 5 67 7 So i guess i can speed this up with more ram |
Quote:
Sorry I couldn't help you with the original question of how much your motherboard really support. |
All times are GMT -5. The time now is 08:29 PM. |