A Q
asked on
Anyway to set more max ram to Tomcat 32bit?
Anyway to set more max ram to Tomcat 32bit?
Something wierd seems to be going on... I have an application on tomcat that used to be on a physical windows server 2008 standard 32-bit which I p2v'd with vmware converter over as a VM. I'm upgrading the server to windows server 2008 r2 64bit and instead of doing an inplace, I'm just building another one up and doing parallel side by side, and its a fresh VM from the start, no p2v stuff....
The strange part is I was able to set a max memory in the tomcat9w.exe configuration tool to about 1600 Megabytes and that was the hitting of the wall on that setup (the original physical one that I p2v'd to a VM), I can set less ram, but I cannot set it more than 1600 otherwise when I try to start the tomcat service in services.msc it will just crap outs.
So my thinking was since I have to stay on 32-bit of tomcat and 32-bit of Java JVM anyhow (long story...) that it might be better to put it in a 64-bit OS (server 2008r2) rather than the standard 32bit of server 2008. Long story short, from a fresh VM, on this box I'm only able to set a max total ram in tomcatw as around 1000 m (1GB) and if I set anymore it will not start, as in I cannot get tomcat service to start... so the wall is around 1GB...
As a test, I installed the tomcat (zip extract, not using msi or exe installer) to my own client workstation laptop running the latest windows 10 1809 etc and once again I hit the 1GB wall and cannot even get it to go up to 1.6GB, even though I have like 16GB ram on my laptop machine...
I have googled this for a long time and apparently it has to do with the way the operating system itself (in this case windows, be it windows server 2008 std, 2008 r2, or win10 etc) handles per process memory limitations and thread memory allocations that by default only allow around 1.5 to 2 g of ram per process and that this is what is constraining the tomcat apache jvm and not the programs itself....
But if this is indeed an OS difference, I checked on my original 32bit server2008 std, the one that I did P2V, and it didn't have anything special set in the boot.ini or any bcdedit parameters that allow it to see more ram per process nor anything like a /3GB flag etc etc
The only other thing I can think of is that maybe there is a difference between a VM and a physical raw bare metal box in how it allocates ram, and that I can get more contigous memory that tomcat/jvm requires when running on a 32bit OS on a physical box as opposed to and compared to a 64bit OS in a VM?
Why is it I can get the exact same version of Tomcat (bit by bit the same) to handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit or even server 2016 64bit I can only get tomcat to do up to around 1GB total max? They are both using the same Java version jvm etc etc etc
Something wierd seems to be going on... I have an application on tomcat that used to be on a physical windows server 2008 standard 32-bit which I p2v'd with vmware converter over as a VM. I'm upgrading the server to windows server 2008 r2 64bit and instead of doing an inplace, I'm just building another one up and doing parallel side by side, and its a fresh VM from the start, no p2v stuff....
The strange part is I was able to set a max memory in the tomcat9w.exe configuration tool to about 1600 Megabytes and that was the hitting of the wall on that setup (the original physical one that I p2v'd to a VM), I can set less ram, but I cannot set it more than 1600 otherwise when I try to start the tomcat service in services.msc it will just crap outs.
So my thinking was since I have to stay on 32-bit of tomcat and 32-bit of Java JVM anyhow (long story...) that it might be better to put it in a 64-bit OS (server 2008r2) rather than the standard 32bit of server 2008. Long story short, from a fresh VM, on this box I'm only able to set a max total ram in tomcatw as around 1000 m (1GB) and if I set anymore it will not start, as in I cannot get tomcat service to start... so the wall is around 1GB...
As a test, I installed the tomcat (zip extract, not using msi or exe installer) to my own client workstation laptop running the latest windows 10 1809 etc and once again I hit the 1GB wall and cannot even get it to go up to 1.6GB, even though I have like 16GB ram on my laptop machine...
I have googled this for a long time and apparently it has to do with the way the operating system itself (in this case windows, be it windows server 2008 std, 2008 r2, or win10 etc) handles per process memory limitations and thread memory allocations that by default only allow around 1.5 to 2 g of ram per process and that this is what is constraining the tomcat apache jvm and not the programs itself....
But if this is indeed an OS difference, I checked on my original 32bit server2008 std, the one that I did P2V, and it didn't have anything special set in the boot.ini or any bcdedit parameters that allow it to see more ram per process nor anything like a /3GB flag etc etc
The only other thing I can think of is that maybe there is a difference between a VM and a physical raw bare metal box in how it allocates ram, and that I can get more contigous memory that tomcat/jvm requires when running on a 32bit OS on a physical box as opposed to and compared to a 64bit OS in a VM?
Why is it I can get the exact same version of Tomcat (bit by bit the same) to handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit or even server 2016 64bit I can only get tomcat to do up to around 1GB total max? They are both using the same Java version jvm etc etc etc
As Dr. Klahn said, if you require > 2G memory, use 64 bit code.
Tip: Trying to run Tomcat in 2G... you'll quickly end up in a fetal position... whimpering... in some dark corner of a closet...
Best to start over again using 64 bit code.
Tip: Trying to run Tomcat in 2G... you'll quickly end up in a fetal position... whimpering... in some dark corner of a closet...
Best to start over again using 64 bit code.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
While I agree that the question seems abandoned, I don't see how Dr Kahn's answer should be regarded as THE answer. It doesn't address the asker's real question, which was why they were experiencing a difference in max heap allowed on the same os- and jvm-bit level.
Instead, my answer offered insight into how to better diagnose THAT problem, and while not an "answer", it would have helped the asker (and any reader with the same question) to help (or help us) get them TO the answer.
I do hope that you're voting to close the question is sent to the asker, in case they may get to reassess the answers and consider replying. I offered substantial, specific diagnostic steps that should help us get aq to a resolution of their problem.
Instead, my answer offered insight into how to better diagnose THAT problem, and while not an "answer", it would have helped the asker (and any reader with the same question) to help (or help us) get them TO the answer.
I do hope that you're voting to close the question is sent to the asker, in case they may get to reassess the answers and consider replying. I offered substantial, specific diagnostic steps that should help us get aq to a resolution of their problem.
I've marked Dr. Klahn's comment as the answer too, as this explains details of 32bit memory space usage for this work flow.
David and Seth, please note that AQ is NOT asking the classic "why can't I set tc to use more that 2g on 32-bit?". He's asking instead specifically why he CAN get 32-bit tc...
If anything, a variant of David's answer could be the better one to AQ: why bother running 32-bit tc on 64bit os?
But it seemed AQ was aware of that option and was instead trying to understand this observed difference with 32-bit tc when running ON 64-bit Windows.
In my reply, I confirmed first this specific aspect to AQ's question, then explained how I could NOT repeat it in my own identicsl test (to help AQ see there was not the inherent 1g limit he saw in running 32-bit tc on 64-bit Windows).
Finally I helped share how the tc logs could confirm he really WAS setting the heap to 1g as he proposed. It's easy, especially when running tc as a svc on windows and using the goofy tomcatXw.exe, to set the heap BOTH as an xmx arg and using the ui's memory text field, and one will override the other. So I was trying to help him really get to a possible explanation for what he was seeing--though I focused on his getting us logs to confirm rather than elaborate on the config ui.
I realize it may seem pedantic to press this point, and clarify the distinctions, but since AQ Is not responding I'm having to clarify for him. I spent all that time on my first answer because this is what I understood him to be asking the first time. Now having read it again today (and yesterday when Seth first wrote), I still feel I'm reading it right. :-) And that's why I wrote my first response, and now this one--just trying to help.
But at this point, and without any reply at all from AQ, I realize why you want to close it. I offered my answer to I help AQ get to the bottom of the real question, but again it was not an ANSWER, so if anything I'd suggest David's as the answer, and mine can stand here to perhaps help anyone else who may come along with AQ's same question. It's a pretty esoteric one, I agree. :-)
Thanks to you both, of course, for your work here on EE. We're ALL just trying to help.
to handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit or even server 2016 64bit [Windows] I can only get tomcat to do up to around 1GB total max?So Dr Kahn's explanation of how a 32-bit OS limits per process memory is NOT the answer to THIS question. And his idea of how one MIGHT be able to raise the addressable memory for 32-bit process on 64-bit is an interesting possible workaround, but again was not answering the question of why AQ was experiencing what they were.
If anything, a variant of David's answer could be the better one to AQ: why bother running 32-bit tc on 64bit os?
But it seemed AQ was aware of that option and was instead trying to understand this observed difference with 32-bit tc when running ON 64-bit Windows.
In my reply, I confirmed first this specific aspect to AQ's question, then explained how I could NOT repeat it in my own identicsl test (to help AQ see there was not the inherent 1g limit he saw in running 32-bit tc on 64-bit Windows).
Finally I helped share how the tc logs could confirm he really WAS setting the heap to 1g as he proposed. It's easy, especially when running tc as a svc on windows and using the goofy tomcatXw.exe, to set the heap BOTH as an xmx arg and using the ui's memory text field, and one will override the other. So I was trying to help him really get to a possible explanation for what he was seeing--though I focused on his getting us logs to confirm rather than elaborate on the config ui.
I realize it may seem pedantic to press this point, and clarify the distinctions, but since AQ Is not responding I'm having to clarify for him. I spent all that time on my first answer because this is what I understood him to be asking the first time. Now having read it again today (and yesterday when Seth first wrote), I still feel I'm reading it right. :-) And that's why I wrote my first response, and now this one--just trying to help.
But at this point, and without any reply at all from AQ, I realize why you want to close it. I offered my answer to I help AQ get to the bottom of the real question, but again it was not an ANSWER, so if anything I'd suggest David's as the answer, and mine can stand here to perhaps help anyone else who may come along with AQ's same question. It's a pretty esoteric one, I agree. :-)
Thanks to you both, of course, for your work here on EE. We're ALL just trying to help.
https://en.wikipedia.org/wiki/2_GB_limit
Now ... it is possible to forcibly set the "large address aware" flag for 32-bit executables under 64-bit systems and then run it with the /3GB flag, but there's no telling what will happen if the executable was not compiled for this environment.
https://www.coveros.com/increasing-the-amount-of-memory-available-to-a-32-bit-windows-application/