LAC/E Maintenance

ShaunWat78
ShaunWat78
in Software Products
<p>I have been told by a few people that I am working for that the Dive:EmpowerInstrumentServer sub directories need to occasionally be cleaned out of "stray *.DAT files" as this eventually slows down LAC/E performance. </p><p></p><p>I have never been told this by anyone previously, can't find much documentation on it from Waters, and was wondering if it had any validity as well as associated risks. I imagine one risk would be accidentally grabbing a partial DAT file of a run in progress, but as long as you only purged files older than a week you should minimize that risk.</p><p></p><p>Thoughts and opinions are welcome...</p>

Answers

  • Aesica
    Aesica

    I believe this can also happen if a LACE is rebooted before recovering from buffering mode.

    I noticed during our recent upgrades that several LACEs had some of these orphaned .DAT files from months or years earlier. I suspect that if you do as you suggested and had a reasonable grace period then the risk of deleting live data could be minimised. I would imagine that performance would only be impacted once the disk gets close to capacity or if somehow the name of the file Empower wants to write already exists, which is probably unlikely at the very best.

  • ShaunWat78
    ShaunWat78

    This is along the lines of what I was thinking to be honest.

    The people here are telling me that this needs to be done on a monthly basis, which does not seem to make sense to me and I believe is an indication that there is a problem elsewhere.

  • DanRamlose
    DanRamlose

    Whenever I go through my routine to dislodge any buffered data that may or may not have moved on by itself, I routinely delete folders from long since archived/locked/removed projects.

    In other news, I've encountered 3 LACEs whose HDDs were so full that they ceased to function.

    2 of them had windows temp folders full of CAB files, presumably not deleted after updates were installed. A third had an Oracle folder full of log files in the empower portion of the file tree.

    Anyone else having these issues?

  • GeorgeM
    GeorgeM

    The only performance hit that I foresee is that these "abandoned" .DAT files will likely be logged in the Message Center as "Failed to recover C:Empower....DAT" and thus filling your Message Center every time it performs a recovery sweep (every 10 minutes).  If you have a few of these occurrences on a few LACEs that sweep every 10 minutes, I can see how the Message Center would get full and then possibly affect performance.

    I'm assuming you don't have several GBs of abandoned .DAT files filling your LACE hard drive; which would then be indicative of a different, more significant problem.

  • WL0724
    WL0724

    The main problem that we have seen is that projects cannot be "locked" as long as these files exist on the LACE.  Our QA group requires that all electronic data be locked after a project is complete and all data has been QA-reviewed.  The LACE must be rebooted to clear all of the orphan .Dat files for a project before Empower will lock the project.

  • DanRamlose
    DanRamlose

    You can also remote to the LACE and manually flush any cached data by going to C:EmpowerBin

    and entering InstrumentServer.exe -r via command window.

    Sometimes, there will be digital detritus left behind whether or not the node is rebooted after doing this.

    Copies of anything complete will usually make it to the server if they're not already there.

    Comparing before and after Recover.log files (C:EmpowerInstrumentServer) will let you know what has been addressed.

Categories