Topology 3: Things to note

The following details were discovered or used in the building or testing of this topology:

1. Impact of single-threaded Update Manager process on a topology of this size:

   1. During periods of high data ingress rates, such as when an interface node is emptying buffers after a disconnect/reconnect to Data Archive, Update Manager is susceptible to errors if there are a large number of sign-ups.

   2. Systems with heavy analytics usage should monitor Update Manager for errors. Update Manager errors can impact analyses' performance.

      1. If Update Manager errors are encountered, restart the PI Analysis Service and manually backfill the analyses for that time period.

2. Why is a Data Archive collective is required for a topology of this size?

   3. The PI Analysis Service runs on a separate node from Data Archive and has many Update Manager sign-ups. When the primary Data archive node is restarted or has a downtime event, Update Manager errors are frequently encountered on restart due to the large system size combined with the number of sign-ups from PI Analysis Service. Having a Data Archive collective enables PI Analysis Service to switch to the secondary in a more seamless manner during a primary Data Archive outage.

3. Details related to PI Analysis Service management:

   4. It is important to tune the PI Analysis Service configuration for systems of this size due to the variability in analytic configurations.

   5. Cache parameters

      • MaxCacheEventsPerAttribute, MinCacheEventPerAttribute, and CacheTimeSpanIn Minutes should be adjusted based on the average event rate/analysis rate to minimize the cache missed count. Adjusting these parameters has an impact on memory usage.

   6. Thread count parameters

      • NumberEvaluationThreads, NumberDataWriterThreads, and NumberParallelDataPipes were increased during testing to improve latency times.

   7. Load shedding can be enabled depending on the specific use case. If it is enabled, the Evaluation Skipped Count performance parameter should be monitored. Manual backfilling is required to fill in any missing calculations. See Analysis service configuration.

4. Potential Impact on data quality if PI Analysis Service is not configured correctly:

   8. During recovery from downtime events, calculations may run using older data and that will cause expression outputs to have the wrong values. To avoid and correct this scenario, follow these best practices:

      2. Monitor the PI Data Archive Update manager for errors,

      3. Monitor the Evaluation Skipped Count,

      4. Monitor the Maximum latency for steady, continuous increase to an unacceptable level.

      5. To correct these situations, restart the PI Analysis Service and manually backfill all analysis for those time periods.

5. Systems with significant PI Integrator for BA, PI Web API or PI SQL DAS requirements:

   9. Resource sizing for Topology 3 is based on the performance envelope specified.

   10. Systems extensively using PI integrator for BA, PI Web API queries, or PI SQL DAS queries will likely be able to improve performance with additional hardware resources for the SQL Server node and/or the PI AF Server node.

6. AVEVA PI Vision scalability is specified using concurrent connections, which may not match the number of concurrent users if some users open more than one display at a time. Scaling of concurrent connections is heavily influenced by both the complexity and volume of unique analysis data reference attributes displayed in open PI Vision displays. For optimal performance in PI Vision, Asset Framework (AF) analyses should output to PI points.