Along with being a software developer on our project, I have also become the unofficial tools administrator. We utilize many of the Atlassian tools, among them being JIRA. When JIRA was installed, it was put an a Windows Server 2008 R2 server, but was installed with the JIRA Standalone 32-bit installer. Due to the Windows memory addressing space when processes are running 32-bit, we could only allocate ~1GB of heap space to the JVM. Any more and the JVM would fail to start. Any less and the process would throw a java.lang.OutOf Memory error before it even started fully. Even at the magical 1GB heap size, we would only run stable for 0.5-1.0 day before we would blow the heap.
I contacted Atlassian support about getting our install running as a 64-bit process on a 64-bit JVM and their response was “Create a new database schema, install the 64-bit JIRA standalone pointing at that new schema and then migrate your data from the old schema to the new schema. No, not happening. I did some digging and figured out how to get the 32-bit install to run as a 64-bit process. Once I did this, the process started as a 64-bit Windows process and I was able to allocate more memory to the heap.
- Put a 64-bit JVM on the system, if it does not already have one.
- Change the Tomcat process properties to point to the 64-bit JVM.
- Rename tomcat.exe to tomcat.exe.x86
- Rename tomcat.exe.x64 to tomcat.exe
How has this been working out with you? We’re running into the same problem with a 32bit JVM and are being told to update to 64bit. Are there any detailed resources that you can link to?
We are still up and running just fine with this configuration. No issues to report.
I’d clear out the /work directory before restarting with the new JVM to be safe but otherwise I’d expect it to Just Work
“Change the Tomcat process properties to point to the 64-bit JVM.” By this, you mean the setenv.bat file?
I achieved this by adjusting the location in the dialog presented by invoking tomcat7w //ES//JIRA Service Name
Under the “Java” tab, there is a place to point the service to your JVM location. It needs to be adjusted to point to a 64-bit JVM.
Thanks, this saved me a lot of time :D It worked like a charm