Solución de problemas de ParallelRunStep
SE APLICA A: SDK de Python azureml v1
En este artículo aprenderá a solucionar los errores que se producen al usar la clase ParallelRunStep con el SDK de Azure Machine Learning.
Para obtener sugerencias generales sobre la solución de problemas de una canalización, consulte Solución de problemas de canalizaciones de aprendizaje automático.
Prueba de scripts de forma local
La clase ParallelRunStep se ejecuta como un paso de las canalizaciones de Machine Learning. Es posible que desee probar los scripts localmente como primer paso.
Requisitos del script de entrada
El script de entrada de una clase ParallelRunStep
debe contener una función run()
y contiene, opcionalmente, una función init()
:
init()
: utilice esta función en preparaciones costosas o comunes para el procesamiento posterior. Por ejemplo, para cargar el modelo en un objeto global. Solo se llamará a esta función una vez al principio del proceso.Nota
Si el método
init
crea un directorio de salida, especifique queparents=True
yexist_ok=True
. Al métodoinit
se le llama desde cada proceso de trabajo en cada nodo en el que se ejecuta el trabajo.run(mini_batch)
: la función se ejecutará para cada instancia demini_batch
.mini_batch
:ParallelRunStep
invocará el método run y pasará una lista oDataFrame
de Pandas como argumento al método. Cada entrada de mini_batch será una ruta de acceso de archivo si la entrada esFileDataset
, oDataFrame
de Pandas si la entrada esTabularDataset
.response
: El método run() debe devolverDataFrame
de Pandas o una matriz. Para append_row output_action, estos elementos devueltos se anexan al archivo de salida común. Para summary_only, se omite el contenido de los elementos. Para todas las acciones de salida, cada elemento de salida devuelto indica una ejecución correcta del elemento de entrada en el minilote de entrada. Asegúrese de que se incluyen suficientes datos en el resultado de la ejecución para asignar la entrada al resultado de la salida de la ejecución. La salida de la ejecución se escribirá en el archivo de salida y no se garantiza que esté en orden, por lo que debe usar alguna clave en la salida para asignarla a la entrada.Nota
Se espera un elemento de salida para un elemento de entrada.
%%writefile digit_identification.py
# Snippets from a sample script.
# Refer to the accompanying digit_identification.py
# (https://github.com/Azure/MachineLearningNotebooks/tree/master/how-to-use-azureml/machine-learning-pipelines/parallel-run)
# for the implementation script.
import os
import numpy as np
import tensorflow as tf
from PIL import Image
from azureml.core import Model
def init():
global g_tf_sess
# Pull down the model from the workspace
model_path = Model.get_model_path("mnist")
# Construct a graph to execute
tf.reset_default_graph()
saver = tf.train.import_meta_graph(os.path.join(model_path, 'mnist-tf.model.meta'))
g_tf_sess = tf.Session()
saver.restore(g_tf_sess, os.path.join(model_path, 'mnist-tf.model'))
def run(mini_batch):
print(f'run method start: {__file__}, run({mini_batch})')
resultList = []
in_tensor = g_tf_sess.graph.get_tensor_by_name("network/X:0")
output = g_tf_sess.graph.get_tensor_by_name("network/output/MatMul:0")
for image in mini_batch:
# Prepare each image
data = Image.open(image)
np_im = np.array(data).reshape((1, 784))
# Perform inference
inference_result = output.eval(feed_dict={in_tensor: np_im}, session=g_tf_sess)
# Find the best probability, and add it to the result list
best_result = np.argmax(inference_result)
resultList.append("{}: {}".format(os.path.basename(image), best_result))
return resultList
Si tiene otro archivo o carpeta en el mismo directorio que el script de inferencia, puede hacer referencia a él buscando el directorio de trabajo actual. Si desea importar los paquetes, también puede anexar la carpeta del paquete a sys.path
.
script_dir = os.path.realpath(os.path.join(__file__, '..',))
file_path = os.path.join(script_dir, "<file_name>")
packages_dir = os.path.join(file_path, '<your_package_folder>')
if packages_dir not in sys.path:
sys.path.append(packages_dir)
from <your_package> import <your_class>
Parámetros para ParallelRunConfig
ParallelRunConfig
es la configuración principal de la instancia de ParallelRunStep
dentro de la canalización de Azure Machine Learning. Se usa para encapsular el script y configurar los parámetros necesarios, incluidos los de las siguientes entradas:
entry_script
: script de usuario como ruta de acceso de archivo local que se ejecutará en paralelo en varios nodos. Sisource_directory
está presente, utilice una ruta de acceso relativa. De lo contrario, use cualquier ruta de acceso accesible desde la máquina.mini_batch_size
: tamaño del minilote que se pasa a una sola llamada derun()
. (Opcional; el valor predeterminado es10
archivos paraFileDataset
, y1MB
paraTabularDataset
).- En el caso de
FileDataset
, es el número de archivos con un valor mínimo de1
. Puede combinar varios archivos en un solo minilote. - En el caso de
TabularDataset
, es el tamaño de los datos. Los valores posibles son1024
,1024KB
,10MB
y1GB
.1MB
es el valor recomendado. El minilote deTabularDataset
nunca cruzará los límites de los archivos. Por ejemplo, si tiene archivos. csv de varios tamaños, el menor es de 100 KB y el mayor es de 10 MB. Si establecemini_batch_size = 1MB
, los archivos con un tamaño menor que 1 MB se tratarán como un solo minilote. Los archivos de tamaño mayor que 1 MB se dividirán en varios minilotes.Nota
TabularDatasets respaldados por SQL no se pueden particionar. Los valores de TabularDataset de un único archivo Parquet y un único grupo de filas no se pueden particionar.
- En el caso de
error_threshold
: número de errores de registro paraTabularDataset
y errores de archivo paraFileDataset
que se deben omitir durante el procesamiento. Si el recuento de errores de la entrada supera este valor, el trabajo se anulará. El umbral de error es para toda la entrada y no para los minilotes individuales que se envían al métodorun()
. El intervalo es[-1, int.max]
. La parte-1
indica que se omitirán todos los errores durante el procesamiento.output_action
: uno de los valores siguientes indica cómo se organizará la salida:summary_only
: el script de usuario almacenará la salida.ParallelRunStep
usará la salida solo para el cálculo del umbral de error.append_row
: en las entradas, solo se creará un archivo en la carpeta de salida para anexar todas las salidas separadas por líneas.
append_row_file_name
: para personalizar el nombre del archivo de salida de append_row output_action (opcional; el valor predeterminado esparallel_run_step.txt
).source_directory
: rutas de acceso a las carpetas que contienen todos los archivos que se van a ejecutar en el destino de proceso (opcional).compute_target
: Solo se admiteAmlCompute
.node_count
: número de nodos de proceso que se usarán para ejecutar el script de usuario.process_count_per_node
: número de procesos de trabajo por nodo para ejecutar el script de entrada en paralelo. En el caso de una máquina de GPU, el valor predeterminado es 1. En una máquina de CPU, el valor predeterminado es el número de núcleos por nodo. Un proceso de trabajo llamará repetidamente arun()
pasando el lote de pequeño tamaño que obtiene. El número total de procesos de trabajo del trabajo esprocess_count_per_node * node_count
, que decide el número máximo derun()
que se van a ejecutar en paralelo.environment
: definición del entorno de Python. Puede configurarla para usar un entorno de Python existente o un entorno temporal. La definición también es responsable de establecer las dependencias de la aplicación necesarias (opcional).logging_level
: nivel de detalle del registro. Los valores con nivel de detalle en aumento son:WARNING
,INFO
yDEBUG
. (Opcional; el valor predeterminado esINFO
).run_invocation_timeout
: tiempo de espera de invocación del métodorun()
en segundos. (Opcional; el valor predeterminado es60
).run_max_try
: número máximo de intentos derun()
para un minilote. Se produce un error enrun()
si se genera una excepción o no se devuelve nada cuando se alcanzarun_invocation_timeout
(opcional; el valor predeterminado es3
).
Puede especificar mini_batch_size
, node_count
, process_count_per_node
, logging_level
, run_invocation_timeout
y run_max_try
como PipelineParameter
, de modo que, cuando vuelva a enviar una ejecución de la canalización, pueda optimizar los valores de los parámetros. En este ejemplo, se usa PipelineParameter
para mini_batch_size
y Process_count_per_node
, y se cambiarán estos valores cuando se vuelva a enviar otra ejecución.
Visibilidad de dispositivos CUDA
Para los destinos de proceso equipados con GPU, la variable de entorno CUDA_VISIBLE_DEVICES
se establecerá en los procesos de trabajo. En AmlCompute, puede encontrar el número total de dispositivos GPU en la variable de entorno AZ_BATCHAI_GPU_COUNT_FOUND
, que se establece automáticamente. Si quiere que cada proceso de trabajo tenga una GPU dedicada, establezca process_count_per_node
en un valor igual al número de dispositivos GPU de una máquina. Cada proceso de trabajo asignará un índice único a CUDA_VISIBLE_DEVICES
. Si un proceso de trabajo se detiene por cualquier motivo, el siguiente proceso de trabajo iniciado usará el índice de GPU publicado.
Si el número total de dispositivos GPU es inferior a process_count_per_node
, a los procesos de trabajo se les asignará un índice de GPU hasta que se hayan usado todos.
Dado que el número total de dispositivos GPU es 2 y process_count_per_node = 4
, como ejemplo, el proceso 0 y el proceso 1 tendrán el índice 0 y 1. Los procesos 2 y 3 no tendrán una variable de entorno. Si una biblioteca usa esta variable de entorno para la asignación de GPU, los procesos 2 y 3 no tendrán GPU y no intentarán adquirir dispositivos de GPU. Si el proceso 0 se detiene, se liberará el índice 0 de GPU. El siguiente proceso, que es el proceso 4, tendrá asignado el índice 0 de GPU.
Para más información, consulte CUDA Pro Tip: Control de la visibilidad de GPU con CUDA_VISIBLE_DEVICES.
Parámetros para crear ParallelRunStep
Cree ParallelRunStep mediante el script, la configuración del entorno y los parámetros. Especifique el destino de proceso que ya adjuntó a su área de trabajo como destino de ejecución del script de inferencia. Use ParallelRunStep
para crear el paso de canalización de inferencias por lotes, que toma todos los parámetros siguientes:
name
: el nombre del paso, con las siguientes restricciones de nomenclatura: unique, 3-32 caracteres y regex ^[a-z]([-a-z0-9]*[a-z0-9])?$.parallel_run_config
: objetoParallelRunConfig
, tal y como se definió anteriormente.inputs
: uno o varios conjuntos de datos de Azure Machine Learning de tipo único que se van a particionar para el procesamiento en paralelo.side_inputs
: uno o varios datos de referencia o conjuntos de datos que se usan como entradas laterales sin necesidad de crear particiones.output
: un objetoOutputFileDatasetConfig
que representa la ruta de acceso al directorio en el que se almacenarán los datos de salida.arguments
: lista de los argumentos pasados al script de usuario. Use unknown_args para recuperarlos en el script de entrada (opcional).allow_reuse
: sirve para decidir si el paso debe volver a usar los resultados anteriores cuando se ejecuta con la misma configuración o entrada. Si este parámetro esFalse
, siempre se generará una nueva ejecución para este paso durante la ejecución de la canalización. (Opcional; el valor predeterminado esTrue
).
from azureml.pipeline.steps import ParallelRunStep
parallelrun_step = ParallelRunStep(
name="predict-digits-mnist",
parallel_run_config=parallel_run_config,
inputs=[input_mnist_ds_consumption],
output=output_dir,
allow_reuse=True
)
Depuración de scripts desde un contexto remoto
La transición de la depuración de un script de puntuación de forma local, a la depuración de un script de puntuación en una canalización real puede resultar difícil. Para información sobre cómo buscar los registros en el portal, consulte la sección de canalizaciones de aprendizaje automático en la depuración de scripts desde un contexto remoto. La información de esa sección también se aplica a ParallelRunStep.
Por ejemplo, el archivo de registro 70_driver_log.txt
contiene información del controlador que inicia el código de ParallelRunStep.
Dada la naturaleza distribuida de los trabajos de ParallelRunStep, hay registros de distintos orígenes. Sin embargo, se crean dos archivos consolidados que proporcionan información de alto nivel:
~/logs/job_progress_overview.txt
: Este archivo proporciona información de alto nivel sobre el número de minilotes (también conocidos como tareas) que se han creado hasta el momento y el número de minilotes que se han procesado hasta ahora. En este extremo, se muestra el resultado del trabajo. Si se produjo un error en el trabajo, se mostrará el mensaje de error y dónde se debe iniciar la solución de problemas.~/logs/sys/master_role.txt
: Este archivo proporciona la vista del nodo principal (también conocido como orquestador) del trabajo en ejecución. Incluye la creación de tareas, la supervisión del progreso y el resultado de la ejecución.
Los registros generados a partir del script de entrada mediante el asistente EntryScript y las instrucciones print se encuentran en los siguientes archivos:
~/logs/user/entry_script_log/<node_id>/<process_name>.log.txt
: estos archivos son los registros escritos desde entry_script con el asistente EntryScript.~/logs/user/stdout/<node_id>/<process_name>.stdout.txt
: estos archivos son los registros de stdout (por ejemplo, la instrucción print) de entry_script.~/logs/user/stderr/<node_id>/<process_name>.stderr.txt
: estos archivos son los registros de stderr de entry_script.
Para obtener una descripción concisa de los errores del script, hay lo siguiente:
~/logs/user/error.txt
: este archivo intentará resumir los errores del script.
Para obtener más información sobre los errores del script, hay lo siguiente:
~/logs/user/error/
: contiene seguimientos de pila completos de las excepciones producidas al cargar y ejecutar el script de entrada.
Cuando necesite comprender en detalle cómo ejecuta cada nodo el script de puntuación, examine los registros de proceso individuales para cada nodo. Los registros de proceso se pueden encontrar en la carpeta sys/node
, agrupados por nodos de trabajo:
~/logs/sys/node/<node_id>/<process_name>.txt
: este archivo proporciona información detallada sobre cada uno de los minilotes a medida que un trabajo lo elige o lo completa. Para cada minilote, este archivo incluye:- La dirección IP y el PID del proceso de trabajo.
- El número total de elementos, el número de elementos procesados correctamente y el número de elementos con errores.
- Hora de inicio, duración, tiempo de proceso y tiempo del método de ejecución.
También puede ver los resultados de las comprobaciones periódicas del uso de recursos de cada nodo. Los archivos de registro y los archivos de configuración se encuentran en esta carpeta:
~/logs/perf
: establezca--resource_monitor_interval
para cambiar el intervalo de comprobación en segundos. El intervalo predeterminado es600
, que son aproximadamente 10 minutos. Para detener la supervisión, establezca el valor en0
. Cada carpeta<node_id>
incluye:os/
: información acerca de todos los procesos en ejecución en el nodo. Una comprobación ejecuta un comando del sistema operativo y guarda el resultado en un archivo. En Linux, el comando esps
. Para Windows, usetasklist
.%Y%m%d%H
: el nombre de la subcarpeta es la fecha y hora.processes_%M
: el archivo finaliza con el minuto de la hora de la comprobación.
node_disk_usage.csv
: detalles de uso del disco del nodo.node_resource_usage.csv
: información general sobre el uso de recursos del nodo.processes_resource_usage.csv
: información general sobre el uso de recursos de cada proceso.
¿Cómo me puedo registrar desde mi script de usuario en un contexto remoto?
ParallelRunStep puede ejecutar varios procesos en un nodo basado en process_count_per_node. Para organizar los registros de cada proceso en el nodo y combinar las instrucciones print y log, se recomienda usar el registrador ParallelRunStep como se muestra a continuación. Puede obtener un registrador de EntryScript, y hacer que los registros aparezcan en la carpeta logs/user del portal.
Uso del registrador por un script de entrada de ejemplo:
from azureml_user.parallel_run import EntryScript
def init():
"""Init once in a worker process."""
entry_script = EntryScript()
logger = entry_script.logger
logger.info("This will show up in files under logs/user on the Azure portal.")
def run(mini_batch):
"""Call once for a mini batch. Accept and return the list back."""
# This class is in singleton pattern and will return same instance as the one in init()
entry_script = EntryScript()
logger = entry_script.logger
logger.info(f"{__file__}: {mini_batch}.")
...
return mini_batch
¿Dónde se recibe el mensaje logging
de Python?
ParallelRunStep establece un controlador en el registrador raíz, que recibe el mensaje en logs/user/stdout/<node_id>/processNNN.stdout.txt
.
El valor predeterminado de logging
es el nivel INFO
. De manera predeterminada, los niveles por debajo de INFO
no se mostrarán, como DEBUG
.
¿Cómo puedo escribir en un archivo para que aparezca en el portal?
Los archivos de la carpeta logs
se cargarán y se mostrarán en el portal.
Puede obtener la carpeta logs/user/entry_script_log/<node_id>
como se muestra a continuación y crear la ruta de acceso del archivo para escribir:
from pathlib import Path
from azureml_user.parallel_run import EntryScript
def init():
"""Init once in a worker process."""
entry_script = EntryScript()
log_dir = entry_script.log_dir
log_dir = Path(entry_script.log_dir) # logs/user/entry_script_log/<node_id>/.
log_dir.mkdir(parents=True, exist_ok=True) # Create the folder if not existing.
proc_name = entry_script.agent_name # The process name in pattern "processNNN".
fil_path = log_dir / f"{proc_name}_<file_name>" # Avoid conflicting among worker processes with proc_name.
¿Cómo controlar el registro en nuevos procesos?
Puede generar nuevos procesos en el script de entrada con el módulo subprocess
, conectarse a sus canalizaciones de entrada, salida o error y obtener sus códigos de retorno.
El enfoque recomendado es usar la función run()
con capture_output=True
. Los errores se mostrarán en logs/user/error/<node_id>/<process_name>.txt
.
Si quiere usar Popen()
, debe redirigir stdout/stderr a archivos, como:
from pathlib import Path
from subprocess import Popen
from azureml_user.parallel_run import EntryScript
def init():
"""Show how to redirect stdout/stderr to files in logs/user/entry_script_log/<node_id>/."""
entry_script = EntryScript()
proc_name = entry_script.agent_name # The process name in pattern "processNNN".
log_dir = Path(entry_script.log_dir) # logs/user/entry_script_log/<node_id>/.
log_dir.mkdir(parents=True, exist_ok=True) # Create the folder if not existing.
stdout_file = str(log_dir / f"{proc_name}_demo_stdout.txt")
stderr_file = str(log_dir / f"{proc_name}_demo_stderr.txt")
proc = Popen(
["...")],
stdout=open(stdout_file, "w"),
stderr=open(stderr_file, "w"),
# ...
)
Nota
Un proceso de trabajo ejecuta el código "system" y el código de script de entrada en el mismo proceso.
Si no se especifica stdout
ni stderr
, un subproceso creado con Popen()
en el script de entrada heredará la configuración del proceso de trabajo.
stdout
escribirá en logs/sys/node/<node_id>/processNNN.stdout.txt
; y stderr
, en logs/sys/node/<node_id>/processNNN.stderr.txt
.
¿Cómo se escribe un archivo en el directorio de salida y se ve luego en el portal?
Puede obtener el directorio de salida de la clase EntryScript
y escribir en él. Para ver los archivos escritos, en el paso Ejecutar vista del portal de Azure Machine Learning, seleccione la pestaña Resultados y registros. Elija el vínculo Data outputs (Resultados de datos) y, luego, complete los pasos que se describen en el cuadro de diálogo.
Use EntryScript
en el script de entrada, como en este ejemplo:
from pathlib import Path
from azureml_user.parallel_run import EntryScript
def run(mini_batch):
output_dir = Path(entry_script.output_dir)
(Path(output_dir) / res1).write...
(Path(output_dir) / res2).write...
¿Cómo puedo pasar una entrada lateral, como archivos que contienen una tabla de búsqueda, a todos los trabajos?
El usuario puede pasar datos de referencia al script mediante el parámetro side_inputs de ParalleRunStep. Todos los conjuntos de datos proporcionados como side_inputs se montarán en cada nodo de trabajo. El usuario puede obtener la ubicación del montaje pasando el argumento.
Construya un conjunto de datos que contenga los datos de referencia, especifique una ruta de acceso de montaje local y regístrelo con su área de trabajo. Páselo al parámetro side_inputs
de ParallelRunStep
. Además, puede agregar su ruta de acceso en la sección arguments
para acceder fácilmente a su ruta de acceso montada.
Nota
Use FileDatasets solo para side_inputs.
local_path = "/tmp/{}".format(str(uuid.uuid4()))
label_config = label_ds.as_named_input("labels_input").as_mount(local_path)
batch_score_step = ParallelRunStep(
name=parallel_step_name,
inputs=[input_images.as_named_input("input_images")],
output=output_dir,
arguments=["--labels_dir", label_config],
side_inputs=[label_config],
parallel_run_config=parallel_run_config,
)
Una vez que pueda acceder a él en su script inferencia [por ejemplo, en el método init()] como sigue:
parser = argparse.ArgumentParser()
parser.add_argument('--labels_dir', dest="labels_dir", required=True)
args, _ = parser.parse_known_args()
labels_path = args.labels_dir
¿Cómo se usan los conjuntos de datos de entrada con la autenticación de entidad de servicio?
El usuario puede pasar conjuntos de datos de entrada con la autenticación de entidad de servicio usada en el área de trabajo. El uso de un conjunto de datos de este tipo en ParallelRunStep requiere que se registre el conjunto para que construya la configuración de ParallelRunStep.
service_principal = ServicePrincipalAuthentication(
tenant_id="***",
service_principal_id="***",
service_principal_password="***")
ws = Workspace(
subscription_id="***",
resource_group="***",
workspace_name="***",
auth=service_principal
)
default_blob_store = ws.get_default_datastore() # or Datastore(ws, '***datastore-name***')
ds = Dataset.File.from_files(default_blob_store, '**path***')
registered_ds = ds.register(ws, '***dataset-name***', create_new_version=True)
Comprobación y análisis del progreso
En esta sección se explica cómo comprobar el progreso de un trabajo ParallelRunStep y la causa de un comportamiento inesperado.
¿Cómo se comprueba el progreso del trabajo?
Además de consultar el estado general de StepRun, el recuento de lotes de pequeño tamaño programados o procesados y el progreso de la generación de salida se pueden ver en ~/logs/job_progress_overview.<timestamp>.txt
. El archivo rota diariamente y puede comprobar el que tiene la marca de tiempo más grande para tener la información más reciente.
¿Qué debo comprobar si no hay progreso durante un tiempo?
Puede ir a ~/logs/sys/errror
para ver si hay alguna excepción. Si no hay ninguna, es probable que el script de entrada esté tardando. Puede imprimir la información de progreso en el código para buscar la parte que consume tiempo o agregar "--profiling_module", "cProfile"
al elemento arguments
de ParallelRunStep
para generar un archivo de perfil denominado <process_name>.profile
en la carpeta ~/logs/sys/node/<node_id>
.
¿Cuándo se detiene un trabajo?
Si no se cancela, el trabajo se detendrá con el estado:
- Completed. Si se han procesado todos los lotes de pequeño tamaño y se ha generado la salida del modo
append_row
. - Failed. Si se supera el valor de
error_threshold
enParameters for ParallelRunConfig
o se produce un error del sistema durante el trabajo.
¿Dónde se encuentra la causa principal del error?
Puede seguir el ejemplo de ~logs/job_result.txt
para encontrar la causa y el registro de errores detallado.
¿Afectará el error del nodo al resultado del trabajo?
No, si hay otros nodos disponibles en el clúster de proceso designado. El orquestador inicia un nuevo nodo en sustitución, y ParallelRunStep es resistente a dicha operación.
¿Qué ocurre si la función init
del script de entrada produce un error?
ParallelRunStep tiene un mecanismo para reintentarlo un número determinado de veces a fin de dar la oportunidad de recuperarse de problemas transitorios sin retrasar el error del trabajo durante demasiado tiempo. El mecanismo es el siguiente:
- Si después de que se inicia un nodo,
init
sigue produciendo errores en todos los agentes, dejaremos de intentarlo después de3 * process_count_per_node
errores. - Si después de iniciar el trabajo,
init
sigue produciendo errores en todos los agentes de todos los nodos, dejaremos de intentarlo si el trabajo se ejecuta más de 2 minutos y hay2 * node_count * process_count_per_node
errores. - Si todos los agentes se bloquean en
init
durante más de3 * run_invocation_timeout + 30
segundos, se producirá un error en el trabajo debido a que no hay progreso durante demasiado tiempo.
¿Qué ocurrirá en OutOfMemory? ¿Cómo puedo comprobar la causa?
ParallelRunStep establecerá el intento actual de procesar el lote de pequeño tamaño en estado de error e intentará reiniciar el proceso con error. Puede comprobar ~logs/perf/<node_id>
para encontrar el proceso de consumo de memoria.
¿Por qué tengo muchos archivos processNNN?
ParallelRunStep iniciará nuevos procesos de trabajo en sustitución de los que se cerraron de forma anómala y cada proceso generará un archivo processNNN
como registro. Sin embargo, si se produjo un error en el proceso debido a una excepción durante la función init
del script de usuario y ese error se repitió continuamente durante 3 * process_count_per_node
veces, no se iniciará ningún nuevo proceso de trabajo.
Pasos siguientes
Consulte estos cuadernos de Jupyter Notebook que muestran canalizaciones de Azure Machine Learning.
Vea la referencia del SDK para obtener ayuda con el paquete azureml-pipeline-steps.
Vea la documentación de referencia de la clase ParallelRunConfig y la documentación para la clase ParallelRunStep.
Realice el tutorial avanzado sobre cómo usar canalizaciones con ParallelRunStep. En este tutorial se explica cómo pasar otro archivo como entrada lateral.