Send number of allocations in span as metric #1805
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marcotc
approved these changes
Dec 6, 2021
I recently noticed that while we usually collect the number of memory allocations on a given span, we send it as an "allocations" field to the agent and this data never seems to make it to the backend. Instead, this refactor reports it as a span metric, which makes it available to customers.
ivoanjo
force-pushed
the
ivoanjo/rfc-allocations-as-metric
branch
from
1a2ffac to
59e8449
Compare
Codecov Report
@@ Coverage Diff @@
## 1.0 #1805 +/- ##
==========================================
+ Coverage 98.16% 98.18% +0.02%
==========================================
Files 943 943
Lines 46167 46171 +4
==========================================
+ Hits 45318 45332 +14
+ Misses 849 839 -10
Continue to review full report at Codecov.
|
|
@marcotc Care to give it another quick check? I've added/fixed the tests. |
ivoanjo
changed the title
ivoanjo
added a commit
that referenced
this pull request
Feb 20, 2023
**What does this PR do?**:
This PR adds a new profiler public API:
`Datadog::Profiling.allocation_count`.
The public documentation for this API is as follows:
> Returns an ever-increasing counter of the number of allocations
> observed by the profiler in this thread.
>
> Note 1: This counter may not start from zero on new threads. It
> should only be used to measure how many
> allocations have happened between two calls to this API:
> ```ruby
> allocations_before = Datadog::Profiling.allocation_count
> do_some_work()
> allocations_after = Datadog::Profiling.allocation_count
> puts "Allocations during do_some_work: #{allocations_after - allocations_before}"
> ```
> (This is similar to some OS-based time representations.)
>
> Note 2: All fibers in the same thread will share the same counter
> values.
>
> Only available when the profiler is running, the new CPU Profiling
> 2.0 profiler is in use, and allocation-related
> features are not disabled via configuration.
> For instructions on enabling CPU Profiling 2.0 see the ddtrace
> release notes.
As long as CPU Profiling 2.0 is in use, this API is enabled by
default. To disable it, this PR adds a new setting:
```ruby
Datadog.configure do |c|
c.profiling.advanced.allocation_counting_enabled = # ...
end
```
**Motivation**:
This feature has long been something we want to provide with ddtrace,
see issues #2164 and #468, as well as PRs #1891, #1805, #597
As part of the ongoing work of enabling allocation profiling,
counting the number of allocations comes at a very cheap cost since
the profiler needs to have a `RUBY_INTERNAL_EVENT_NEWOBJ`
tracepoint anyway -- it's just a matter of also incrementing a
counter inside it.
**Additional Notes**:
Note that this does not yet change any user-visible feature for
ddtrace. I'm counting on @marcotc to pick up the task of using this
API to make some tracing magic :)
**How to test the change?**:
This change includes code coverage.
---
Fixes #2164
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I recently noticed that while we usually collect the number of memory allocations on a given span, we send it as an "allocations" field to the agent and this data never seems to make it to the backend.
Instead, this refactor reports it as a span metric. Does this make sense?
This is still missing tests and whatnot, but I wanted to get a feel if I'm doing this correctly before I did the full changes.
Also, as requested by @delner I'm targeting this to the 1.0 branch.