3 ms·

(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google) I recommend reading page 2 of the paper, which discusses the specifi

(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google) I recommend reading page 2 of the paper, which discusses the specific set of features that XRay offers. How do I get perf or DTrace to give me the six things listed there? I can only think of ways to get a couple of them.

dap 10y ago
> The cost is acceptable when tracing and barely measurable when not tracing. "Acceptable" is obviously relative, but with DTrace's pid provider, the cost is zero when not tracing, and about the cost of a fastcall per probe point when enabled. > Instrumentation is automatic and directed towards functions that are important for understanding the binary’s execution time. I'm not sure what this means, but with DTrace, you enumerate the functions or binary objects (with wildcards and such) that you want to instrument, and the framework takes care of reliably instrumenting them, no matter the state of the process. Is that "automatic" and "directed"? I need to read the rest of the paper more closely. > Tracing is efficient in both space and time -- only recording what is required and what matters. DTrace records exactly what you ask it to. It supports in-situ aggregation for cases where it's not tenable to record a complete log of all interesting events. This is an important part of the design. > Tracing is configurable with thresholds for storage (how much memory to use) and accuracy (whether to log everything or only function calls taking at least some amount of time). With DTrace, it's pretty easy to filter on function execution time. The buffer size is configurable. There are also multiple buffer policies for different use-cases (e.g., ringbuffer of the last N events leading up to some other event). > Tracing does not require changes to the operating system nor super-user privileges. If they're running Linux, as I imagine they are, DTrace isn't necessarily an option. Several other platforms have just ported it. Using it to record user-level state on your own processes does not require superuser privileges. > Tracing can be turned on and off dynamically without having to restart the server. Absolutely -- that's what the "D" is for. I'd strongly recommended checking out the DTrace paper: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill_html/ https://www.usenix.org/legacy/event/usenix04/tech/general/fu... There may be good reasons not to use DTrace for this, but I'm not sure which of those six goals would be the sticking point other than OS availability. (edit: I also haven't read beyond that yet!)

dap 10y ago

> The cost is acceptable when tracing and barely measurable when not tracing. "Acceptable" is obviously relative, but with DTrace's pid provider, the cost is zero when not tracing, and about the cost of a fastcall per probe point when enabled. > Instrumentation is automatic and directed towards functions that are important for understanding the binary’s execution time. I'm not sure what this means, but with DTrace, you enumerate the functions or binary objects (with wildcards and such) that you want to instrument, and the framework takes care of reliably instrumenting them, no matter the state of the process. Is that "automatic" and "directed"? I need to read the rest of the paper more closely. > Tracing is efficient in both space and time -- only recording what is required and what matters. DTrace records exactly what you ask it to. It supports in-situ aggregation for cases where it's not tenable to record a complete log of all interesting events. This is an important part of the design. > Tracing is configurable with thresholds for storage (how much memory to use) and accuracy (whether to log everything or only function calls taking at least some amount of time). With DTrace, it's pretty easy to filter on function execution time. The buffer size is configurable. There are also multiple buffer policies for different use-cases (e.g., ringbuffer of the last N events leading up to some other event). > Tracing does not require changes to the operating system nor super-user privileges. If they're running Linux, as I imagine they are, DTrace isn't necessarily an option. Several other platforms have just ported it. Using it to record user-level state on your own processes does not require superuser privileges. > Tracing can be turned on and off dynamically without having to restart the server. Absolutely -- that's what the "D" is for. I'd strongly recommended checking out the DTrace paper: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill_html/ https://www.usenix.org/legacy/event/usenix04/tech/general/fu... There may be good reasons not to use DTrace for this, but I'm not sure which of those six goals would be the sticking point other than OS availability. (edit: I also haven't read beyond that yet!)