Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

The case of the Colossal MirthDb

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

  • The case of the Colossal MirthDb

    I've installed Mirth 1.7 and have 2 or 3 channel developed. Twice now, I've encountered a 'disk-full' situation. The file C:\Program Files\Mirth\mirthdb\seg0\c460.dat grows until the disk is completely full. Today the file is 21.3G. I can't open the Mirth Administrator due to the unavailablity of disk space. This is the second time i've had to Uninstall and Reinstall. Thankfully, I learned the first time to export the channels.

    Is there a setting i can apply to prevent this 'growing' problem?
    Thanks!

  • #2
    Re:The case of the Colossal MirthDb

    The problem is caused by the DB you're using: Derby.

    The default db is not recomended for real-life applications. You should change to another one (postgress, sqlsever, mysql, oracle, etc.)

    Comment


    • #3
      Re:The case of the Colossal MirthDb

      We faced a similar situation with default database. Did switching to other database help? We will try to move to MySQL and see if situation can be avoided.

      Comment


      • #4
        Re:The case of the Colossal MirthDb

        dawatson wrote:
        I've installed Mirth 1.7 and have 2 or 3 channel developed. Twice now, I've encountered a 'disk-full' situation. The file C:Program FilesMirthmirthdbseg0c460.dat grows until the disk is completely full. Today the file is 21.3G. I can't open the Mirth Administrator due to the unavailablity of disk space. This is the second time i've had to Uninstall and Reinstall. Thankfully, I learned the first time to export the channels.

        Is there a setting i can apply to prevent this 'growing' problem?
        Thanks!
        I think you mean your system's disk is getting filled right? then Mirth Administrator (or other programs won't run?).

        A simple way (maybe a bit crude) to prevent this is to separate your OS disk from your data disk. this is a common practice. Make the volume/partition/share/disk where you store the DB separate than your OS.
        Oscar Gonzalez
        : Home of the Mirth Healthcare Appliances.

        Comment


        • #5
          Re:The case of the Colossal MirthDb

          oscar wrote:
          I think you mean your system's disk is getting filled right? then Mirth Administrator (or other programs won't run?).

          A simple way (maybe a bit crude) to prevent this is to separate your OS disk from your data disk. this is a common practice. Make the volume/partition/share/disk where you store the DB separate than your OS.
          That would 'work' but IMHO it is a bad idea because it is a quick fix that mitigates one issue and not a permanent solution to establish a good environment to run Mirth in for production.

          If you have a Mirth instance which is getting enough traffic and requires that the Mirth DB do the logging then you shouldn't be running on Derby. Moving Derby to its own data volume only shifts the problem and does not solve it.

          A proper solution is to use a full database engine and to make sure that your message logging/pruning is set appropriately for your/your customers needs.

          Post edited by: jbartels, at: 08/21/2008 05:26
          Jon Bartels

          Zen is hiring!!!!
          http://consultzen.com/careers/
          Talented healthcare IT professionals wanted. Engineers to sales to management.
          Good benefits, great working environment, genuinely interesting work.

          Comment


          • #6
            Re:The case of the Colossal MirthDb

            Of course it's not a fix, just a band-aid. And it would simply prevent from having to completely start over each time it fills up, plus it is a good practice to separate OS volumes from data volumes

            I didn't mean to say this was a fix, but simply a "crude way" to get moving until a better DB and proper configs are established.
            Oscar Gonzalez
            : Home of the Mirth Healthcare Appliances.

            Comment


            • #7
              Re:The case of the Colossal MirthDb

              oscar wrote:
              Of course it's not a fix, just a band-aid. And it would simply prevent from having to completely start over each time it fills up, plus it is a good practice to separate OS volumes from data volumes
              Thats very good point, just because you're running a full database engine doesn't mean that Mirth can't still fill that database up and flood the disk. I had that happen a few months ago on a postgres-based Mirth VM with a small disk when my interface guy logged all the messages that came in for 3 or 4 days.

              Not storing messages or not storing them forever is vital. Pruning, 'only log errors', and 'don't store filtered' are there for a reason!
              Jon Bartels

              Zen is hiring!!!!
              http://consultzen.com/careers/
              Talented healthcare IT professionals wanted. Engineers to sales to management.
              Good benefits, great working environment, genuinely interesting work.

              Comment


              • #8
                Re:The case of the Colossal MirthDb

                Our Mirth instance was on a separate partition, not on the root partition and it got full as the Mirth db took up ~10GB! This pretty much brought the application to it knees. So we moved the db to an another partition which had enough room for it to grew (900GB partition) to solve the immediate crisis. We were logging in this instance and we stopped logging and deleted all the messages but did not see the size of the db go down. We are planning to move to MsSQL instance for our deployment. Will report back here how our experiment fared. One more thing we noticed is that when we do any kind of search on the messages, the db size goes up at least by another GB and returns back.

                Comment


                • #9
                  Re:The case of the Colossal MirthDb

                  maqboolp wrote:
                  We are planning to move to MsSQL instance for our deployment. Will report back here how our experiment fared. One more thing we noticed is that when we do any kind of search on the messages, the db size goes up at least by another GB and returns back.
                  So which DB are yo using now? The built-in one?
                  Oscar Gonzalez
                  : Home of the Mirth Healthcare Appliances.

                  Comment


                  • #10
                    Re:The case of the Colossal MirthDb

                    Yes, we are usng the built n Derby DB.

                    Comment


                    • #11
                      Re:The case of the Colossal MirthDb

                      "Yes, we are usng the built n Derby DB."

                      It's useless for anything but simple testing. Install mysql or something.

                      Comment


                      • #12
                        Re:The case of the Colossal MirthDb

                        maqboolp wrote:
                        One more thing we noticed is that when we do any kind of search on the messages, the db size goes up at least by another GB and returns back.
                        I'm not certain, but I think I might know why this is happening. When you run a search (SELECT query) every database engine will build certain tables internally to parse, manipulate, and present the result of the query. If you're searching on messages the intermediate tables could be quite large, especially if you're looking at a TEXT column (like the message body) or a non-indexed column.
                        Jon Bartels

                        Zen is hiring!!!!
                        http://consultzen.com/careers/
                        Talented healthcare IT professionals wanted. Engineers to sales to management.
                        Good benefits, great working environment, genuinely interesting work.

                        Comment


                        • #13
                          Re:The case of the Colossal MirthDb

                          I think I might know why this is happening.
                          that sounds logical. If you were to take an export/dump of the database before any queries are run, and another one after running the queries, you could then compare the two exports and maybe that would help to determine why and where the DB grew?
                          Oscar Gonzalez
                          : Home of the Mirth Healthcare Appliances.

                          Comment

                          Working...
                          X