locked
Extended Events - What should I not be doing? RRS feed

  • Question

  • I am trying to understand what can cause issues in extended events, I have come across the following, so far

    Following actions can cause issues - debug_break,create_dump_all_threads,create_dump_single_thread

    EVENT_RETENTION_MODE=NO_EVENT_LOSS - This may cause detectable performance issues while the event session is active. User connections may stall while waiting for events to be flushed from the buffer.

    anything else please??

    Thanks

    Chinni

    Tuesday, November 13, 2018 8:13 PM

All replies

  • I've written  a blog post in my recommendations for XE, but that is more from a usability perspective. But perhaps there is some bits that can be of use for you... 

    http://sqlblog.karaszi.com/tips-for-getting-started-with-extended-events/


    Tibor Karaszi, SQL Server MVP (Web Blog)

    • Proposed as answer by Puzzle_Chen Monday, November 19, 2018 12:44 AM
    Tuesday, November 13, 2018 8:18 PM
  • Thank you. I read that now, it is helpful. 

    I would see if anyone else has more comments

    Tuesday, November 13, 2018 9:19 PM
  • Hi Chinni,

    All of the methods of collecting diagnostics data from SQL Server have "observer overhead" associated with them and can impact the performance of a workload under heavy load. It is hard to say what you should not do. Extended Events provide the least amount of overhead and provide similar capabilities for events and columns as SQL Trace. But not every Extended Event is suited for all situations. Here is a blog talking about this. They found every dump showed the server was producing XEvent which can cause high overhead by accident inproduction.

    Best Regards
    Puzzle
    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    • Proposed as answer by Puzzle_Chen Monday, November 19, 2018 12:44 AM
    Wednesday, November 14, 2018 1:40 AM
  • Hello Chinni

    We should be careful while configuring ring_buffer target. Max_memory configuration on the target should be appropriate or else MEMORYCLERK_XE memory clerk will use much memory.

    This article has some more details.

    Regards;

    Vivek Janakiraman
    www.jbswiki.com

    • Proposed as answer by Puzzle_Chen Monday, November 19, 2018 12:44 AM
    Wednesday, November 14, 2018 2:10 AM
  • Yes, common sense takes you a long way.

    One tip is to use the event_counter target first, if you are doubtful of how often an event occurs. Since this only counts how many times each event occurs, it has very low overhead. And this target don't even come with any config, dead-easy to use. Note that this target isn't in the wizard, so use the "real GUI" of you want to use a GUI to configure your trace.


    Tibor Karaszi, SQL Server MVP (Web Blog)

    • Proposed as answer by Puzzle_Chen Monday, November 19, 2018 12:44 AM
    Wednesday, November 14, 2018 9:28 AM
  • thank you all for the inputs. these are helpful. Yes, I understand that extended events are very specific to the problem we are dealing with. I was only trying to figure out what event/action can definitely be a bad thing to enable on a production instance (if enabled all the time) ex. enabling actions like - create dump, break process into debug are something I would not even attempt to enable for a long time on my production database. Also EVENT_RETENTION_MODE=NO_EVENT_LOSS seem to be one of those which I should not even enable. 

    Thursday, November 15, 2018 9:14 PM
  • Any other question? Please feel free to ask.
    If you have resolved your issue, please close the thread by marking the useful reply as answer. 
    Thanks for your contribution:-)

    Best Regards
    Puzzle
    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Friday, November 23, 2018 1:08 AM