Also, we think there’s a possible memory leak in the app because the RAM usage keeps growing and we have to restart the app every 5-6 days to reclaim the RAM.
I’m not sure what you mean when you say that you restarted the “app” - are you referring to restarting the DATABASE INSTANCE (aka restarting tomcat), or are you referring to one specific app within the system?
Either way I agree that there seems to be some erratic behaviour (memory leak or whatever). I reported the same with regard to the Tracker Capture app some time back (see JIRA DHIS2-6201), and I’ve recently confirmed this slow-down multiple times: As you edit more than 5-10 TEIs, the app responds slower and slower until it crashes (snap error, which seems to clear out the browser cache) or you use the Browser cache cleaner.
Hopefully somebody from the back-end team will respond, so that an in-depth investigation can take place to identify the root cause(s) of this.
By restart, I meant restarting the Tomcat instance (service tomcat7 restart).
Users have reported similar slowdown issues as you described in DHIS2-6201 as well. I was assuming it must have had been due to this possible memory leak (?). Do you also notice increasing RAM usage in server?
Yeah, hopefully somebody from backend team can look into this issue because the only temporary workaround for our case is a Cron job that restarts the Tomcat instance every night.
We are also facing same challenges (2,30 Build bf753d4, RAM 15 GB, still Tomcat 7): increased RAM, memory leaks, garbage collector failures that are likely related to Tracker capture. @Mohammad_Ullah perhaps this it’s been already tackled in 2.33, check from release notes:
I am the OP and If this helps anyone, we’re still using 2.30 but with build version of f2a4e3e, and it has been stable since. I would say, if situation permits, try with different build versions.
