[FEATURE]: Support Datadog Profiler with uWSGI pre-fork model #15152
Description
Package Name
uwsgi
Package Version(s)
3.17.1
Describe the goal of the feature
The goal is to enable the Datadog Continuous Profiler for Python applications running under a uWSGI pre-fork model.
We specifically use this configuration to maintain an optimized, low memory footprint, which is critical for our service deployment strategy. Enabling the profiler in this environment would allow us to analyze CPU and memory performance in our production configuration which would be great.
Is your feature request related to a problem?
Yes. The problem is that the Datadog Profilercurrently requires specific uWSGI configuration flags that conflict with our optimal memory model and led to instability when attempted.
https://ddtrace.readthedocs.io/en/stable/advanced_usage.html#uwsgi
Specifically, the current documentation states that ddtrace only supports uWSGI when configured with:
- Lazy apps must be enabled (lazy-apps).
When we initially attempted to enable the profiler in our pre-fork model (without having checked the docs), we experienced random segfaults during master process shutdown, forcing us to disable the profiler feature immediately to maintain stability.
Describe alternatives you've considered
- Using the officially supported configuration (threads and lazy-apps): This is not a viable alternative as it significantly increases the memory footprint per worker process, negating our primary optimization strategy. Our architectural decision is based on running workers with this pre-fork model to keep memory usage minimal.
- Disabling Profiler: What we've currently done. Which means we are unable to leverage the feature for performance optimization and debugging.
Additional context
I'd like to to understand the technical limitations preventing the profiler from supporting the standard uWSGI pre-fork model.
-
Why is the Profiler not supported in the pre-fork model? Is this an architectural limitation of the native profiling components (e.g., Signal handling, GIL interaction)?
-
What are the primary risks associated with forcing the profiler on in this environment (beyond the segfaults we already observed)?
-
Are there any known workarounds or beta features we could test to utilize the profiler without having to enable lazy-apps?
I guess depending on my understanding of the above ^. Can support for this uwsgi set up be added as a feature? Given the popularity of uWSGI's pre-fork, minimal-memory configuration in Python services, this would significantly increase the utility of the Datadog Profiler for a large segment of users.