locked
Problem with xperf RRS feed

  • Question

  • Hi,

    I followed the instructions in Silverlight TV 57: Performance Tuning Your Apps

    and when opening the ETL file (created from HeapMonitor) using xperf I got this warning:


    Performance Analyzer noticed that 13912 events and 0 buffers were lost in this trace.

    This is usually caused by insufficient disk bandwidth for ETW logging.
    Please try increasing the minimum and maximum number of buffers and/or
    the buffer size.  Doubling these values would be a good first attempt.
    Please note, though, that this action increases the amount of memory
    reserved for ETW buffers, increasing memory pressure on your scenario.
    See "xperf -help start" for the associated command line options.

    XPERF MIGHT NOT BE ABLE TO PROVIDE RELIABLE DATA IN THIS SITUATION.

    Would you like to continue analyzing this trace? 


    (I just clicked on Yes)

    Is that usual? I tried it in two computers running Windows 7 and got the same warning window.

    The commandline help wasn't very helpful...

    Tuesday, February 8, 2011 1:28 PM

Answers

  • The key clue here is the first line in the body of that error message, the part that says "This is usually caused by insufficient disk bandwidth for ETW logging."  You can try the corrections suggested in the error message, modifying the buffer sizes may very well help.

    However, I've found that there are a couple tricks to getting this work reliably.

    1. HeapMonitor is simply a light-weight wrapper around XPerf that enables the ETW loggers necessary to collect heap trace information.  Some of these ETW loggers are system-wide rather than being specific to a process, thus, minimizing the amount of activity on the system can help reduce the number of events being logged and therefore reduce the amount of bandwidth necessary to flush the in-memory buffers to disk.  In short, close down as many applications and services as you can before collecting your trace.
    2. If you have multiple hard disks, start your tracing session from the opposite disk than the one that your OS partition resides on.  Windows reads and writes to the disk a decent amount in normal operation.  Whenever the disk is busy doing things for Windows, it can't be flushing your event buffers to disk.  Ensuring that your trace is being written to a non-OS disk increases the chance that your events will be flushed to disk before they are lost.It

    It isn't always the end of the world when that message pops up either.  I've been able to gather a lot of useful information from traces with lost events, though I wouldn't recommend making a habit of it :)

    Try these ideas out and let me know if they work for you.

    Mike

    Wednesday, February 16, 2011 4:00 AM

All replies

  • The key clue here is the first line in the body of that error message, the part that says "This is usually caused by insufficient disk bandwidth for ETW logging."  You can try the corrections suggested in the error message, modifying the buffer sizes may very well help.

    However, I've found that there are a couple tricks to getting this work reliably.

    1. HeapMonitor is simply a light-weight wrapper around XPerf that enables the ETW loggers necessary to collect heap trace information.  Some of these ETW loggers are system-wide rather than being specific to a process, thus, minimizing the amount of activity on the system can help reduce the number of events being logged and therefore reduce the amount of bandwidth necessary to flush the in-memory buffers to disk.  In short, close down as many applications and services as you can before collecting your trace.
    2. If you have multiple hard disks, start your tracing session from the opposite disk than the one that your OS partition resides on.  Windows reads and writes to the disk a decent amount in normal operation.  Whenever the disk is busy doing things for Windows, it can't be flushing your event buffers to disk.  Ensuring that your trace is being written to a non-OS disk increases the chance that your events will be flushed to disk before they are lost.It

    It isn't always the end of the world when that message pops up either.  I've been able to gather a lot of useful information from traces with lost events, though I wouldn't recommend making a habit of it :)

    Try these ideas out and let me know if they work for you.

    Mike

    Wednesday, February 16, 2011 4:00 AM
  • how shall we proceed to modify the buffer size ?
    Friday, January 9, 2015 6:34 PM