800xA 5.0 SP2 AC400 Connect Trend not updating while both CS History sevices are in service state

Trend is not udating while both Basic history services(CS1 and CS2) are service state.

If any one of the service is disabled trend is updating in all servers/stations.

Comments (0) New comment

ATHULPK Rank: 310

Asked 2 years ago

Answer this question Follow

Voted best answer

Hello,

Connectivity server(Basic history) are not synched.

Restart Server one by one, if that didn't work then

Copy Basic history data of one server in redundant server then restart one by one.

Thanks

Comments (1) New comment

Dash

Rank: 21

Answered 2 years ago

Answers

Sounds like a sync issue between the service providers.

What are the values for "Log, EnabledLogs, DirectLogs, EnabledDirectLogs and Percent synchronized" when viewed from Service Provider Status for each of the service providers?

All logs must be enabled to be able to reach 100% sync. The colored numbers should match as in the above image: EnabledLogs=Logs and EnabledDirectLogs=DirectLogs. If not, use Log Summary aspect to find which logs are not active and have them activated.

If the log counts does not match between CS1 and CS2; try restarting the one having lower numbers. If that does not help, restart the other.

If number of logs and log size is large (thousands and/or several GB disk) a manual sync could be done much quicker than waiting for automatic sync: Stop both providers. Copy the .log files across from "donor" to "recipient", then start the providers again.

Comments (6) New comment

by ATHULPK Rank: 310 on 8/16/2017 11:39:39 PM | Like (0) | Report

There is an event coming in Service Event viewer "OPC HDA read takes long time"

by Stefan Stromqvist AKS expert

Rank: 1 on 8/16/2017 11:45:40 PM | Like (0) | Report

That indicates that a request has taken more than 2 minutes to fulfill.

Either there is a very large request made by someone (not only operator trends may request history data: Excel, reports, third party OPC HDA, etc is also possible).

If there should be a memory leak in the AdvHtHistorySrv.exe, with increasing PrivateBytes/VirtualBytes the time to read data would grow, eventually triggering this event.

Keep a watch (perfmon.exe) on the counters and tell me what figures you get and how the trend looks like over a period of a week.

Several memory leakages have been solved in more recent versions.

Avoid large requests from reports, etc.

Avoid using "Momentary" or "ExtMomentary" treatment in trends - use these only with small time scopes and for select trends. Default should be TimeAverage, at least for longer trends.

MiniTrends (encapsulated in VB6 or PG2 graphics are hardcoded for ExtMomentary, the "worst" treatment of them all since all datapoints need to be requested even if they can not be painted due to lack of pixels.

by ATHULPK Rank: 310 on 8/17/2017 2:03:06 AM | Like (0) | Report

As per your first comment I had deleted matched EnabledLogs,Logs and EnabledDirectLogs,DirectLogs. And percentageSynchronized for CS2 reached 100%.. And CS1 is slowly increasing but the service for CS1 is automatically restarting...

by Stefan Stromqvist AKS expert

Rank: 1 on 8/17/2017 3:48:23 AM | Like (0) | Report

If it is restarting, look for exception logs.

C:\> dir /s C:\exception*.log
15/03/16 14:43 87,052 Exception_ABBIT32.log
17/01/28 16:48 3,812 Exception_AdvAeAlarmManager.log
17/02/03 12:56 5,688 Exception_AdvDsOPCConnector.log
17/01/27 18:21 9,692 Exception_AfwADServer.log
17/01/29 21:58 24,218 Exception_AfwFsdSrv.log
15/12/16 14:36 25,746 Exception_AfwRAS.log
17/01/28 04:43 3,808 Exception_AfwSystemMessage.log
17/02/02 13:40 3,798 Exception_AfwXRefSrv.log

Look for AdvHtHistorySrv.log with NEW date & time. Old files can be deleted.

If found, momentarily enable "Dump On Exception", collect, compress the dumps and hand them over to regional ABB support and ask for a support case to be created.

Did you find any vidence of running out of memory? AdvHtHistorySrv.exe can not grow above 2GB virtual bytes on a 32-bit OS - in fact, anything above a few hundred MB is abnormal. Did you log memory use as I hinted?

A good configuration is less than 10.000 logs and less than 50 GB of disk space used for logs.

by ATHULPK Rank: 310 on 8/18/2017 12:34:11 AM | Like (0) | Report

There is no any new AdvHtHistorySrv.log. And AdvHtHistorySrv.exe is taking virtual memory of 500mb.

by Stefan Stromqvist AKS expert

Rank: 1 on 8/18/2017 12:39:24 AM | Like (0) | Report

500 MB is very large in terms of what is normal for that process. Did you read Private Private/Virtual Bytes with perfmon.exe (do not use Task Manager)?

I believe you should report a support case - something is not as it should.

Add new comment

Stefan Stromqvist AKS expert

Rank: 1

Answered 2 years ago

Question details

800xA 5.0 SP2 AC400 Connect Trend not updating while both CS History sevices are in service state

Voted best answer

Answers

Other questions needing answers

Related topics

AKS experts