Using uWSGI lazy-apps to cut worker memory footprint
Learn how enabling lazy-apps defers Python import until the first request, reducing per‑worker RSS and when to watch out for fork‑unsafe code.
Loading…
ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Learn how enabling lazy-apps defers Python import until the first request, reducing per‑worker RSS and when to watch out for fork‑unsafe code.
I am tuning a uWSGI 2.0.x deployment that uses the cheaper algorithm to scale workers dynamically between a minimum and maximum count. I want to enable lazy-apps so each worker loads the application after forking, reducing shared memory and allowing the master to start before the app is loaded. The uncertainty is how these two features interact. With lazy-ap
Goal Determine how uWSGI's graceful reload (SIGUSR1 or touch‑reload) coordinates with --lazy-apps when workers are recycled, specifically whether a deterministic shutdown order can be enforced to avoid version skew across workers. Constraints and uncertainty Graceful reload waits for active requests but does not define a worker shutdown sequence. --lazy-apps
python
uwsgi