I been setting up standalone Jira with Crowd, Confludnce and Fisheye. Everything works fine, my only problem is that the server has 2gb of memory. (which can be upgraded, no problem there) Since our usage should not be very big (we only have about 15 users and low issue creation rate), I reduced the memory usage of everything via specifying it in Java VM parameters. It looks like this:
Crowd - -Xms32m -Xmx64m -XX:MaxPermSize=128m
Jira - -Xms128m -Xmx256m -XX:MaxPermSize=128m
Confluence - -Xms128m -Xmx256m -XX:MaxPermSize=128m
Fisheye/Crucible - -Xms128m -Xmx256m -XX:MaxPermSize=128m -XX:MaxNewSize=128m
So according to my calculation I should have about 700 memory free, system on idle with apache, mysql and the linux OS running only using 150mb. There's a 550mb overhead for Java VM in total over 4 apps? I sometimes just don't understand where, how and why Java VM uses memory.
So then, I just run Jira and Confluence (plus Crowd) and I get the same results... only now I'm running one less application.
Looking at memory bevavior:
Idle - 150mb
Run Crowd - 500mb
Run Jira - 1.4gb (???????)
Run Fisheye - 2gb
Run Confluence - 2gb (what?) (30mb swap)
Even just looking at Crowd, it should only have 200mb allocated to it total, yet somehow it manages to use 160mb more.
Anyone can share some light on this?
Thanks in advance.
By modifying the memory options for Java, you only modify the amount of memory available to the Java code running inside JVM.
On top of that, additional memory will be consumed for loading native code, shared libraries, etc. This amount is quite significant. If you look at top output, RES column should roughly correspond to you altered settings, but SHR column will show much more memory necesary to run the process. So, the process itself will need more memory (some of it will be shared with other processes running on that host). You really should upgrade RAM on that machine if you plan on running all these tools. I don't recommend lowering the amount of memory allocated to them - even if you don't run into OOMs, you can lower their performance.
Memory is not a problem, as mentioned before, running it on a cloud. I was simply asked if it all can be squeezed into 2gb, which I assumed from the begining probably woulnd't be very feasible. When I lowered Java VM memory, it just left me scratching my head, wondering what exactly eats the memory.
Could you give any recomendations as to how much memory this setup should require? Once again we probably won't have a massive amount of users or issues. Thanks.
My recommendation would be to use the default memory settings. If you can't, reduce the amount of necessary memory proportionally for all tools, which is more or less what you did here.
If you are running on EC2, your next instance size will have 8GB anyway.
The -XX:MaxPermSize= and -Xmx (Maximum Java Heap size) parameters respectively configure the maximum size of the permanent region, where the class code and related data are logically presented as part of the old generation region but are kept physically separate, and the maximum size of the main heap where Java objects and their data are stored either in the young or old generation regions. Together the permanent region and the main heap comprise the total Java heap. An allocation failure in either of these regions either represents the inability to accommodate either all the application code or all the application data, both of which are terminal conditions, that can exhaust available storage, and cause an OutOfMemory error.
So, PermSz and HeapSz added are total heap. Your crowd takes: 64+128 Mb in total heap. The rest is java managed memory (i.e. available to the java process only)
To minimize it, you should decrease the number of threads, tune I/O buffers (where you can) etc
Since launching the Jira Software 8.0 and Jira Service Desk 4.0 platform releases in February, many of you have been asking when the next Enterprise release will be so you can take advantage of the m...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs