Almost every time I’ve investigated such problems, they turn out to be programmer error. Specifically, doing a something in a foreground script that makes a gateway round trip. Anything that perturbs that round trip changes an unnoticeable milliseconds-level pause into a very noticeable multiple-seconds pause.
Audit your event scripts and runScript bindings for system.tag.*, system.db.*, and system.alarm.* calls. The only exceptions should be button actionPerformed events, since the user expects the system to go do something at that point.
This only happens on two HMIs running PIs mirroing off a VM.
and the only scripting added recently by my self you have seen on my other post. And I don’t think they relate to those 3 things. Maybe they increase the prior issue? I really don’t know at this point.
Try stopping the client and deleting the client’s cache. I have seen this happen too. Sometimes the files in the cache get corrupted and cause the client to get very slow and use a lot of memory.
Do a control+F and search within all windows/templates (make sure everything is selected to be sure) for runScript and then within those, look to see if the functions that are being called call system.tag\db\alarm.
If you find nothing, start searching for system.tag\db\alarm one by one - it’s possible they exist in some property change script that is perhaps taking much longer than you think, or worse getting stuck in some property change infinite loop.
I don’t think this would cause a client to freeze.
Regarding Control+F, try opening the problematic window(s) one at a time, and looking manually for runScripts, or property change events that call system.tag\db\alarm.
If you’re unable to even look through the designer to find what is wrong though due to it freezing up, then it’s probably time to call Ignition.