Set default --max-requests for API workers to prevent unbounded RSS growth

[amasolov]

Summary

• Set max_requests=10000 and max_requests_jitter=500 as defaults for API workers
• Workers are gracefully recycled after ~10,000 requests, resetting accumulated glibc heap fragmentation
• Defaults only apply when max_requests has not been explicitly configured (via CLI, config file, or GUNICORN_CMD_ARGS)

Context

Follow-up from the discussion in #7481 where @ggainey and @dralley agreed that setting sensible --max-requests defaults is the right approach. See #7482 for the full profiling data showing ~1 kB/request RSS growth from glibc heap fragmentation under normal Django ORM workload.

Implementation note

The defaults are set in PulpcoreApiApplication.load_app_specific_config() rather than as click option defaults to preserve the config precedence chain: if a user has already configured max_requests via a config file, GUNICORN_CMD_ARGS, or CLI flag, their value is respected and not overridden.

Test plan

• Verify workers restart after ~10,000 requests (check gunicorn logs for worker boot messages)
• Verify --max-requests 0 on CLI disables recycling
• Verify GUNICORN_CMD_ARGS="--max-requests 5000" overrides the default
• Verify existing test suite passes

📜 Checklist

• Commits are cleanly separated with meaningful messages (simple features and bug fixes should be squashed to one commit)
• A changelog entry or entries has been added for any significant changes
• Follows the Pulp policy on AI Usage
• (For new features) - User documentation and test coverage has been added

See: Pull Request Walkthrough

Made with Cursor

[dralley]

The comment describes disabling recycling by setting --max-requests 0, but it would seem like this would explicitly use the defaults in that scenario. Am I missing something?

[dralley]

@amasolov

[amasolov]

@dralley Good catch - I had that backwards in the first version.

Gunicorn already uses max_requests == 0 for "no recycling", and I was treating any 0 as "use our defaults", which would have stomped on someone who explicitly passes --max-requests 0 to turn recycling off.

I’ve changed it so we only apply the 10000/500 defaults when --max-requests wasn’t passed on the pulpcore-api CLI (None in the click options). If you pass --max-requests 0, we leave it alone. Updated the architecture note to say the same thing.

Latest push is one squashed commit with that fix.