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?-XX:+ CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabledIt 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