ICU startup on high latency networks
On high latency networks, it can take ICU many minutes to start because every interface on the PI Data Archive is checked. Minimize startup time by caching a node's registered interfaces.
Ted Orme
shared this idea
7 comments
-
jcox
commented
The most significant delay we experience is during the "Checking for ISU instances" part of the loading process. A simple checkbox to disable checking for ISU instances would be a huge improvement
-
Moshe Sabag
commented
PI ICU takes a considerable amount of time time to load when multiple interfaces are used with the same data archive collective. This would be a very useful improvement to the product if the time is reduced and will help PI system admins a lot.
-
sahilp
commented
This is really a bad situation. The "workaround" I have is to open the ICU in the morning and schedule my activities for the afternoon
-
Eduan
commented
I agree, it is a killer. I have had to revert to old-style sometimes, where I do not use ICU but write the interface files in notepad, not the best solution, but functional. Maybe it is time this is written into AF instead of mdb.
-
Bottacin Alberto
commented
For PI monitoring purpose we install on several PI Interface Nodes and PI/AF Servers some monitoring Pi-interfaces (PerfMon, TCP-Response and SNMP) and all of this interface write tags on a centralize PI Server.
When you open the ICU on a monitored PI machine, it scans all the interfaces on the target servers, also the ones installed on others monitored machines: for example, if there is a PerfMon installed on “HOST1” and another on “HOST2” where both are collecting data of the hosting machine and both are pointing to the centralized monitoring PI server, when I start the ICU on “HOST1” it try to loading both interfaces (“HOST1” and “HOST2”). This is a very big problem in term of ICU loading time in case of several interfaces installed each one on different “HOST” that pointing to the same centralized PI server (this is the monitoring scenario, but we have the same problem also for loading PI2PI that are pointing to a centralized PI concentrator).I thought that the ICU loads the data from the ModuleDB (MDB) of the target PI server: right now all the monitoring interface are connected to monitoring PI server with the same user that has Read access to all MDB items. I tried to manage the Trust/Mapping in order to use different PI Indentity and give to a determinate PI Identity the access only to the related Machine/Interfaces on MDB. I did the following steps as a first test:
1) Create a new Pi-Identity “ID1” on the monitoring PI server (destiantion of the interfaces)
2) Modify the Mapping/Trust on the monitoring Pi server in order to use “ID1” only for Perfom/TCP-Response/SNMP Interfaces installed on “HOST1”
3) Edit the MDB access rights as below:
%OSI → removed R access for PiWord + added R/W access for “ID1”
Interfaces → added R/W access for “ID1”
“HOST1” → added R/W access for “ID1”
“PIPerfMon_HOST1” → added R/W access for “ID1”
“PISNMPTrap_HOST1”→ added R/W access for “ID1”
“TCPResp_HOST1”→ added R/W access for “ID1”
After that, I tried to start again the ICU on “HOST1” but the attached error appeared.Then, I did the following additional activities:
1) add the R/W access for “ID1” identity on “PIModules” table of database security on the centralized monitoring PI server
2) Edit the MDB access rights as below (in addiction of rights edited before):
%OSI → added R access for PiWord
After that I tried to start again the ICU on “HOST1” but it starts to “searching for ISU instances for..” each machine on the target MDB tree (see “SearchingForISU.PNG” attached).
To recap, this is the same issue saw before start the activity described here.So as far as I understood the problem seems: ICU searchs ISU (Iterface Status Utility - that seems a legacy utility: https://techsupport.osisoft.com/Products/Interfaces/PI-Interface-Status-Utility/Overview) on each interface on the MDB of the PI servers (or colledtive) selected to be loaded on ICU.
-
mbailey
commented
Same boat. They need a better solution here. 10 minuets is short! Ours can take over 45 min.
-
JEyth
commented
This is also a problem on faster networks in large systems. Could ICU search the database more efficiently so it only reads the interface configurations for the local machine? We have hundreds of interfaces that are spread over approximately 100 machines which connect to the same collective. Even on the collective's local network it can take a few minutes for ICU to finish reading all of the configurations.
