# Improving Tomcat memory parameters

**URL:** <https://community.dhis2.org/t/improving-tomcat-memory-parameters/1434>\
**Category:** Support - Assistance technique\
**Created:** [15 April 2013 07:39 UTC](https://community.dhis2.org/t/improving-tomcat-memory-parameters/1434 "2013-04-15T07:39:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Knut\_Staring](https://dhis2.b-cdn.net/user_avatar/community.dhis2.org/knut_staring/32/32549_2.png) [@Knut\_Staring](https://community.dhis2.org/u/Knut_Staring)\
**Post date:** [15 April 2013 07:39 UTC](https://community.dhis2.org/t/improving-tomcat-memory-parameters/1434/1 "2013-04-15T07:39:32Z")

</div>

This discussion can be of interest to DHIS2 administrators as well.

> **···**
>
> Jeremy Keiper
> 
> ```
> OpenMRS Core Developer
> 
> AMPATH / IU-Kenya Support
> 
> On Fri, Apr 12, 2013 at 10:10 AM, Mark Goodrich <mgoodrich@pih.org>
> wrote:
> 
> ```
> 
> > Saptarshi,
> > 
> > ```
> > Thanks so much! This is very helpful...
> > 
> > +1 to Rowan's suggestion of updating the wiki... if you don't have time, let me know, and I can at least paste in what you've written here.
> > 
> > This is a good page as well:
> > 
> > [https://wiki.openmrs.org/display/docs/Performance+Tuning](https://wiki.openmrs.org/display/docs/Performance+Tuning)
> > 
> > Do you have any experience with these parameters?
> > 
> > ```
> > 
> > ```auto
> > -XX:+
> > CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
> > 
> > ```
> > 
> > ```
> > It looks like we are experiences a classloading leak due to the user of Groovy in the UI framework... I checked yesterday and there were 4,000+ dead classloaders on our production most of which were Groovy classloaders. Darius put a tweak into the UI Framework last night, but I don't think it has resolved it.
> > 
> > Mark
> > 
> > On 04/12/2013 04:09 AM, Rowan Seymour wrote:
> > 
> > ```
> 
> > > ```
> > > @Saptarshi maybe you could update [https://wiki.openmrs.org/display/docs/Troubleshooting+Memory+Errors](https://wiki.openmrs.org/display/docs/Troubleshooting+Memory+Errors)
> > > 
> > > ```
> 
> > > ```
> > > I think every implementation runs into these kind of problems eventually and just googling for answers gives all sorts of conflicting advice.
> > > 
> > > ```
> 
> > > –
> > > 
> > > ```
> > > OpenMRS Implementers: [http://go.openmrs.org/implementers](http://go.openmrs.org/implementers)
> > > 
> > > Post: implementers@openmrs.org
> > > 
> > > Unsubscribe: implementers+unsubscribe@openmrs.org
> > > 
> > > Manage your OpenMRS subscriptions at [https://id.openmrs.org/](https://id.openmrs.org/)
> > > 
> > > ```
> 
> > –
> > 
> > ```
> > OpenMRS Implementers: [http://go.openmrs.org/implementers](http://go.openmrs.org/implementers)
> > 
> > Post: implementers@openmrs.org
> > 
> > Unsubscribe: implementers+unsubscribe@openmrs.org
> > 
> > Manage your OpenMRS subscriptions at [https://id.openmrs.org/](https://id.openmrs.org/)
> > 
> > ```
> 
> ```
> On 12 April 2013 00:21, Saptarshi Purkayastha <sunbiz@gmail.com>
> wrote:
> 
> ```
> 
> > ```
> > To add to what I wrote earlier, so that this is not considered Voodoo knowledge, lemme quote references:
> > 
> > [http://www.oracle.com/technetwork/java/javase/6u18-142093.html](http://www.oracle.com/technetwork/java/javase/6u18-142093.html)
> > 
> > * Server JVM heap configuration ergonomics are now the same as the Client, except that the default maximum heap size for 32-bit JVMs is 1 gigabyte, corresponding to a physical memory size of 4 gigabytes, and for 64-bit JVMs is 32 gigabytes, corresponding to a physical memory size of 128 gigabytes*.
> > 
> > So, by a calculation that the default JVM memory allocations have some science behind it, they allocate 1/4 total physical memory size. On your 32GB server, lets consider MySQL has been given 16GB, so 1/4th of the remaining I'd recommend 4G for heap.
> > 
> > Also one should move to JDK7 for the G1 garbage collector's efficiency (once we figure out why those 2 tests randomly end in errors, but not fail)
> > 
> > [http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html](http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html)
> > 
> > ```
> > 
> > * * *
> > 
> > ```
> > Regards,
> > 
> > Saptarshi PURKAYASTHA
> > 
> > My Tech Blog: [http://sunnytalkstech.blogspot.com](http://sunnytalkstech.blogspot.com)
> > 
> > You Live by CHOICE, Not by CHANCE
> > 
> > ```
> 
> > 
> 
> > ```
> > On 11 April 2013 23:59, Saptarshi Purkayastha <sunbiz@gmail.com>
> > wrote:
> > 
> > ```
> > 
> > > ```
> > > Firstly expecting that this is a 64-bit OS with 64-bit JVM,
> > > 
> > > I'd have PermSize and MaxPermSize different, probably double for a server with 32GB RAM
> > > 
> > > -XX:PermSize=256 m -XX:MaxPermSize=512m
> > > 
> > > If Java activities and MySQL and equally prioritized on the server. I'd still give 4Gb max heap size for Java.
> > > 
> > > -Xmx4 G -Xms1024m
> > > 
> > > If you have enough RAM for everything else running on the server and its not paging, 4Gb heap size shouldn't be a problem.
> > > 
> > > Heap thrashing is a misnomer coming from early IBM implementations. Sun/Oracle JVM is really well managed
> > > 
> > > You are also probably using sun java6 (hotspot jvm), I'd enable the CMS (Concurrent Mark & Sweep Garbage collector)
> > > 
> > > -XX:+UseConcMarkSweepGC
> > > 
> > > ```
> > > 
> > > * * *
> > > 
> > > ```
> > > Regards,
> > > 
> > > Saptarshi PURKAYASTHA
> > > 
> > > My Tech Blog: [http://sunnytalkstech.blogspot.com](http://sunnytalkstech.blogspot.com)
> > > 
> > > You Live by CHOICE, Not by CHANCE
> > > 
> > > ```
> 
> > > ```
> > > On 11 April 2013 23:33, Ellen Ball <ellnball@gmail.com>
> > > wrote:
> > > 
> > > ```
> > > 
> > > > ```
> > > > We've experienced the pain of tomcat crashing on an OpenMRS 1.9.3 production server with this memory error: "Java.lang.OutOfMemoryError: PermGen"
> > > > 
> > > > ```
> > > > 
> > > > - 
> > > > 
> > > > ```
> > > > The server has 32GB of RAM.  
> > > > 
> > > > ```
> > > > 
> > > > - 
> > > > 
> > > > ```
> > > > tomcat is using JAVA_OPTS = "-Xmx512m -Xms512m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:NewSize=128m"
> > > > Has anyone else seen this error? Has anyone experimented with increased memory parameter values? It seems that the Xmx and Xms values should be the same for a server (" In a server environment, you normally want Xms and Xmx set to the same value to avoid heap thrashing.
> > > > "). The heap space shouldn't be too high, but if anyone know the optimal size that would be helpful.
> > > > 
> > > > ```
> 
> > > >
> 
> > > > Thanks,
> 
> > > >
> 
> > > > ```
> > > > Ellen Ball
> > > > 
> > > > ```
> 
> > > >
> 
> > > >
> 
> > > > ```
> > > > Partners In Health
> > > > 
> > > > ```
> 
> > > > ```
> > > > --
> > > > 
> > > > OpenMRS Implementers: [http://go.openmrs.org/implementers](http://go.openmrs.org/implementers)
> > > > 
> > > > Post: implementers@openmrs.org
> > > > 
> > > > Unsubscribe: implementers+unsubscribe@openmrs.org
> > > > 
> > > > Manage your OpenMRS subscriptions at [https://id.openmrs.org/](https://id.openmrs.org/)
> > > > 
> > > > ```
> 
> > >
> 
> > ```
> > --
> > 
> > OpenMRS Implementers: [http://go.openmrs.org/implementers](http://go.openmrs.org/implementers)
> > 
> > Post: implementers@openmrs.org
> > 
> > Unsubscribe: implementers+unsubscribe@openmrs.org
> > 
> > Manage your OpenMRS subscriptions at [https://id.openmrs.org/](https://id.openmrs.org/)
> > 
> > ```
> 
> –
> 
> ```
> **Rowan Seymour**
> 
> tel: +250 783835665
> 
> ```