[BUG] MirthConnect consumes 100% CPU what causes long queue about connect HOT 3 CLOSED

When the CPU is high take a thread dump from the Java process.

That thread dump will show you what CPU intensive operations Mirth is performing.

Thread dumps will not contain PHI or PII but will contain channel names. If you're comfortable with disclosing your channel names you can post the entire dump here as a file attachment.

If you are not look for threads that are in the RUNNABLE state and post snippets of the stack traces to find the offending operation.

During the CPU spikes what is your database doing? Any slow running queries?

from connect.

I've found something like that

"Database Reader Polling Thread on 031-queue (122d9579-b839-4866-baf6-05b4759d3483) < 122d9579-b839-4866-baf6-05b4759d3483_Worker-1" #202 [204782] prio=5 os_prio=0 cpu=1480876.34ms elapsed=78307.11s tid=0x00007f92b801c0b0 nid=204782 waiting on condition [0x00007f924a9f8000]
`"122d9579-b839-4866-baf6-05b4759d3483_QuartzSchedulerThread" #203 [204783] prio=5 os_prio=0 cpu=3143.78ms elapsed=78074.08s tid=0x00007f92b8028e70 nid=204783 in Object.wait() [0x00007f924a8f7000] `
"122d9579-b839-4866-baf6-05b4759d3483_Worker-1" #202 [204782] prio=5 os_prio=0 cpu=1480870.80ms elapsed=78074.08s tid=0x00007f92b801c0b0 nid=204782 in Object.wait() [0x00007f924a9f8000]

Queue/channel named 031-queue consumes cpu=1480876.34ms

from connect.

You have a stuck or slow running query. You can recover from the condition by having postgres kill the queries your DB poller is running.

Then you can tune your queries to be faster and more efficient for each poll.

from connect.