chore(profiler): remove remaining max_events config stuff #14205
Conversation
DD_PROFILING_MAX_EVENTS doesn't do anything since #13988. This commit just cleans up some remaining references we missed.
|
|
nsrip-dd
added
the
changelog/no-changelog
Bootstrap import analysisComparison of import times between this PR and base. SummaryThe average import time from this PR is: 280 ± 6 ms. The average import time from base is: 280 ± 2 ms. The import time difference between this PR and base is: -0.5 ± 0.2 ms. The difference is not statistically significant (z = -2.71). Import time breakdownThe following import paths have shrunk:
|
Performance SLOsCandidate: nick.ripley/remove-max-event-references (167e4bd) 🔵 No Baseline Data (24 suites)🔵 coreapiscenario - 12/12 (2 unstable)🔵 No baseline data available for this suite
|
DD_PROFILING_MAX_EVENTS doesn't do anything since #13988. This commit just cleans up some remaining references we missed.
In #14205 we removed the _interval parameter for the MemoryCollector. This was a mistake. Now the memory profile collector thread basically spins in a tight loop because the interval is 0. Add that parameter back.
In #14205 we removed the _interval parameter for the MemoryCollector. This was the wrong thing to do. Now the memory profile collector thread basically spins in a tight loop because the interval is 0. Add that parameter back.
…ckport 3.12] In #14205 we removed the `_interval` parameter for the `MemoryCollector`. This was a mistake. Now the memory profile collector thread basically spins in a tight loop because the interval is 0. Add that parameter back. Backports #14276 to the 3.12 branch. This was fixed in 3.12.0 but somehow didn't make it to 3.12.1 or 3.12.2
…ckport 3.12] In #14205 we removed the `_interval` parameter for the `MemoryCollector`. This was a mistake. Now the memory profile collector thread basically spins in a tight loop because the interval is 0. Add that parameter back. Backports #14276 to the 3.12 branch. This was fixed in 3.12.0 but somehow didn't make it to 3.12.1 or 3.12.2
…port 3.12] (#14485) In #14205 we removed the `_interval` parameter for the `MemoryCollector`. This was a mistake. Now the memory profile collector thread basically spins in a tight loop because the interval is 0. Add that parameter back. Backports #14276 to the 3.12 branch. This was fixed in 3.12.0 but somehow didn't make it to 3.12.1 or 3.12.2 The actual fix was picked up by #14487 and this PR is mainly to add a release note. ## Checklist - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) ## Reviewer Checklist - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) Co-authored-by: Taegyun Kim <taegyun.kim@datadoghq.com>
PR #14205 introduced a significant performance regression, where the profiler created a thread which consumed an entire CPU core spinning in a tight loop. Our macrobenchmarks captured this increased CPU usage, but we didn't have any SLOs defined. This commit adds an SLO for CPU usage based on the typical CPU usage prior to that regression. This commit also adds an RSS SLO, again based on typical usage.
PR #14205 introduced a significant performance regression, where the profiler created a thread which consumed an entire CPU core spinning in a tight loop. Our macrobenchmarks captured this increased CPU usage, but we didn't have any SLOs defined. This commit adds an SLO for CPU usage based on the typical CPU usage prior to that regression. This commit also adds an RSS SLO, again based on typical usage.
PR #14205 introduced a significant performance regression, where the profiler created a thread which consumed an entire CPU core spinning in a tight loop. Our macrobenchmarks captured this increased CPU usage, but we didn't have any SLOs defined. This commit adds an SLO for CPU usage based on the typical CPU usage prior to that regression. This commit also adds an RSS SLO, again based on typical usage.
DD_PROFILING_MAX_EVENTSdoesn't do anything since #13988. This commit justcleans up some remaining references we missed.
Checklist
Reviewer Checklist