Announcement

Collapse
No announcement yet.

Performance problem

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

  • Performance problem

    We have been testing Mirth 1.5 here on Ubuntu Linux for the past few weeks by sending a few million messages at it and have been somewhat successful (particularly after making changes like swapping Derby for PostgreSQL and turning off saving messages in the Mirth UI.)

    Part of the channel we are using for testing saves the messages themselves to the PostgreSQL database (since we need them for other things). After a couple million messages, it got big and I have to move it to a 2nd hard drive.

    Shortly after moving the data (not the database application itself, though) to the new hard drive, I tried turning on Mirth again and the performance went south right away. Just starting up mirth.sh suddenly took over 3 minutes (and the Mirth UI performance turned downright ugly - it is basically unusable.)

    The database itself seemed to be performing fine after the move through other tools, like DBViz and pgAdmin. Since it was the only notable change I was aware of (and because it's an easy thing to test), I went ahead and installed an instance of mirthdb on MySQL and ran it. Same problem - 3+ minute startup.

    I set up some timers in the Mirth source and came across the culprit, this little guy in com.webreach.mirth.server.Mirth:

    muleManager = (MuleManager) builder.configure(configurationFilePath);
    Thinking that maybe then it's a Mule problem, I installed Mirth to a new directory (so I'd get a clean mule config and everything that goes with it.) I went to start it up and had the same problem - 3+ minute startup.

    The machine itself looks fine - the CPU's are < 5%, 700MB of available memory, and there is plenty of disk space.

    Now, I'm left with a machine that's acting bored, a clean mirth install, a clean mirthdb instance, and a clean mule configuration, and startup still takes 3+ minutes.

    Any ideas/thoughts/suggestions/encouragement would be greatly appreciated. In the meantime, I guess I have no choice but to get into the Mule source to see if I can't find anything there.

    Thanks in advance,
    Jeff

  • #2
    Re:Performance problem

    Do you have a .mule folder in the Mirth directory - check in there, is there a queue store with lots of files?

    Just to verify - you aren't storing any messages in the Mirth database?
    Chris Lang

    Comment


    • #3
      Re:Performance problem

      There are no files in .mule, only an empty directory named "4950554f-dbaf-48b7-9a4e-0c8d598921d9".

      We aren't storing messages in the Mirth database, and in the new instance I'm using a clean (empty) instance of mirthdb in MySQL.

      Comment


      • #4
        Re:Performance problem

        Sounds like a strange problem. Obviously, if a fresh install worked the first time, then a fresh install should work again, so there has to be something that is persistent across these installs. Please double check everything on the box to make sure it is actually using the new mysql database. Also, is this mysql a fresh install? Try dropping the entire database and starting fresh if it is not. We had this problem with a full postgres database that was never being vacuumed before. Try running a full vacuum on the postgres database and see what that does for you. Also try dropping the postgres database and recreating it if you are not sure how to vacuum it entirely.

        Jacob
        Jacob Brauer
        Director, Software Development
        NextGen Healthcare

        sigpic

        Comment


        • #5
          Re:Performance problem

          Jacob, that's what I was thinking - it's got to be something common across both instances.

          I was able to (eventually) set up a really basic test channel and verified that Mirth is using the new instance of MIRTHDB that I set up in MySQL.

          Comment


          • #6
            Re:Performance problem

            Has the box been rebooted since the new install?
            Chris Lang

            Comment


            • #7
              Re:Performance problem

              It has been now, and it didn't seem to have an effect. (Nice thought, though.)

              Also, psql isn't running but MySQL is. I've also confirmed that changing the title of my test channel is reflected in my MySQL instance.

              Another thing to note, when opening the Administrator, it logs in quickly but then says "Please wait: Loading components" and it takes a long time. Saving the change to the title of the channel is very quick but reloading the list of channels (in this case, only 1) takes a while.

              Comment


              • #8
                Re:Performance problem

                Can you confirm there is only one instance of Mirth running? Could the other instance still be started as service?

                What happens if you switch the new instance to Derby for testing? Same performance issues? Export your channels - how large is the resulting XML?
                Chris Lang

                Comment


                • #9
                  Re:Performance problem

                  "ps -ef | grep -i mirth" returns only the one I am running. Doing the same grep with "Launcher" returns only the one I am running.

                  Starting the database with derby (by setting "database=derby" in conf/mirth.properties) doesn't seem to be any quicker.

                  It's almost acting as if it's timing out waiting for something. After all, the box isn't busy and we know the databases are each pretty responsive outside the application.

                  Comment


                  • #10
                    Re:Performance problem

                    Try a new database and deleting mule-conf.xml from the conf folder - is that still slow?
                    Chris Lang

                    Comment


                    • #11
                      Re:Performance problem

                      Actually, in the conf directory of my re-install, there is no mule-config.xml, only a mule-boot.xml.

                      The MySQL instance I am using was only created a couple hours ago, and I haven't attempted to use it with my original install. It's running great in DBVisualizer.

                      Comment


                      • #12
                        Re:Performance problem

                        Hmmm...is the client running on a remote machine?
                        Chris Lang

                        Comment


                        • #13
                          Re:Performance problem

                          No, the client is on the same machine.

                          Comment

                          Working...
                          X