Subscribing is a smart move!
You can subscribe to this forum after you log in or create your free account.
Geo SCADA Performance Investigation Quick Start Guide
Geo SCADA Knowledge Base
Access vast amounts of technical know-how and pro tips from our community of Geo SCADA experts.
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we?ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
In Geo SCADA Expert you have the power to configure many complex and useful behaviors, but with this power there are configurations that can cause performance issues.
Please see the Geo SCADA Expert Performance Guidelines document for details. Link.
We include below some specific items to help you investigate issues.
Logic Overruns
On a ViewX Client, use the Queries Bar to look at the Overruns column in the Logic Execution Status Queries List. Overruns are an indication that scheduled Logic executions are being missed because the previous Logic programs have taken longer to execute
Logging
Check the Logging settings in the Server Configuration tool on the machine where the Geo SCADA Expert Server(s) are installed and modify the maximum number of files and/or file size to capture a longer time frame.
Snapshots
In the Geo SCADA Expert Server Configuration tool check the Snapshots Interval. You may want to shorten it to 15 or 5 minutes to review specific time periods. Use the Snapshot Analyzer tool if needed.
Client Updates
In the Geo SCADA Expert Server Status tool, review the Update Count in the Database | Interest section. This indicates whether any ViewX Clients are receiving many updates, which could be a cause of performance issues.
Accumulator Behaviors
Accumulators calculate interval data such as integration, run time or delta values. Their calculations can be configured to be Continuous or, if not Continuous they are calculated on update of the parent point. When configured to be Continuous the Report and Reset Period are used on a timed basis, and they exert a database and system loading when the Report or Reset times occur. If you have many Accumulators that are configured to be Continuous, then the system may exclude other activities at each Report and Reset time. You could consider this to be a load on the system with peaks at certain times. Keep the Report interval long to reduce the number of peaks. Individual database-write locks are used for each update.
When not configured to be Continuous, the calculations for the Report and Reset times are carried out whenever the source (input) point of the Accumulator changes, using the timestamps of the source change samples. The Accumulator is calculated for each Report and Reset time when the source change is received. If the source does not change often then many calculations could be performed by a single point update. The same database write lock for the point update (which may include other point updates in the same lock) is used for the Accumulator updates, consequently the database would be locked for the duration of many point and Accumulator calculations and would exclude other database activity such as serving client needs or serving driver requests. This may lead to pauses in client or driver behavior and, in extreme cases, drivers may lose server access and could restart.
A temporary mitigation for the above issue is to reduce the number of point updates passed from driver to server in a request (Maximum asynchronous point updates per request, in Server Configuration | Global Parameters | Drivers). The system should not be left with this mitigation, rather the configuration of Accumulators should be reviewed to reduce their calculation load.
Author
Create your free account or log in to subscribe to the forum - and gain access to more than 10,000+ support articles along with insights from experts and peers.