Trabajadores multiplex (función experimental)

Informar un problema Ver fuente

En esta página, se describen los trabajadores multiplex, cómo escribir reglas compatibles con multiplex y soluciones alternativas para ciertas limitaciones.

Los trabajadores multiplex permiten que Bazel maneje múltiples solicitudes con un solo proceso de trabajador. En el caso de los trabajadores con varios subprocesos, Bazel puede usar menos recursos para lograr el mismo rendimiento o uno mejor. Por ejemplo, en lugar de tener un proceso de trabajador por trabajador, Bazel puede tener cuatro trabajadores multiplexados que hablan con el mismo proceso de trabajador, que puede manejar solicitudes en paralelo. Para lenguajes como Java y Scala, ahorra tiempo de preparación de JVM y tiempo de compilación de JIT y, en general, permite usar una caché compartida entre todos los trabajadores del mismo tipo.

Descripción general

Hay dos capas entre el servidor de Bazel y el proceso trabajador. Para ciertos mnemónicos que pueden ejecutar procesos en paralelo, Bazel obtiene un WorkerProxy del grupo de trabajadores. WorkerProxy reenvía solicitudes al proceso trabajador de forma secuencial junto con un request_id; el proceso de trabajo procesa la solicitud y envía respuestas a WorkerMultiplexer. Cuando WorkerMultiplexer recibe una respuesta, analiza el request_id y, luego, reenvía las respuestas a la WorkerProxy correcta. Al igual que con los trabajadores no multiplexados, toda la comunicación se realiza a través de entrada y salida estándar, pero la herramienta no puede usar solo stderr para la salida visible para el usuario (consulta a continuación).

Cada trabajador tiene una clave. Bazel usa el código hash de la clave (compuesto por variables de entorno, la raíz de ejecución y el valor mnemotécnico) para determinar qué WorkerMultiplexer usar. Las WorkerProxy se comunican con la misma WorkerMultiplexer si tienen el mismo código hash. Por lo tanto, si las variables de entorno y la raíz de ejecución son las mismas en una sola invocación de Bazel, cada valor mnemotécnico único solo puede tener un proceso de WorkerMultiplexer y un trabajador. La cantidad total de trabajadores, incluidos los trabajadores normales y WorkerProxy, sigue limitada por --worker_max_instances.

Escribe reglas compatibles con multiplex

El proceso de trabajador de la regla debe ser multiproceso para aprovechar los trabajadores multiplex. Protobuf permite que un conjunto de reglas analice una sola solicitud, aunque pueda haber varias solicitudes apiladas en la transmisión. Cada vez que el proceso de trabajo analiza una solicitud desde la transmisión, debe controlar la solicitud en un subproceso nuevo. Debido a que diferentes subprocesos podrían completarse y escribirse en la transmisión al mismo tiempo, el proceso de trabajo debe asegurarse de que las respuestas se escriban de forma atómica (los mensajes no se superponen). Las respuestas deben contener el request_id de la solicitud que controlan.

Cómo administrar los resultados multiplex

Los trabajadores multiplex deben tener más cuidado a la hora de manejar sus resultados que los trabajadores de un soloplex. Todo lo que se envía a stderr irá a un solo archivo de registro compartido entre todas las WorkerProxy del mismo tipo, intercalados de forma aleatoria entre las solicitudes simultáneas. Si bien redireccionar stdout a stderr es una buena idea, no recopiles ese resultado en el campo output de WorkResponse, ya que esto podría mostrarle al usuario fragmentos alterados de resultado. Si tu herramienta solo envía resultados orientados al usuario a stdout o stderr, deberás cambiar ese comportamiento para poder habilitar los trabajadores multiplex.

Habilitación de trabajadores multiplex

Los trabajadores multiplex no están habilitados de forma predeterminada. Un conjunto de reglas puede activar trabajadores multiplex con la etiqueta supports-multiplex-workers en el execution_requirements de una acción (al igual que la etiqueta supports-workers habilita trabajadores normales). Al igual que cuando se usan trabajadores normales, se debe especificar una estrategia de trabajadores a nivel del conjunto de reglas (por ejemplo, --strategy=[some_mnemonic]=worker) o, en general, a nivel de la estrategia (por ejemplo, --dynamic_local_strategy=worker,standalone). No se necesitan marcas adicionales, y supports-multiplex-workers tiene prioridad sobre supports-workers, si ambas están configuradas. Para desactivar los trabajadores multiplex de forma global, pasa --noworker_multiplex.

Se recomienda que un conjunto de reglas use trabajadores multiplex si es posible para reducir la presión de la memoria y mejorar el rendimiento. Sin embargo, en la actualidad, los trabajadores multiplex no son compatibles con la ejecución dinámica, a menos que implementen la zona de pruebas de multiplex. Si se intenta ejecutar trabajadores multiplex que no están en zona de pruebas con ejecución dinámica, se usarán, en silencio, trabajadores de un soloplex de zona de pruebas.

Zona de pruebas de multiplex

Los trabajadores multiplex se pueden poner en zona de pruebas agregándole compatibilidad explícita en las implementaciones de trabajadores. Si bien la zona de pruebas para trabajadores de un soloplex se puede realizar ejecutando cada proceso de trabajador en su propia zona de pruebas, los trabajadores multiplex comparten el directorio de trabajo del proceso entre varias solicitudes paralelas. Para permitir la zona de pruebas de los trabajadores multiplex, el trabajador debe admitir la lectura y escritura en un subdirectorio especificado en cada solicitud, en lugar de hacerlo directamente en su directorio de trabajo.

Para admitir la zona de pruebas multiplex, el trabajador debe usar el campo sandbox_dir de WorkRequest y usarlo como prefijo para todas las operaciones de lectura y escritura de archivos. Si bien los campos arguments y inputs no se modifican de una solicitud no zona de pruebas, las entradas reales son relativas a sandbox_dir. El trabajador debe traducir las rutas de los archivos que se encuentran en arguments y inputs para leer desde esta ruta de acceso modificada y también debe escribir todos los resultados relacionados con sandbox_dir. Esto incluye rutas de acceso como “.”, así como rutas de acceso que se encuentran en archivos especificados en los argumentos (como los argumentos "argfile").

Una vez que un trabajador admite la zona de pruebas multiplex, el conjunto de reglas puede declarar esta compatibilidad agregando supports-multiplex-sandboxing al execution_requirements de una acción. Luego, Bazel usará la zona de pruebas multiplex si se pasa la marca --experimental_worker_multiplex_sandboxing o si el trabajador se usa con ejecución dinámica.

Los archivos de trabajador de un trabajador multiplex de zona de pruebas aún están relacionados con el directorio de trabajo del proceso de trabajador. Por lo tanto, si un archivo se usa para ejecutar el trabajador y como entrada, se debe especificar como entrada en el argumento del archivo indicador y en tools, executable o runfiles.