Announcement

Collapse
No announcement yet.

Mirth Connect Administrator client startup is too slow

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth Connect Administrator client startup is too slow

    Hi,
    I'm working with Mirth Connect Server 3.4.2.8129 and some performance issues are arising.
    When i try to perform login, it takes too much time to show the dashboard screen (30 minutes in average).
    Also sometimes the client screen crashes.


    Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
    2GB RAM
    CPU and MEM usage are both ok.

    I would be very grateful if anyone could help.

    Regards
    Attached Files

  • #2
    Is the mirth db healthy ? Does it has space to grow? I recommend pruning data first, followed by an intensive check on the channels that are using lot of resources and patching them.
    Last edited by siddharth; 08-02-2018, 10:21 PM. Reason: foo
    HL7v2.7 Certified Control Specialist!

    Comment


    • #3
      Have you tried clearing your java cache and reinstalling?

      Are you able to test logging in from multiple workstations? Do they all have the same problem?

      Are the server and workstation on the same network? I haven't experienced anything as extreme as what you're describing, but my administrator noticeably slows down when I'm connecting over a vpn as opposed to when I'm sitting in the office.

      Which version of Java are you using?

      Comment


      • #4
        Thanks for the replies!

        @siddharth Yes, i guess. At least it's not lacking resources. How can i know if a channel is using a lot of resources? It's worth noting that the problem happens in all our environments and production has way more data than the others. Only when running mirth locally this doesn't happen. There's no network problem that we're aware of.

        @agermano, I've tried that in the past and it didn't help. All workstations have the same problem, yes. Restarting the server solves the problem for a short time, but we can't do this in production. In development, they're on the same network and the problem also exists, even though there's much less data than in production. We use Java 8.

        Comment


        • #5
          the most likely indicators are mappings, it gives a list of variables the channel uses. The value changes per message. So if you have lot of them variables, it can be a cause. Now here, you said after a restart it is good for a while. This is second indicator, that as time grows mirth is hogging up the heap space, but not so much to cause a GC overhead exception.
          HL7v2.7 Certified Control Specialist!

          Comment


          • #6
            Try taking a threaddump (jstack) of the client-side Administrator JVM when the issue is occurring.
            Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

            Nicholas Rupley
            Work: 949-237-6069
            Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


            - How do I foo?
            - You just bar.

            Comment


            • #7
              Hi guys,
              The configuration was setted up to consume only 512MB, but even with the mem setup configured to 1.5GB, the problem still was happening.

              We've upgraded our machine configuration. Now, it has 8GB and 6GB is reserved for running mirth service. Finally the problem was solved.

              We added Xms and Xmx params into mcservice.vmoptions file.

              Thank you everyone!

              Comment

              Working...
              X