Skip to content

[9.1] fix: create the RequestExecutingAgent ProcessPool in initialize - #8766

Draft
chrisburr wants to merge 1 commit into
DIRACGrid:integrationfrom
chrisburr:fix/rea-processpool-fork-before-requests
Draft

[9.1] fix: create the RequestExecutingAgent ProcessPool in initialize#8766
chrisburr wants to merge 1 commit into
DIRACGrid:integrationfrom
chrisburr:fix/rea-processpool-fork-before-requests

Conversation

@chrisburr

Copy link
Copy Markdown
Member

Fork the REA process pool earlier in the agent process to avoid wasting as much memory on each subprocess.

BEGINRELEASENOTES

*RequestManagemet
FIX: Reduce memory usage of RequestExecutingAgent

ENDRELEASENOTES

ProcessPool was built lazily on the first processPool() call, which happens
inside execute(), after getBulkRequests() has already loaded a whole
BulkRequest into memory. All MinProcess workers are forked at that instant,
and because a worker never unwinds the frame it was forked from, every one
of them pins that cycle's Requests for the lifetime of the agent.

A core dump of one worker from a 60-process pool running BulkRequest=3000
still held the parent's requestsToExecute list and getRequests dict:
3003 Request, 3764 Operation and 40973 File objects, 54.8 MiB of live data
in a process that only ever handles one request at a time.

Creating the pool at the end of initialize() forks from the main thread
before any request is fetched, and keeps the RequestDB engine out of the
workers as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant