3 Replies Latest reply on May 29, 2015 8:47 PM by Rhys Kirk

    What happens under the hood with PIPoint.UpdateValue and the Remove option?




      We have a script which exists to delete data from the archive that is not required. There are some queries to find points that we would like to remove, then there is a call to remove each of the values that looks like this:

      #now delete

      foreach ( $pointResults in $listResults)


              $valuesToDelete = $pointResults | Where-Object {$_.Value.Name -eq "Set To Bad" }

              if($valuesToDelete.Count -gt 0)



                  write-output "** Deleting Values for  **"

                  write-output $valuesToDelete | select PiPoint, Value, Timestamp | Format-Table

                  foreach($deleteValue in $valuesToDelete)








      Also going on at the same time on the PI server are a lot of queries and interfaces writing to the same tags that values are being deleted from. The PI server version is 3.4.380.


      This works OK, but when this script is running on a loaded server we notice a few problems

      1) Other data consumers start getting RPC Timeouts

      2) Some messages in the log like this T:3532 PT(ptid=2201,recno=2201,loc=11,flag=8): ptwait tick/timeout=120011/120000, RID|LLL|LC|LI|NAL=0|5|1|0|254 Lock[253].uc=4 QL.sc/tid=0/3704 threads=2,0,0 [-11106] Failed to lock archive-cache point


      These updates go into the exception queue, but it seems that when they are being processed it is either very expensive, or there is a lock that is preventing other things from happening normally, causing RPC timeouts (or both).


      We can throttle the points updates with re@move, but I was wondering if the point really does get locked for all updates while this operation is going on? Also, are there any alternative methods we should be looking at using to achieve this same functionality?


      Many thanks for any ideas or explanations.






        • Re: What happens under the hood with PIPoint.UpdateValue and the Remove option?
          Rhys Kirk

          Hi Ivan!


          Removing events from the PI Server is a horrendous process, I've been through it a lot over the last few weeks. Short of going to PI Config then AF SDK is as efficient as it gets, in fact you can bulk send deleted values but it is the piarchss thread that suffers trying to remove the values.

          As far as I understood removing values causes a couple of trips to the archive, the event is queued for deletion and has to be read from the archive before the deletion actually occurs. I managed to try and keep a sustained amount of deletions streaming into the PI Server (around 1,000/sec) that seemed to work for a long while but would occasionally cause all incoming events to get queued whilst piarchss caught up with itself - higher attempts of removing values caused the blocking to happen more frequently. I noticed that in my scenario there was a cyclical pattern as to when piarchss would start blocking incoming events...approx every 10 minutes whilst streaming deletes. However that pattern may be different for each PI Server depending on load, but it did point that there is likely a background process running to "clean up", perhaps even reindex the archive files themselves. So the bigger your archives then perhaps the longer the reindex.

          It ended up taking as long to remove the data as it did for the data to first come into the system.


          Out of curiosity, your script is looking for "Set to Bad" are you seeing that digital status being generated from Abacus calculations?

          2 of 2 people found this helpful
            • Re: What happens under the hood with PIPoint.UpdateValue and the Remove option?

              Thanks Rhys! Yeah I kind of suspected that it was just a very expensive operation. We will have to throttle the deletes accordingly. Do you expect PI config to be any better?


              The Set To Bad is coming from some custom code which replaces values with "Set to Bad" as a sort of marker for getting deleted later. The reason is because these "Set To Bad" states get replicated across PI to PI.

                • Re: What happens under the hood with PIPoint.UpdateValue and the Remove option?
                  Rhys Kirk

                  My view after testing AF SDK was that although piconfig has less fluff than the AF SDK, both routes will still hit the same bottleneck. I didn't test piconfig so don't have a direct comparison.


                  I also conceded that the mass deletes (millions of events from a mis-performing interface) I had to perform are a rare case that I shouldn't have to do often. If you're looking to periodically delete, which I think you possibly will be, then you'll want to get the PI Server devs on speed dial.


                  It would still be interesting to hear from the PI Server team on the internal mechanics for handling a delete, and if indexes are periodically rebuilt after a delete etc.
                  Stephen Kwan Denis Vacher Omar Shafie

                  1 of 1 people found this helpful