6 Replies
      Latest reply on Jan 14, 2019 10:13 AM by dmaclach
      dmaclach Level 1 Level 1 (0 points)

        So I am logging using os_signpost.


        My begin format string contains two strings "language: %s message: %s".


        My end format string contains one string "size: %zu".


        I am running on an iMac Pro 2017. I should have lots of processing power....


        I am routinely running into problems where the Data stream is logging run issue messages "due to high rates in live mode recording. Try windowed recording mode".


        It appears in general that the messages being dropped are my end messages.


        I have tried windowed recording mode, and it doesn't really seem to help. Is there anything I can do to improve performance so messages aren't being dropped? Compared to something like dtrace recording system calls I don't think I am logging that much data. The fact that it's the end messages that are being dropped is really messing up my graphs because my instrument believes that the interval is still open which means my graphs get incredibly deep incredibly quickly.


        I could easily turn language into an enumeration if parsing/recording a %d is significantly faster/easier than parsing/recording a %s.


        Any thoughts would be appreciated.




        • Re: messages lost due to high rates causing issues
          dmaclach Level 1 Level 1 (0 points)

          Converting "language" to an enum ("language: %d message %s"), and converting "size" so that it was just "%zu" instead of "size: %zu" thinking it may be faster to parse did not seem to improve my life dramatically except for making my code a little harder to read.


          Filed radars

          47211696 [custom instruments] defaults for <enum> Elements


          47211508 [custom instruments] <enum> as a top level declaration


          while going through the exercise of using enumerations.


          Is os-signpost-interval-schema recording backtraces even though I don't care about backtraces? I don't have a backtrace column anywhere...

          • Re: messages lost due to high rates causing issues
            cwoolf Apple Staff Apple Staff (30 points)

            Since you're on a Mac, run "log stats" from the command line.  If you want to be pro, you can use "log collect" to create an archive of the window of time you were seeing the problem, then run "log stats --archive path" to narrow it down.  When it finishes, it will give you a break down of who is filling up the logs.  Logging is a shared resource on the system, so the overload doesn't have to be caused by your app.


            In live mode, data is sent directly to an Instruments recording service, so if the recording service backs up, the data gets dropped rather than blocking the sender.  In Windowed Mode, logging signposts goes into something like a circular memory buffer, so it's very hard to overload.  The downside is that the older data is evicted from memory quicker.  If the problem you're seeing is still happening in Windowed Mode, then something isn't functioning as it was designed.  That's not good.


            With regards to live mode, choosing a target rather than All Processes can help, and not including instruments with wide open filters like "os_signpost" and "os_log" will also help.  Since I see the "custom instruments" tag, I'm assuming you've supplied a subsystem and category and are using your own custom instruments, so the filtering you get with that should help with the data loss.


            Oh, and finally, having "Console.app" open does change the equation a bit, so I'd recommend quitting that app before recording.

              • Re: messages lost due to high rates causing issues
                dmaclach Level 1 Level 1 (0 points)

                Sorry I wasn't completely clear...


                I am recording off of an iPhone (SE) to my Mac via USB. Not sure if that makes any difference.


                I am focusing on a single app, and the only instrument that I am recording is my own.


                Console.app is not open.


                As far as I know there is no equivalent to "log collect" to pick up data from my phone... happy to be educated of course