[feat] Make the CPU reservation of the controller and SimpleStorageUnit configurable

Abierto Apto para principiantes
  • ¿Algo no está bien?
#207 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
performance

Línea de trabajo

Dos sitios de llamada definen los actors: transfer_queue/controller.py alrededor de la línea 1107 y transfer_queue/storage/simple_storage.py alrededor de la línea 900, ambos actualmente @ray.remote(num_cpus=1). Léelos junto con TransferQueueLockManager, que ya usa num_cpus=0, luego lee las dos variables de entorno y pasa el valor mediante .options(num_cpus=...) en las llamadas .remote(), con valor predeterminado 1 cuando no estén definidas. Terminado se ve como una prueba que construye los actors y verifica su num_cpus solicitado, además de ningún cambio de comportamiento cuando las variables están ausentes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

TransferQueueController and SimpleStorageUnit are declared with @ray.remote(num_cpus=1) (controller.py#L1107, simple_storage.py#L900), so each one reserves a full CPU for as long as it lives. A framework that starts a controller and several storage units per job reserves that many CPUs per job before any training work runs. verl's v1 trainer starts one controller and 8 storage units by default, so 9 CPUs per job (see verl#7398, where a 16-CPU Ray cluster was left with 7 CPUs after the units came up). When jobs queue for a GPU, their TransferQueue actors already hold CPUs and can keep the jobs ahead of them from being scheduled; #164 is the same pressure showing up as a startup hang.

The reservation is far above the usage. One local Ray 2.57.0 run (torch 2.13.0, Python 3.12) with 8 storage units, 126 kv_put calls per second of two small fields plus a kv_list per batch, for 30 seconds, measured through psutil CPU times of the actor processes:

controller    0.148 cores (average)
8 units       0.012 cores each (average)

TransferQueueLockManager is already num_cpus=0, so a zero reservation for these actors is not a new pattern here.

Proposal

Read the CPU request from environment variables, TQ_CONTROLLER_NUM_CPUS and TQ_STORAGE_UNIT_NUM_CPUS, and pass it through .options(num_cpus=...) where the actors are created. Keep the default at 1 so nothing changes for existing users. I can send a PR with a test that checks the requested resources of the created actors.

Not covered

The numbers above come from a small local loop, not from a training run, so they show the order of magnitude and not the load of a real job.

Lenguaje dominante
Python
Estrellas
169
Forks
56
Merge medio
1 d 17 h
PR fusionados (30 d)
15

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Ascend/TransferQueue

Todos los issues de Ascend/TransferQueue

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.