PHV Trends Very Slowly

Anyone else having issues with trending behaving very slowly (1-4 minutes to open a trend, go back in time, expand the time, etc.)? I have three plants (2 13.3.1, 1 14.3.1) and they all experience this issue. Seems to have started on the 13.3.1 plants after a hotfix (not sure which one). Unchecking View/Display Events in PHV usually speeds it back up (trends pull up in a second or two, same for adjustments). Restarting the ProPlus (Event Chronicle) also resolves the issue temporarily (a few days). 

I've also notice that when the issue occurs, opening the Event Chronicle Administration tool takes several minutes rather than the usual few seconds. Once open I don't see anything unusual. DeltaV Diagnostics also doesn't indicate any issues.

Have Hotix WS_28_CSS installed on the 13.3.1 plants and WS_08_CSS on 14.3.1.

22 Replies

  • Added more memory (from 4 GB to 32 GB) to the ProPlus (Event Chronicler) on a 13.3.1 system. After one month, trending is still working normally. By this point I would have already had to restart the ProPlus. I do notice the memory usage goes up over time for the DvDbServer.exe process and for the three instances of the SQL Server Windows NT - 64 bit processes. Its most pronounced for DvDbServer.exe which consumes around 94.7 MB after a restart and one month later is utilizing approximately 600 MB.
  • In reply to JoshC:

    Further follow-up. 90 days post restart DvDbServer.exe is now consuming 1,634.6 MB of memory so there appears to be a memory leak. However, since the computer has 32 GB (82% free) of memory, trending still performs normally. So the trending issues were definitely due to a lack of sufficient memory exacerbated by the ever growing demand of the DvDbServer.exe process.
  • In reply to JoshC:

    On your engineering workstations, do you periodically restart any applications that access the database? DvDbServer is the DeltaV Engineering/Configuration Database server and when you open something in Explorer or Control Studio it will cache information to make it faster in the future. That being said, the fact you are 90 days between restarts of the pro+ is pretty impressive. In a lot of plants, I know there will be a planned restart, Database Clean and Backup of the database done usually once every week or two. Might be something to look into as this also affects your configuration and download speeds as well.
  • In reply to Matt Forbis:

    Thanks for the reply Matt. I do have the database scheduled to be cleaned nightly, but I did not have the force disconnects option selected so maybe it hasn't been completing as often as it should. There does appear to be a somewhat persistent connection from the OPC server running on the Application Station to maybe that has been holding it up. I now have the force disconnect option selected so I will see what happens in the next few days.

    I see your point on restarting, but this has never been issue with 11.3.1, 12.3.1, 13.3.1,14.3, or 14.3.1 systems that I've worked on until certain hot fixes were applied on the 13.3.1 and 14.3.1 systems. The issue seems to have been fixed in a subsequent 14.3.1 hotfix but not the 13.3.1. Plus, I figure one of the reasons we buy server class machines is so that they don't have to be periodically rebooted.

  • In reply to JoshC:

    If you have connections to the Database Server and don't disconnect, the clean won't actually run, it will just abort without that option selected. A reboot of the server is not strictly required, but in some cases the engineering activity is so much that just the database gets fragmented and slows down performance even with no memory leaks. By disconnecting clients you will restart the database server periodically which will greatly improve performance. There are still some cases though that a full restart of the server just seems to be required.
  • In reply to Matt Forbis:

    We were experiencing slow trends only for those that included event chronicle data. Turns out the event chronicle log files were significantly large and increasing in size. The .ldf files should have been around 1024 KB, but one was 2GB!
    Check out these file sizes in the Event Chronicle folder, and get hold of GSC if you suspect the .ldf files are growing.
  • In reply to Matt Forbis:

    Thanks Matt. I checked this morning, and the DvDbServer process is now down to around 80 MB. I'll make sure to enable the force disconnects option on all my DeltaV systems.