ReactionMechanismGenerator / ReactionMechanismGenerator/ARC

Local pipe: concurrent arrays oversubscribe the CPU budget (stateless local_worker_limit)

Open
#961 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
51
Forks
25
Avg merge
4d 5h
Merged PRs (30d)
15

Description

Summary

local_worker_limit() (arc/job/pipe/pipe_run.py) decides how many pipe workers may run
concurrently, but it is stateless across pipe arrays: it derives the count from the full
machine-wide CPU/memory budget on every call, with no accounting of workers already running from
other concurrent arrays. When ARC runs more than one local pipe array at a time, the combined
worker count can exceed the configured budget.

Details

The limit is computed as:

by_cores = local_cpu_budget() // max(1, int(cpus_per_worker))
# ... further capped by available memory ...

local_cpu_budget() returns the server's cpus (the machine-wide budget) fresh on each call.
Each pipe array is a separate process/invocation, so there is no shared in-process state to
consult — every array computes its limit as if it were the only one running.

Example

Budget = 20 cores, 5 cores/worker. Three concurrent arrays (e.g. an sp batch, a freq batch,
and a ts batch) each derive 20 // 5 = 4 workers → 12 workers = 60 cores requested against a
20-core budget
. The budget bounds workers within one array but not across concurrent arrays.

Root cause

The derivation has no cross-process view of currently-running workers. A single-process semaphore
would not help, because the arrays are independent processes with no shared in-memory counter.

Proposed fix

Cross-process coordination that all local arrays consult before spawning a worker — e.g. an
on-disk/lock-file token bucket keyed to the CPU budget, or a lightweight local scheduler. Each
array acquires tokens for the cores it takes and releases them as workers finish, so the machine
never exceeds the configured budget regardless of how many arrays run.

Workaround

Set pipe_settings['local_max_workers'] to cap the derived value manually when running concurrent
arrays.

References
  • PR #924 (PySCF in-core adapter / local pipe backend) — review thread by @calvinp0 that surfaced this.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in arc/job/pipe/pipe_run.py with local_worker_limit() and local_cpu_budget(), then trace how local pipe arrays spawn workers. The fix is complete when concurrent arrays coordinate across processes so acquired worker resources never exceed the configured CPU budget and are released as workers finish; review the local_max_workers workaround for compatibility.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, distributed-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.