Hi All;
Hopefully this will give you all a bit of a laugh as well as provide a good story on why reading the manual, or tool tip can save you loads of grief...
We have a virtual PICO-1000 appliance and have had this going for five or six years.
Our integration environment is fairly stable, so I don't go into it much as most of my new projects involve data repository and other stuff.
A couple of weeks ago I went into the appliance control panel and saw that we were eating up disk space.
Subsequent visits showed that the disk space was being eaten up very quickly. This was somewhat alarming.
I went in and checked message retention settings, and monitored the situation, finding it had no impact.
I did notice some time ago that a version of Mirth Connect had added a flag "Allow Message Archiving".
Disk space was becoming a bit critical. I had some other issues at the same time that Mirth support was looking at and didn't want to bother them with this.
It was around this time that I used the new tool in the appliance console that lets me see what is eating up disk space.
One table was eating 120 of my 298Gb!
I took a look, and eventually figured out that it contained database backups from a mysql database server.
I have my Mirth Engine doing tons of stuff, some of has nothing to do with integration.
One of these things is to take the backups generated by this server, and move them over to the same backup server on our network that the Mirth Appliance backs up to.
I was confused because I had this channel set to purge messages (and contents) after 1 day.
I don't know what planets aligned for me to notice this but I noticed right by the archiving setting "(Incomplete, errored and queued messages will not be pruned)"
./facepalm
This channel would occasionally throw errors. As I'm the only programmer for 5 hospitals, time is a premium and I just didn't have the time to go do any investigation...and the back ups ran most of the time, so I wasn't worried about it.
So yeah...there were a few hundred errors thrown over the past year.....and each message contained a full backup of at least one database.
Of course, I had never taken off this flag, as I thought message archiving would be a good thing. I didn't realize that with it on, I had to go in and manually remove errored messages.
So, I went through my 117 deployed channels, and, where appropriate, I removed the archive flag.
The next day, after the pruner ran, I went from 180+Gb used, to 75Gb.
So, even the best of us can do boneheaded things that can solved by simply paying attention to manuals and helpful text added to gui.
Hopefully this will give you all a bit of a laugh as well as provide a good story on why reading the manual, or tool tip can save you loads of grief...
We have a virtual PICO-1000 appliance and have had this going for five or six years.
Our integration environment is fairly stable, so I don't go into it much as most of my new projects involve data repository and other stuff.
A couple of weeks ago I went into the appliance control panel and saw that we were eating up disk space.
Subsequent visits showed that the disk space was being eaten up very quickly. This was somewhat alarming.
I went in and checked message retention settings, and monitored the situation, finding it had no impact.
I did notice some time ago that a version of Mirth Connect had added a flag "Allow Message Archiving".
Disk space was becoming a bit critical. I had some other issues at the same time that Mirth support was looking at and didn't want to bother them with this.
It was around this time that I used the new tool in the appliance console that lets me see what is eating up disk space.
One table was eating 120 of my 298Gb!
I took a look, and eventually figured out that it contained database backups from a mysql database server.
I have my Mirth Engine doing tons of stuff, some of has nothing to do with integration.
One of these things is to take the backups generated by this server, and move them over to the same backup server on our network that the Mirth Appliance backs up to.
I was confused because I had this channel set to purge messages (and contents) after 1 day.
I don't know what planets aligned for me to notice this but I noticed right by the archiving setting "(Incomplete, errored and queued messages will not be pruned)"
./facepalm
This channel would occasionally throw errors. As I'm the only programmer for 5 hospitals, time is a premium and I just didn't have the time to go do any investigation...and the back ups ran most of the time, so I wasn't worried about it.
So yeah...there were a few hundred errors thrown over the past year.....and each message contained a full backup of at least one database.
Of course, I had never taken off this flag, as I thought message archiving would be a good thing. I didn't realize that with it on, I had to go in and manually remove errored messages.
So, I went through my 117 deployed channels, and, where appropriate, I removed the archive flag.
The next day, after the pruner ran, I went from 180+Gb used, to 75Gb.
So, even the best of us can do boneheaded things that can solved by simply paying attention to manuals and helpful text added to gui.
Adventures in not reading the manual...or tooltip...a cautionary tale
0 commentaires:
Enregistrer un commentaire