High CPU usage after updating patient coded diagnosis in OpenMRS

OpenMRS Version: 2.1.0 Build 7eadd7

I notice my CPU usage reaches 100% as soon as I am updating a patient coded diagnosis through OpenMRS or Bahmni. The OpenMRS page I am talking about is this

My CPU is i7 with 16gb of RAM (8 for vagrant box and 8gb for the host machine)

Below is the thread dump.

jstack.9008.105815.765486924.txt (217.3 KB) jstack.9008.105824.965972369.txt (221.1 KB) jstack.9008.105834.913472995.txt (222.1 KB) jstack.9008.105840.153660121.txt (222.9 KB) jstack.9008.105859.995023853.txt (222.9 KB) jstack.9008.105849.813187915.txt (223.1 KB)

Can anyone share their server specs and configuration here ? Do I need to modify the openmrs.conf file ?

I am reopening this question because this issue hasnt been resolved. Increasing the java heap to 4096m does not really solve the issue. The issue only comes back after updating patient coded diagnosis in the observation form.

how can I debug this issue ? Is it possible that there’s some long query running during the update ?

Do you mean as soon as you click the Save Observation button?

Yes as soon as I pressed the save observation button.

Just to make sure that there is no other module interference, can you try it again with only the legacyui module installed to see if you still have the same problem?

Ill check on that and update you. By the way, is there a way to force apply constraints on openmrs tables ? I am afraid I might have removed one or two constraints by accident when I was removing concept diagnosis and this might have caused the high CPU usage. Or maybe that has nothing to do with it.

If this is not a production database, you can as well just delete the database and recreate it.

I have stopped all modules except the legacy UI. I tried adding several observations(6 times) for a patient then the CPU hits 100% again. Is it possible because I have a large set of concept of type diagnosis (82789 records) ?

You can prove that. Make a database backup, then delete a good number of them and test again.

I removed most of my diagnosis concept. Its now left with 1700 records. I think the main issue is when I try to fill in the “answer concept” field, it calls this

I try to change the field value multiple time (without saving the observation), thus the dwr calls above is called multiple time as well and the high CPU usage issue reappears again.


I guess I’ll need to setup the openmrs development environment so I can find out what that function does in the backend. I will update if I encounter any issues or not here.

I have downloaded the source code and start debugging the web service. Basically it calls the following

	@Transactional(readOnly = true)
	public List<ConceptSearchResult> findConceptAnswers(String phrase, Locale locale, Concept concept) throws APIException {
		List<ConceptSearchResult> concepts = getConcepts(phrase, Arrays.asList(locale), false, null, null, null, null,
		    concept, null, null);
		return concepts;

It triggers the above function regardless the phrase size (empty string too). Since I have about 88000 records, the function returns all those records and try to initialize them one by one.

I am thinking of setting some conditions, lets say only call this function if the phrase size is 3 or more. The other condition is only search for concept that starts with that particular phrase. E.g. “something%”.

My questions:

  1. Is my intended solution applicable ? Will it have any impact on other modules or functions ?
  2. I am using openmrs with Bahmni. If I manage to patch the code and repackage the war file. Should I just replace the war and everything will just work as it was ?

Any feedback on this is very much appreciated.

A few things:

  • The tool you’re using here is very old, so I’m not surprised you’ve discovered this significant issue in it. I would think that from the Bahmni and OpenMRS Reference Application perspective it’s worth building a specific screen just for correcting diagnoses, which has better UX. (However that requires someone to do development work.)
  • There’s a team working on what will eventually be a replacement for this tool in OpenMRS, but it doesn’t cover the Obs use case yet. Their preliminary work is here: Encounters and Observations UI mockup
  • If you want the easiest quick-fix, I would suggest you patch the DWRConceptSearch function, as this will have the least effect on everything else. This page is in the “legacyui” module in OpenMRS, and you should be able to build a new version of this and add it to Bahmni without affecting other things. (It won’t require a new WAR.)

  • If you want to write a bit more code (rather than just a quick patch), you could do a custom HTML + JS screen to fix diagnoses (maybe packaged as an OWA).

1 Like