6 Replies Latest reply on Aug 7, 2018 3:57 PM by mheere

    How to setup a PI Server to accept large amount of snapshot event values?

    szymkowicz

      I am looking for a baseline tuning for a PI Server (2017 R2 or later if it helps) in order to benchmark a PI AF Client (latest 2.10x) which generate in order snapshot value at 1 event value / s / pi point for 1 Million pi point type float32 with no compression.

      PI Server on new hardware Server grade Fast processor, RAM and a lot of I/Os with high speed SSD, Fast/low latency network

      Each PI Server(s) got its own dedicated server and PI AF got its own dedicated server.

       

      PI AF Client app on new hardware Server grade Fast processor, RAM and a lot of I/Os with high speed SSD, Fast/low latency network

      PI Server 2017 R2 install with default parameters except Update manager > Max Update Queue value: 20 000 000 Max: 100 000 000 and total update queue value 40 000 000 max 1 000 000 000

      Test1: PI AF Client app PIbufss to fan out to send the snapshot events to a 2 nodes PI Collective w/ 2017R2, but it seems to have contention/queuing after 250K event/s on an average windows of 5s

      Test2: PI AF Client app without pibufss so no fan out the snapshot events to a single node in a PI Collective w/ 2017R2, but it seems to have contention/queuing after 300K event/s on an average windows of 5s

      The PI AF Client app has been optimized to reduce overhead, API calls, memory management, latency GCC and multithread/core to spread the generation and API calls

      Test3: PI AF Client app on multiple servers -> much worse than Test1 and Test2

       

      So far the documentation I found can not define rules to tune/setup a PI Server for some simple requirements such as a monotic snapshot event flow.

        • Re: How to setup a PI Server to accept large amount of snapshot event values?
          André Åsheim

          Hi,

          If I understand you correctly you basically want to test how much data you can write to the PI server.

          To insure no data-loss this is more a HW configration than a SW configuration. The tuning parameters can only help you so far. It doesn't matter if you change the Max queue parameters if the server can't even receive the request.

          I would start looking at the HW sizing at: https://techsupport.osisoft.com/troubleshooting/hardwaresizing/hardwaresizing.aspx

           

          Note that when buffering is enabeled all data will be written to disk at the client node first then sent to PI, so you need to have good disks here as well.

          • Re: How to setup a PI Server to accept large amount of snapshot event values?
            jyi

            Hi Stephan,

             

            It's strange. You should not have gotten a recommended hardware sizing result based on your requirements. 

            This is because we generally want you to talk to us when your archiving data points are over a certain number. Please remember that your requirements now are for steady-state operation and we need to account for emergency situations as well.

            Please check if your inputs are correct (#Point count, interface scan rate and compression rate)

            Also, the default tuning parameters works the best in most cases. I would believe that the same is true for your setup as well.

            • Re: How to setup a PI Server to accept large amount of snapshot event values?
              mheere

              Hello Stephan,

               

              Back when we released PI Server 2012 we did ingress testing against the snapshot and archive.  The numbers we published at that time were 1M events/sec to the snapshot and 500K events/sec to the archive.  What you are looking to do is beyond what we've tested or documented for archive performance, and it's right on the raged edge of possible snapshot performance with some important caveats:

               

              -These numbers were pure ingress only.  There wasn't a single client connected to the server.  Client connections, especially to the update manager for real-time streams, absolutely will impact the ingress capabilities.  The numbers on this slide (https://pisquare.osisoft.com/message/78428-re-how-many-points-can-one-pi-data-archive-machine-handle#comment-78428 ) are individual maximums - not all attainable simultaneously.
              - It required multiple client sources of data to achieve these inputs.  The highest numbers we've seen for ingress from a single instance of buffer subsystem (the fastest ingress mechanism we have) are around the 300K event/s sec to the snapshot mar

               

              On the surface it looks to me like you need a minimum of 2 data archive servers to accomplish your goal, and even then you may not be able to get the required data rates leaving your client machine.

               

              I'd like to talk with you a bit more about your use case if you have the time.  We are just about to embark on a new round of PI data archive testing, and if I can understand exactly what you are looking to accomplish it may help us to design better tests.

               

              Thanks!
              Matt

              2 of 2 people found this helpful