Huge Memory usage

[pietropau]

When you set e new internal subscriber in opehhistorian (version 2.0.347.0) require high memory usage.

Thanks,
Pietro

[ritchiecarroll]

How large of a data set are you subscribing to? For example, how many metadata points exist in the openPDC?

[pietropau]

Openpdc is connected up 216 PMU (200 Voltage, 600 Currents).

Pietro

[StephenCWills]

I wasn't able to reproduce the issue. Can we get the hardware specs of the system running the openHistorian? Also, do you know about how long the openHistorian was running before you took the screenshot?

[pietropau]

Hardware specs: Dual-core Opteron 2.40 Hz with 8 GB RAM.
About memory, it takes two minutes for reach 8 Gb

[pietropau]

• I reset Openpdc and openhistorian configuration with "configuration setup utility"
• Openpdc configured with 1 PDC with 18 PMU and for receive internal metadata
• Openhistorian configured for receive external metadata from Openpdc

[ritchiecarroll]

I guess the best thing we can do at this stage since we are not able to replicate your issue is to get a fresh copy of your log files at system start-up. To do this, stop the openHistorian service and delete (or rename) the following files: StatusLog.txt and ErrorLog.txt. Then restart the openHistorian and send us a copy of these log files a after few minutes. This may help us diagnose the issue you are seeing.

[StevenChisholm]

The openHistorian was originally designed to have a huge memory buffer for the archive files. After using it in production at OG&E, I've determined that Microsoft since Windows 2008 R2 does a decent job caching the files under the surface as long as they stay open. I'm in the process of reworking how aggressive the historian is at caching files. In the mean time, you can edit your application settings. This can be done by changing "MemoryPoolSize" under the "SystemSettings" in the "openHistorian.exe.config" file to something smaller. I think the value is in GB.

[pietropau]

Now it's openpdc that require huge memory.

In my opinion there exists a trouble in the configuration for internal connection between your openPDC and open Historian. Are configured both for receive internal/external metada? is it correct ?

Thanks
Pietro

[ritchiecarroll]

Can we get a copy of your log files?

[pietropau]

Health.txt
StatusLog.txt
ErrorLog.txt

[ritchiecarroll]

Note that these logs look to be for the historian. Since the openPDC is the one with a large memory pool, can we get those logs? Note that it would also be helpful to see your Status.txt as well - this file is only logged every thirty minutes, but it shows detailed status of all system adapters.

In the historian logs you provided I did see some errors, e.g.:

---

Failure code received in response to server command "MetaDataRefresh": Failed to transfer meta-data due to exception: Failed to open ADO data connection, verify "ConnectionString" in configuration file: Authentication to host 'localhost' for user 'root' using method 'mysql_native_password' failed with message: Reading from the stream has failed.

Failed to transfer meta-data due to exception: Failed to open ADO data connection, verify "ConnectionString" in configuration file: Authentication to host 'localhost' for user 'root' using method 'mysql_native_password' failed with message: Reading from the stream has failed.

---

However, it looks like the system may have recovered from these issues.

Also, are you running on a Virtual Machine?

Thanks,
Ritchie

[ritchiecarroll]

In the logs you have an IEEE C37.118 PDC style connection called PDC12 and a GEP style subscription called HIS. Can you provide a drawing of your configuration? Here is how I would recommend configuration of this system (based on my current understanding):

[StephenCWills]

Hi Pietro,

I think Ritchie has the right idea with the architecture diagram. I see a lot of messages in StatusLog.txt about out-of-sequence statistic measurements. Not only is it a highly unusual message, but it seems to be repeating the same IDs and timestamps while the count of out-of-sequence measurements continuously increases. This suggests you may have a data feedback loop, and that would also explain the memory usage going out of control.

It may be easiest to start over from scratch, making your connections according to the suggested architecture diagram posted by Ritchie.

Thanks,
Stephen

[pietropau]

We are trying to apply the architecture suggested, starting over from scratch.
The files provided are from openpdc folder.
The server is not virtual machine
I change PDC wit single PMU for test.

StatusLog.txt

[pietropau]

First test

1. I start over from scratch openpdc and openhistorian, I have configured one PMU into openPDC

2. Openpdc configured for receive internal/external metadata

3. Memory required by openpdc increasing

Second Test

1. I start over from scratch openpdc and openhistorian, I have configured one PMU into openPDC

2. Openhistorian configured for receive internal metadata

3. Memory required by openpdc increasing

[ritchiecarroll]

This is an incorrect configuration - so sorry for the confusion. The configuration listed is creating a feed-back loop. I will try to detail the steps:

[ritchiecarroll]

1. From openPDC: Connect to PMU
2. From openHistorian: Connect to openPDC, steps are as follows
   • Select "Inputs / Subscription Based Inputs / Create Internal Subscription":
     
   • Fill out info -- CRITICAL -- set port to _6165_ for openPDC:
     

That should correct issue - note that you may need to re-run Configuration Setup Utility for openHistorian and create a new database. Also: With openHisorian service stopped, I would recommend deleting current "C:\Program Files\openHistorian\Archive" folder to clear out current data.

[pietropau]

Ok now it's working, thanks

[ritchiecarroll]

Excellent!!