Ray backend creates per-worker venvs that fill disk and crash with concurrent experiments
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 22/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- ai-infra-agents, distributed-systems
Hướng nghiên cứu
Start in agentlab/experiments/launch_exp.py around line 85, where ray.init(num_cpus=n_jobs) runs, and check how the working directory and pyproject.toml get packaged into worker runtime_env. Then look at the cleanup around ray.shutdown() near line 89. Done means the Ray temp directory is removed after each run and concurrent launches no longer each build a full venv, which needs a test or a reproduction with multiple Study.run() calls. The issue lists several competing fixes, so a maintainer decision on the approach is needed first.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
When using parallel_backend="ray" (the default), Ray auto-packages the working directory and creates a fresh virtual environment per worker in a temporary directory. For projects with heavy dependencies (e.g., PyTorch ~12GB), this causes:
- Disk exhaustion: Each Ray cluster creates a full venv copy (~12GB+). With 4-10 concurrent experiments, this can consume 50-120GB+ in
/tmp, filling the root partition. - Worker startup hangs: Workers hang during
uv sync/pip installin the temp venv, producing repeatedworker_pool.cc: Some workers of the worker process have not registered within the timeouterrors. - GCS crashes: When too many clusters compete for resources, Ray's GCS (Global Control Store) becomes unresponsive, causing
Failed to connect to GCS within 60 secondsand terminating experiments. - AF_UNIX socket path limit: If the temp directory path is long (e.g., a scratch filesystem), the Unix socket path exceeds the 107-byte limit, causing
OSError: AF_UNIX path length cannot exceed 107 bytes.
Reproduction
- Have a project with
pyproject.tomlthat depends on PyTorch (or similar large packages) - Launch 3+ concurrent
Study.run()calls withparallel_backend="ray"(default) - Observe
/tmpfilling up withray_*directories, each containing a full venv
Root Cause
In agentlab/experiments/launch_exp.py:85:
ray.init(num_cpus=n_jobs)
This bare ray.init() causes Ray to auto-detect the working directory (which contains pyproject.toml) and package it for workers. Each worker then runs uv sync to create a fresh venv in the Ray temp directory, re-installing all dependencies from scratch.
Key behaviors:
- Ray creates a new temp directory per
ray.init()call (each experiment gets its own cluster) - Each cluster's workers build an independent venv copy
- Failed/completed experiments leave their temp directories behind (no cleanup)
ray.shutdown()inlaunch_exp.py:89does not clean up the temp directory
Impact
- Experiments silently fail with
ENOSPCerrors (Playwright can't create browser profiles when disk is full) - Hundreds of tasks get recorded as errors that are actually disk-full failures, requiring full reruns
- The problem compounds: each relaunch creates additional temp directories
Workaround
Using parallel_backend="joblib" avoids Ray entirely and doesn't have this issue. However, joblib doesn't support Ray's task graph execution (dependency tracking between tasks).
Another workaround is to set RAY_TMPDIR to a large filesystem and create isolated Ray temp dirs there, but this hits the AF_UNIX 107-byte socket path limit if the path is too long.
Suggested Fix
- Disable Ray's auto-packaging by setting
runtime_env={"worker_process_setup_hook": ...}orRAY_RUNTIME_ENV_HOOKto prevent venv creation in workers - Or pass
runtime_env={"py_modules": [...]}with only the necessary module instead of the full working directory - Or set
ray.init(runtime_env={"working_dir": None})to prevent auto-packaging - Add temp directory cleanup in the
finallyblock afterray.shutdown()-- clean up the Ray temp directory
Environment
- AgentLab v0.4.0
- Ray 2.51.1
- Python 3.12
- Ubuntu 22.04
- Dependencies include PyTorch 2.8.0 (~12GB installed)
- Ngôn ngữ chính
- Python
- Star
- 644
- Fork
- 134
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ServiceNow/AgentLab
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
ServiceNow/AgentLab#340 ·
-
Availability and use terms for minimized HTTP traces linked to recorded agent configurationsĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
ServiceNow/AgentLab#339 ·
-
Qwen3 IntegrationĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
ServiceNow/AgentLab#329 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 25/100
ServiceNow/AgentLab#324 · 2 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
ServiceNow/AgentLab#323 ·
Tất cả issue của ServiceNow/AgentLab
Issue tương tự
-
PAC Wording
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Harmony OPeNDAP SubSetter (HOSS) Geographic production rssmif16d 7 XYZ_PROV
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
nasa/harmony-autotester#372 ·
-
Add DomainĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
disposable/disposable#318 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
developmentseed/titiler-cmr#270 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Chart: a failed venv install is marked ready, and the 10Gi venv PVC is too small for itCó thể đã có người làm @andyne13 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày