Risoluzione dei problemi relativi a ParallelRunStep

  • Articolo

SI APPLICA A: Python SDK azureml v1

Questo articolo illustra come risolvere i problemi quando si verificano errori usando la classe ParallelRunStep di Azure Machine Learning SDK.

Per suggerimenti generali sulla risoluzione dei problemi di una pipeline, vedere Risoluzione dei problemi relativi alle pipeline di Machine Learning.

Test degli script in locale

ParallelRunStep viene eseguito come passaggio nelle pipeline di Machine Learning. È consigliabile testare gli script in locale come primo passaggio.

Requisiti dello script di immissione

Lo script di immissione per un ParallelRunStep deve contenere una funzione run() e facoltativamente contiene una funzione init():

  • init(): usare questa funzione per qualsiasi preparazione dispendiosa o comune per un'inferenza successiva. Usarla ad esempio per caricare il modello in un oggetto globale. Questa funzione verrà chiamata solo una volta all'inizio del processo.

    Nota

    Se il metodo init crea una directory di output, specificare che parents=True e exist_ok=True. Il metodo init viene chiamato da ogni processo di lavoro in ogni nodo in cui è in esecuzione il processo.

  • run(mini_batch): la funzione viene eseguita per ogni istanza di mini_batch.
    • mini_batch: ParallelRunStep richiama il metodo run e passa un elenco o un DataFrame Pandas come argomento al metodo. Ogni voce in mini_batch sarà un percorso file se l'input è un oggetto FileDataset oppure un DataFrame Pandas se l'input è un oggetto TabularDataset.
    • response: il metodo run() deve restituire un DataFrame Pandas o una matrice. Per append_row output_action, questi elementi restituiti vengono accodati nel file di output comune. Per summary_only, il contenuto degli elementi viene ignorato. Per tutte le azioni di output, ogni elemento di output restituito indica un'esecuzione riuscita dell'elemento di input nel mini-batch di input. Verificare che nel risultato dell'esecuzione siano inclusi dati sufficienti per eseguire il mapping dell'input al risultato dell'output dell'esecuzione. L'output dell'esecuzione verrà scritto nel file di output ma non sarà necessariamente in ordine, quindi sarà necessario usare una chiave nell'output per eseguirne il mapping all'input.

      Nota

      È previsto un elemento di output per un elemento di input.

%%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

Se è presente un altro file o un'altra cartella nella stessa directory dello script di inferenza, è possibile farvi riferimento individuando la directory di lavoro corrente. Se si vogliono importare i pacchetti, è anche possibile aggiungere la cartella del pacchetto 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>

Parametri per ParallelRunConfig

ParallelRunConfig è la configurazione principale per l'istanza di ParallelRunStep all'interno della pipeline di Azure Machine Learning. Si usa per eseguire il wrapping dello script e configurare i parametri necessari, incluse tutte le voci seguenti:

  • entry_script: script utente come percorso di file locale che verrà eseguito in parallelo su più nodi. Se source_directory è presente, usare un percorso relativo. In caso contrario, usare qualsiasi percorso accessibile nel computer.

  • mini_batch_size: dimensioni del mini-batch passato a una singola chiamata di run(). (Facoltativo; il valore predefinito è 10 file per FileDataset e 1MB per TabularDataset.)

    • Per FileDataset, è il numero di file con un valore minimo di 1. È possibile combinare più file in un solo mini-batch.
    • Per TabularDataset, sono le dimensioni dei dati. Valori di esempio sono 1024, 1024KB, 10MB e 1GB. Il valore consigliato è 1MB. Il mini-batch di TabularDataset non supererà mai i limiti dei file. Supponiamo ad esempio di avere una serie di file CSV di varie dimensioni, comprese tra 100 KB e 10 MB. Se si imposta mini_batch_size = 1MB, i file di dimensioni inferiori a 1 MB verranno considerati come un mini-batch. I file di dimensioni maggiori di 1 MB verranno suddivisi in più mini-batch.

      Nota

      Non è possibile partizionare i TabularDatasets supportati da SQL. Non è possibile partizionare TabularDataset da un singolo file Parquet e da un singolo gruppo di righe.

  • error_threshold: numero di errori di record per TabularDataset e di errori di file per FileDataset che devono essere ignorati durante l'elaborazione. Se il numero di errori per l'intero input supera questo valore, il processo viene interrotto. La soglia di errore è per l'intero input e non per il singolo mini-batch inviato al metodo run(). L'intervallo è [-1, int.max]. La parte -1 indica di ignorare tutti gli errori durante l'elaborazione.

  • output_action: uno dei valori seguenti indica come verrà organizzato l'output:

    • summary_only: l'output viene archiviato dallo script utente. ParallelRunStep userà l'output solo per il calcolo della soglia di errore.
    • append_row: per tutti gli input, nella cartella di output verrà creato un solo file in cui accodare tutti gli output separati per riga.

  • append_row_file_name: per personalizzare il nome del file di output per append_row output_action (facoltativo, il valore predefinito è parallel_run_step.txt).

  • source_directory: percorsi delle cartelle che contengono tutti i file da eseguire nella destinazione di calcolo (facoltativo).

  • compute_target: è supportato solo AmlCompute.

  • node_count: il numero di nodi di calcolo da usare per l'esecuzione dello script utente.

  • process_count_per_node: il numero di processi di lavoro per nodo per eseguire lo script di immissione in parallelo. Per un computer GPU, il valore predefinito è 1. Per un computer CPU, il valore predefinito è il numero di core per nodo. Un processo di lavoro chiamerà run() ripetutamente passando il mini batch che riceve. Il numero totale di processi di lavoro nel processo è process_count_per_node * node_count, che determina il numero massimo di run() da eseguire in parallelo.

  • environment: la definizione dell'ambiente Python. È possibile configurarlo per usare un ambiente Python esistente o per configurare un ambiente temporaneo. La definizione è anche responsabile dell'impostazione delle dipendenze dell'applicazione necessarie (facoltativo).

  • logging_level: livello di dettaglio del log. I valori in ordine crescente di livello di dettaglio sono: WARNING, INFO e DEBUG. (Facoltativo. Il valore predefinito è INFO)

  • run_invocation_timeout: timeout della chiamata del metodo run() in secondi. (Facoltativo. Il valore predefinito è60)

  • run_max_try: il numero massimo di tentativi di run() per un mini-batch. Una run() viene considerata non riuscita se viene generata un'eccezione o se non viene restituito nulla quando viene raggiunto run_invocation_timeout (facoltativo; il valore predefinito è 3).

È possibile specificare mini_batch_size, node_count, process_count_per_node, logging_level, run_invocation_timeout e run_max_try come PipelineParameter in modo che, quando si ripete l'esecuzione della pipeline, sia possibile ottimizzare i valori dei parametri. In questo esempio si usa PipelineParameter per mini_batch_size e Process_count_per_node e questi valori verranno cambiati quando si ripete l'esecuzione in un secondo momento.

Visibilità dei dispositivi CUDA

Per le destinazioni di calcolo dotate di GPU, la variabile di ambiente verrà impostata CUDA_VISIBLE_DEVICES nei processi di lavoro. In AmlCompute è possibile trovare il numero totale di dispositivi GPU nella variabile di ambiente AZ_BATCHAI_GPU_COUNT_FOUND, che viene impostata automaticamente. Se si vuole che ogni processo di lavoro abbia una GPU dedicata, impostare process_count_per_node su un valore pari al numero di dispositivi GPU in un computer. Ogni processo di lavoro assegnerà un indice univoco a CUDA_VISIBLE_DEVICES. Se un processo di lavoro viene arrestato per qualsiasi motivo, il processo di lavoro avviato successivamente userà l'indice GPU rilasciato.

Se il numero totale di dispositivi GPU è minore di process_count_per_node, ai processi di lavoro verrà assegnato un indice GPU fino a quando non verranno usati tutti.

Dato che i dispositivi GPU totali sono 2 e process_count_per_node = 4 come esempio, il processo 0 e quello 1 avranno l'indice 0 e 1. I processi 2 e 3 non avranno una variabile di ambiente. Per una libreria che usa questa variabile di ambiente per l'assegnazione di GPU, i processi 2 e 3 non avranno GPU e non tenteranno di acquisire dispositivi GPU. In caso di arresto del processo 0, l'indice GPU 0 verrà rilasciato. Il processo successivo, che è il processo 4, avrà l'indice GPU 0 assegnato.

Per altre informazioni, vedere Suggerimento per CUDA: controllare la visibilità della GPU con CUDA_VISIBLE_DEVICES.

Parametri per la creazione di ParallelRunStep

Creare ParallelRunStep usando lo script, la configurazione dell'ambiente e i parametri. Specificare la destinazione di calcolo già collegata all'area di lavoro come destinazione di esecuzione dello script di inferenza. Usare ParallelRunStep per creare il passaggio della pipeline di inferenza batch, che accetta tutti i parametri seguenti:

  • name: nome del passaggio, con le restrizioni di denominazione seguenti: univoco, 3-32 caratteri ed espressione regolare ^[a-z]([-a-z0-9]*[a-z0-9])?$.
  • parallel_run_config: oggetto ParallelRunConfig, come definito in precedenza.
  • inputs: uno o più set di dati di Azure Machine Learning di tipo singolo da partizionare per l'elaborazione parallela.
  • side_inputs: uno o più set di dati o dati di riferimento usati come input secondari senza necessità di partizionamento.
  • output: un oggetto OutputFileDatasetConfig che rappresenta il percorso della directory in cui verranno archiviati i dati di output.
  • arguments: elenco di argomenti passati allo script utente. Usare unknown_args per recuperarli nello script di immissione (facoltativo).
  • allow_reuse: indica se il passaggio deve riutilizzare i risultati precedenti quando viene eseguito con le stesse impostazioni o gli stessi input. Se il parametro è False, durante l'esecuzione della pipeline viene sempre generata una nuova esecuzione per questo passaggio (Facoltativo. Il valore predefinito è True).
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
)

Debug degli script dal contesto remoto

La transizione dal debug di uno script di assegnazione del punteggio in locale al debug di uno script di assegnazione del punteggio in una pipeline effettiva può risultare difficile. Per informazioni sull'individuazione dei log nel portale, vedere la sezione della pipeline di Machine Learning sull'esecuzione del debug degli script dal contesto remoto. Le informazioni contenute nella sezione si applicano anche a ParallelRunStep.

Ad esempio, il file di log 70_driver_log.txt contiene le informazioni del controller che avvia il codice ParallelRunStep.

A causa della natura distribuita dei processi ParallelRunStep, sono presenti log di origini diverse. Tuttavia, vengono creati due file consolidati che offrono informazioni di alto livello:

  • ~/logs/job_progress_overview.txt: questo file offre informazioni di alto livello sul numero di mini-batch (chiamati anche attività) creati e il numero di mini-batch elaborati. A questo scopo, mostra il risultato del processo. Se il processo non è riuscito, verrà visualizzato il messaggio di errore e il punto in cui avviare la risoluzione dei problemi.

  • ~/logs/sys/master_role.txt: questo file fornisce la visualizzazione del nodo principale, chiamato anche agente di orchestrazione, del processo in esecuzione. Include la creazione di attività, il monitoraggio dello stato di avanzamento e il risultato dell'esecuzione.

I log generati dallo script di immissione usando l'helper EntryScript e le istruzioni print sono disponibili nei file seguenti:

  • ~/logs/user/entry_script_log/<node_id>/<process_name>.log.txt: questi file sono i log scritti da entry_script usando l'helper EntryScript.

  • ~/logs/user/stdout/<node_id>/<process_name>.stdout.txt: questi file sono i log di stdout, ad esempio istruzione di stampa, di entry_script.

  • ~/logs/user/stderr/<node_id>/<process_name>.stderr.txt: questi file sono i log di stderr di entry_script.

Per una comprensione immediata degli errori nello script, è disponibile il file:

  • ~/logs/user/error.txt: questo file tenta di riepilogare gli errori nello script.

Per altre informazioni sugli errori nello script, è disponibile il file:

  • ~/logs/user/error/: contiene tracce complete dello stack delle eccezioni generate durante il caricamento e l'esecuzione dello script di immissione.

Quando è necessaria una conoscenza completa del modo in cui ogni nodo ha eseguito lo script del punteggio, esaminare i singoli log dei processi per ogni nodo. I log dei processi sono disponibili nella cartella sys/node, raggruppati in base ai nodi di lavoro:

  • ~/logs/sys/node/<node_id>/<process_name>.txt: questo file offre informazioni dettagliate su ogni mini-batch quando viene selezionato o completato da un ruolo di lavoro. Per ogni mini-batch, il file include:

    • Indirizzo IP e PID del processo di lavoro.
    • Il numero totale di elementi, il numero di elementi elaborati correttamente e il numero di elementi non elaborati.
    • L'ora di inizio, la durata, il tempo di elaborazione e l'ora del metodo run.

È anche possibile visualizzare i risultati dei controlli periodici dell'utilizzo delle risorse per ogni nodo. I file di log e i file di installazione si trovano in questa cartella:

  • ~/logs/perf: impostare --resource_monitor_interval per modificare l'intervallo di controllo in secondi. L'intervallo predefinito è 600, che è di circa 10 minuti. Per arrestare il monitoraggio, impostare il valore su 0. Ogni cartella <node_id> include:

    • os/: informazioni su tutti i processi in esecuzione nel nodo. Un controllo esegue un comando del sistema operativo e salva il risultato in un file. In Linux usare il comando: ps. In Windows usare tasklist.
      • %Y%m%d%H: il nome della sottocartella è l'ora.
        • processes_%M: il file termina con il minuto dell'ora di controllo.
    • node_disk_usage.csv: utilizzo dettagliato del disco del nodo.
    • node_resource_usage.csv: panoramica dell'utilizzo delle risorse del nodo.
    • processes_resource_usage.csv: panoramica dell'utilizzo delle risorse di ogni processo.

Come registrare dallo script utente personale da un contesto remoto?

ParallelRunStep può eseguire diversi processi in un nodo sulla base di process_count_per_node. Per organizzare i log da ogni processo nel nodo e combinare l'istruzione print e log, è consigliabile usare il logger ParallelRunStep, come illustrato di seguito. Si ottiene un logger da EntryScript per fare in modo che i log vengano visualizzati nella cartella logs/user nel portale.

Script di immissione di esempio che usa il logger:

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

Dove viene eseguito il sink del messaggio logging da Python?

ParallelRunStep imposta un gestore nel logger radice, che esegue il sink del messaggio a logs/user/stdout/<node_id>/processNNN.stdout.txt.

logging viene impostato il livello INFO per impostazione predefinita. Per impostazione predefinita, i livelli al di sotto di INFO non verranno visualizzati, ad esempio DEBUG.

Come è possibile scrivere in un file da visualizzare nel portale?

I file nella cartella logs verranno caricati e visualizzati nel portale. È possibile ottenere la cartella logs/user/entry_script_log/<node_id> come di seguito e comporre il percorso del file da scrivere:

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.

Come gestire l'accesso ai nuovi processi?

È possibile generare nuovi processi nello script di immissione con il modulo subprocess, connettersi alle pipe di input/output/errore e ottenere i codici restituiti.

L'approccio consigliato consiste nell'usare la funzione run() con capture_output=True. Gli errori verranno visualizzati in logs/user/error/<node_id>/<process_name>.txt.

Se si vuole usare Popen(), è necessario reindirizzare stdout/stderr ai file, ad esempio:

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 processo di lavoro esegue il codice "system" e il codice dello script di immissione nello stesso processo.

Se non si specifica stdout o stderr, un sotto-processo creato con Popen() nello script di immissione erediterà l'impostazione del processo di lavoro.

stdout scriverà in logs/sys/node/<node_id>/processNNN.stdout.txt e stderr in logs/sys/node/<node_id>/processNNN.stderr.txt.

Come si scrive un file nella directory di output e lo si visualizza nel portale?

È possibile ottenere la directory di output dalla classe EntryScript e scriverla. Per visualizzare i file scritti, nel passaggio Esegui vista nel portale di Azure Machine Learning selezionare la scheda Output + log. Selezionare il collegamento Output dei dati, quindi completare i passaggi descritti nella finestra di dialogo.

Usare EntryScript nello script di immissione come in questo esempio:

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...

Come si passa un input collaterale, ad esempio uno o più file contenenti una tabella di ricerca, a tutti i ruoli di lavoro?

L'utente può passare dati di riferimento allo script usando il parametro side_inputs di ParalleRunStep. Tutti i set di dati forniti come side_inputs verranno montati in ogni nodo di lavoro. L'utente può ottenere il percorso del montaggio passando l'argomento.

Creare un set di dati contenente i dati di riferimento, specificare un percorso di montaggio locale e registrarlo nell'area di lavoro. Passarlo al parametro side_inputs di ParallelRunStep. Inoltre, è possibile aggiungere il percorso nella sezione arguments per accedere facilmente al percorso montato.

Nota

Usare FileDatasets solo per 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,
)

Successivamente, è possibile accedervi nello script di inferenza, ad esempio nel metodo init(), come illustrato di seguito:

parser = argparse.ArgumentParser()
parser.add_argument('--labels_dir', dest="labels_dir", required=True)
args, _ = parser.parse_known_args()

labels_path = args.labels_dir

Come si possono usare i set di dati di input con l'autenticazione dell'entità servizio?

L'utente può passare set di dati di input con l'autenticazione dell'entità servizio usata nell'area di lavoro. L'uso di tale set di dati in ParallelRunStep richiede la registrazione del set di dati per costruire la configurazione 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)

Come controllare lo stato di avanzamento e analizzarlo

Questa sezione descrive come controllare lo stato di avanzamento di un processo ParallelRunStep e verificare la causa di un comportamento imprevisto.

Come si può controllare l'avanzamento di un processo?

Oltre a esaminare lo stato complessivo di StepRun, è possibile visualizzare il numero di mini batch pianificati/elaborati e lo stato di avanzamento della generazione dell'output in ~/logs/job_progress_overview.<timestamp>.txt. Il file ruota su base giornaliera, è possibile controllare quello con il timestamp più grande per visualizzare le informazioni più recenti.

Cosa occorre controllare se non è presente un avanzamento da un po' di tempo?

È possibile accedere a ~/logs/sys/errror per verificare se è presente un'eccezione. Se non ve ne sono, è probabile che lo script di immissione richieda molto tempo. È possibile stampare le informazioni sullo stato di avanzamento nel codice per individuare la parte che richiede molto tempo o aggiungere "--profiling_module", "cProfile" a arguments di ParallelRunStep generare un file di profilo denominato <process_name>.profile nella cartella ~/logs/sys/node/<node_id>.

Quando si arresterà un processo?

Se non è stato annullato, il processo si arresterà con lo stato:

  • Operazione completata. Se tutti i mini batch sono stati elaborati e l'output è stato generato per la modalità append_row.
  • non riuscito. Se error_threshold in Parameters for ParallelRunConfig viene superato o si è verificato un errore di sistema durante il processo.

Dove si trova la causa radice dell'errore?

È possibile seguire il lead in ~logs/job_result.txt per trovare la causa e il log degli errori dettagliato.

L'errore del nodo influirà sul risultato del processo?

Non se sono presenti altri nodi disponibili nel cluster di elaborazione designato. L'agente di orchestrazione avvierà un nuovo nodo sostitutivo e ParallelRunStep è resiliente a tale operazione.

Cosa accade se la funzione init nello script di immissione ha esito negativo?

ParallelRunStep comprende un meccanismo per eseguire nuovi tentativi per un certo periodo di tempo in modo da offrire la possibilità di eseguire il ripristino da problemi temporanei senza ritardare l'errore del processo per troppo tempo. Il meccanismo è il seguente:

  1. Se dopo l'avvio di un nodo, init in tutti gli agenti continua a dare esito negativo, non verranno più eseguiti tentativi dopo 3 * process_count_per_node errori.
  2. Se dopo l'avvio di un processo, init in tutti gli agenti di tutti i nodi continua a dare esito negativo, non verranno più eseguiti tentativi se il processo è in esecuzione per più di 2 minuti e si verificano 2 * node_count * process_count_per_node errori.
  3. Se tutti gli agenti sono bloccati su init per più di 3 * run_invocation_timeout + 30 secondi, il processo avrà esito negativo a causa di assenza di avanzamento per troppo tempo.

Cosa accadrà su OutOfMemory? Come si può controllare la causa?

ParallelRunStep imposterà il tentativo corrente di elaborare il mini batch sullo stato di errore e proverà a riavviare il processo che ha dato esito negativo. È possibile controllare ~logs/perf/<node_id> per trovare il processo di utilizzo della memoria.

Perché sono presenti numerosi file processNNN?

ParallelRunStep avvierà nuovi processi di lavoro in sostituzione di quelli chiusi in modo anomalo e ogni processo genererà un file processNNN come log. Tuttavia, se il processo ha dato esito negativo a causa dell'eccezione durante la funzione init dello script utente e l'errore si ripete continuamente per 3 * process_count_per_node volte, non verrà avviato alcun nuovo processo di lavoro.

Passaggi successivi