Share via

Rozwiązywanie problemów z klasą ParallelRunStep

  • Artykuł

DOTYCZY:Zestaw SDK języka Python w wersji 1

Z tego artykułu dowiesz się, jak rozwiązywać problemy z błędami przy użyciu klasy ParallelRunStep z zestawu SDK usługi Azure Machine Learning.

Aby uzyskać ogólne porady dotyczące rozwiązywania problemów z potokiem, zobacz Rozwiązywanie problemów z potokami uczenia maszynowego.

Lokalne testowanie skryptów

Element ParallelRunStep działa jako krok w potokach uczenia maszynowego. Możesz przetestować skrypty lokalnie jako pierwszy krok.

Wymagania dotyczące skryptu wejściowego

Skrypt wejściowy elementu ParallelRunStepmusi zawieraćrun() funkcję i opcjonalnie zawiera init() funkcję:

  • init(): ta funkcja służy do jakichkolwiek kosztowych lub typowych przygotowań do późniejszego przetwarzania. Na przykład użyj go do załadowania modelu do obiektu globalnego. Ta funkcja będzie wywoływana tylko raz na początku procesu.

    Uwaga

    Jeśli metoda init tworzy katalog wyjściowy, określ ten parents=True katalog i exist_ok=True. Metoda jest wywoływana init z każdego procesu roboczego w każdym węźle, na którym jest uruchomione zadanie.

  • run(mini_batch): Funkcja zostanie uruchomiona dla każdego mini_batch wystąpienia.
    • mini_batch: ParallelRunStep wywoła metodę run i przekaże listę lub bibliotekę pandas DataFrame jako argument do metody . Każdy wpis w mini_batch będzie ścieżką pliku, jeśli dane wejściowe to FileDataset lub pandas DataFrame , jeśli dane wejściowe to TabularDataset.
    • response: metoda run() powinna zwracać bibliotekę pandas DataFrame lub tablicę. W przypadku append_row output_action zwracane elementy są dołączane do wspólnego pliku wyjściowego. W przypadku summary_only zawartość elementów jest ignorowana. Dla wszystkich akcji wyjściowych każdy zwrócony element wyjściowy wskazuje jeden pomyślny przebieg elementu wejściowego w minisadowej danych wejściowych. Upewnij się, że w wyniku uruchomienia jest uwzględniona wystarczająca ilość danych, aby zamapować dane wejściowe w celu uruchomienia wyniku wyjściowego. Uruchom dane wyjściowe zostaną zapisane w pliku wyjściowym i nie ma gwarancji, że w danych wyjściowych będzie używany klucz, aby zamapować go na dane wejściowe.

      Uwaga

      Jeden element wyjściowy jest oczekiwany dla jednego elementu wejściowego.

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

Jeśli masz inny plik lub folder w tym samym katalogu co skrypt wnioskowania, możesz odwoływać się do niego, wyszukując bieżący katalog roboczy. Jeśli chcesz zaimportować pakiety, możesz również dołączyć folder pakietu do folderu 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>

Parametry dla parametrów ParallelRunConfig

ParallelRunConfig jest główną konfiguracją na ParallelRunStep przykład w potoku usługi Azure Machine Learning. Służy do zawijania skryptu i konfigurowania niezbędnych parametrów, w tym wszystkich następujących wpisów:

  • entry_script: Skrypt użytkownika jako lokalna ścieżka pliku, która będzie uruchamiana równolegle w wielu węzłach. Jeśli source_directory jest obecny, użyj ścieżki względnej. W przeciwnym razie użyj dowolnej ścieżki dostępnej na maszynie.

  • mini_batch_size: rozmiar minisadowej partii przekazanej do pojedynczego run() wywołania. (opcjonalnie; wartość domyślna to 10 pliki dla FileDataset i 1MB dla .TabularDataset

    • W przypadku FileDatasetparametru jest to liczba plików o minimalnej wartości 1. Można połączyć wiele plików w jedną minisadę.
    • W przypadku TabularDatasetelementu jest to rozmiar danych. Przykładowe wartości to 1024, 1024KB, 10MBi 1GB. Zalecana wartość to 1MB. Mini-batch z TabularDataset nigdy nie przekroczy granic plików. Jeśli na przykład masz .csv plików o różnych rozmiarach, najmniejszy plik to 100 KB, a największy to 10 MB. Jeśli ustawisz wartość mini_batch_size = 1MB, pliki o rozmiarze mniejszym niż 1 MB będą traktowane jako jedna minisadowa. Pliki o rozmiarze większym niż 1 MB zostaną podzielone na wiele minisadów.

      Uwaga

      Nie można partycjonować zestawów danych tabelarycznych opartych na języku SQL. Tabelaryczne zestawy danych z pojedynczego pliku parquet i grupy pojedynczych wierszy nie mogą być partycjonowane.

  • error_threshold: liczba niepowodzeń rekordów dla TabularDataset błędów i plików, FileDataset które należy zignorować podczas przetwarzania. Jeśli liczba błędów dla całego danych wejściowych przekroczy tę wartość, zadanie zostanie przerwane. Próg błędu dotyczy całego wejścia, a nie pojedynczej minisadowej wysłanej run() do metody . Zakres to [-1, int.max]. Część -1 wskazuje na ignorowanie wszystkich błędów podczas przetwarzania.

  • output_action: Jedna z następujących wartości wskazuje sposób organizowania danych wyjściowych:

    • summary_only: skrypt użytkownika będzie przechowywać dane wyjściowe. ParallelRunStep Użyje danych wyjściowych tylko dla obliczenia progu błędu.
    • append_row: Dla wszystkich danych wejściowych w folderze wyjściowym zostanie utworzony tylko jeden plik, aby dołączyć wszystkie dane wyjściowe oddzielone wierszem.

  • append_row_file_name: Aby dostosować nazwę pliku wyjściowego dla append_row output_action (opcjonalnie; wartość domyślna to parallel_run_step.txt).

  • source_directory: ścieżki do folderów, które zawierają wszystkie pliki do wykonania w obiekcie docelowym obliczeniowym (opcjonalnie).

  • compute_target: Obsługiwana jest tylko AmlCompute wartość .

  • node_count: liczba węzłów obliczeniowych, które mają być używane do uruchamiania skryptu użytkownika.

  • process_count_per_node: liczba procesów roboczych na węzeł do równoległego uruchamiania skryptu wejściowego. W przypadku maszyny z procesorem GPU wartość domyślna to 1. W przypadku maszyny procesora CPU wartość domyślna to liczba rdzeni na węzeł. Proces roboczy będzie wywoływany run() wielokrotnie, przekazując minisadową partię. Łączna liczba procesów roboczych w zadaniu to process_count_per_node * node_count, która decyduje o maksymalnej liczbie wykonywanych run() równolegle.

  • environment: definicja środowiska języka Python. Można ją skonfigurować tak, aby korzystała z istniejącego środowiska języka Python lub skonfigurować środowisko tymczasowe. Definicja jest również odpowiedzialna za ustawienie wymaganych zależności aplikacji (opcjonalnie).

  • logging_level: Szczegółowość dziennika. Wartości w coraz większej szczegółowości to: WARNING, INFOi DEBUG. (opcjonalnie; wartość domyślna to INFO)

  • run_invocation_timeoutrun(): limit czasu wywołania metody w sekundach. (opcjonalnie; wartość domyślna to 60)

  • run_max_try: Maksymalna liczba run() prób dla minisadowej partii. Wartość A run() kończy się niepowodzeniem, jeśli zgłaszany jest wyjątek lub po osiągnięciu niczego nie jest zwracany run_invocation_timeout (opcjonalnie; wartość domyślna to 3).

Można określić mini_batch_size, , node_count, process_count_per_nodelogging_level, run_invocation_timeout, i run_max_try jako PipelineParameter, aby po ponownym wysłaniu uruchomienia potoku można dostosować wartości parametrów. W tym przykładzie użyjesz elementu PipelineParametermini_batch_size i Process_count_per_node zmienisz te wartości podczas ponownego ponownego uruchomienia.

Widoczność urządzeń CUDA

W przypadku obiektów obliczeniowych wyposażonych w procesory GPU zmienna CUDA_VISIBLE_DEVICES środowiskowa zostanie ustawiona w procesach roboczych. W aplikacji AmlCompute można znaleźć łączną liczbę urządzeń z procesorem GPU w zmiennej środowiskowej AZ_BATCHAI_GPU_COUNT_FOUND, która jest ustawiana automatycznie. Jeśli chcesz, aby każdy proces roboczy miał dedykowany procesor GPU, ustaw process_count_per_node wartość równą liczbie urządzeń z procesorem GPU na maszynie. Każdy proces roboczy przypisze unikatowy indeks do CUDA_VISIBLE_DEVICESelementu . Jeśli proces roboczy zostanie zatrzymany z jakiegokolwiek powodu, następny uruchomiony proces roboczy użyje opublikowanego indeksu procesora GPU.

Jeśli łączna liczba urządzeń z procesorem GPU jest mniejsza niż process_count_per_node, procesy robocze zostaną przypisane do indeksu procesora GPU do momentu użycia wszystkich.

Biorąc pod uwagę łączną liczbę urządzeń z procesorem GPU 2, a process_count_per_node = 4 na przykład proces 0 i proces 1 będą miały indeks 0 i 1. Proces 2 i 3 nie będzie miał zmiennej środowiskowej. W przypadku biblioteki używającej tej zmiennej środowiskowej do przypisania procesora GPU proces 2 i 3 nie będzie miał procesorów GPU i nie będzie próbował uzyskać urządzeń z procesorem GPU. Jeśli proces 0 zostanie zatrzymany, zostanie wydany indeks procesora GPU 0. Następny proces, który jest procesem 4, będzie miał przypisany indeks procesora GPU 0.

Aby uzyskać więcej informacji, zobacz CUDA Pro Tip: Control GPU Visibility with CUDA_VISIBLE_DEVICES (Porada CUDA Pro: kontrola widoczności procesora GPU za pomocą CUDA_VISIBLE_DEVICES).

Parametry służące do tworzenia elementu ParallelRunStep

Utwórz element ParallelRunStep przy użyciu skryptu, konfiguracji środowiska i parametrów. Określ docelowy obiekt obliczeniowy, który został już dołączony do obszaru roboczego jako element docelowy wykonywania dla skryptu wnioskowania. Użyj ParallelRunStep polecenia , aby utworzyć krok potoku wnioskowania wsadowego, który przyjmuje wszystkie następujące parametry:

  • name: nazwa kroku z następującymi ograniczeniami nazewnictwa: unikatowe, 3–32 znaki i wyrażenie regularne ^[a-z]([-a-z0-9]*[a-z0-9])?$.
  • parallel_run_configParallelRunConfig: obiekt, zgodnie z definicją wcześniej.
  • inputs: co najmniej jeden zestaw danych usługi Azure Machine Learning do partycjonowania na potrzeby przetwarzania równoległego.
  • side_inputs: Co najmniej jedno dane referencyjne lub zestawy danych używane jako dane wejściowe po stronie bez konieczności partycjonowania.
  • outputOutputFileDatasetConfig: obiekt reprezentujący ścieżkę katalogu, w której będą przechowywane dane wyjściowe.
  • arguments: lista argumentów przekazanych do skryptu użytkownika. Użyj unknown_args, aby pobrać je w skrypcie wpisu (opcjonalnie).
  • allow_reuse: czy krok powinien ponownie używać poprzednich wyników podczas uruchamiania z tymi samymi ustawieniami/danymi wejściowymi. Jeśli ten parametr to False, nowy przebieg będzie zawsze generowany dla tego kroku podczas wykonywania potoku. (opcjonalnie; wartość domyślna to 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
)

Debugowanie skryptów z kontekstu zdalnego

Przejście z debugowania skryptu oceniania lokalnie do debugowania skryptu oceniania w rzeczywistym potoku może być trudnym skokiem. Aby uzyskać informacje na temat znajdowania dzienników w portalu, zobacz sekcję Potoki uczenia maszynowego na temat debugowania skryptów z kontekstu zdalnego. Informacje w tej sekcji dotyczą również elementu ParallelRunStep.

Na przykład plik 70_driver_log.txt dziennika zawiera informacje z kontrolera, który uruchamia kod ParallelRunStep.

Ze względu na rozproszony charakter zadań ParallelRunStep istnieją dzienniki z kilku różnych źródeł. Tworzone są jednak dwa skonsolidowane pliki, które zapewniają ogólne informacje:

  • ~/logs/job_progress_overview.txt: Ten plik zawiera ogólne informacje o liczbie minisadów (znanych również jako zadania) utworzonych do tej pory i liczbie minisadów przetworzonych do tej pory. Na tym końcu zostanie wyświetlony wynik zadania. Jeśli zadanie nie powiodło się, zostanie wyświetlony komunikat o błędzie i gdzie rozpocząć rozwiązywanie problemów.

  • ~/logs/sys/master_role.txt: Ten plik udostępnia główny węzeł (znany również jako koordynator) widok uruchomionego zadania. Obejmuje tworzenie zadań, monitorowanie postępu, wynik uruchomienia.

Dzienniki wygenerowane na podstawie skryptu wpisu przy użyciu pomocnika Języka EntryScript i instrukcji drukowania będą znajdować się w następujących plikach:

  • ~/logs/user/entry_script_log/<node_id>/<process_name>.log.txt: Te pliki są dziennikami zapisanymi z entry_script przy użyciu pomocnika Języka EntryScript.

  • ~/logs/user/stdout/<node_id>/<process_name>.stdout.txt: Te pliki to dzienniki ze stdout (na przykład instrukcja print) entry_script.

  • ~/logs/user/stderr/<node_id>/<process_name>.stderr.txt: Te pliki są dziennikami ze stderr entry_script.

W celu zwięzłego zrozumienia błędów w skrycie istnieją następujące usterki:

  • ~/logs/user/error.txt: ten plik spróbuje podsumować błędy w skrycie.

Aby uzyskać więcej informacji na temat błędów w skryscie, istnieją następujące informacje:

  • ~/logs/user/error/: zawiera pełne ślady stosu wyjątków zgłaszanych podczas ładowania i uruchamiania skryptu wpisu.

Jeśli potrzebujesz pełnej wiedzy na temat wykonywania skryptu oceny dla każdego węzła, zapoznaj się z poszczególnymi dziennikami procesów dla każdego węzła. Dzienniki procesów można znaleźć w folderze sys/node pogrupowane według węzłów roboczych:

  • ~/logs/sys/node/<node_id>/<process_name>.txt: Ten plik zawiera szczegółowe informacje o każdej minisadowej partii, ponieważ jest on pobierany lub ukończony przez proces roboczy. Dla każdej minisadowej ten plik zawiera następujące elementy:

    • Adres IP i identyfikator PID procesu roboczego.
    • Całkowita liczba elementów, liczba przetworzonych pomyślnie przetworzonych elementów i liczba elementów zakończonych niepowodzeniem.
    • Czas rozpoczęcia, czas trwania, czas przetwarzania i czas wykonywania.

Możesz również wyświetlić wyniki okresowych kontroli użycia zasobów dla każdego węzła. Pliki dziennika i pliki instalacyjne znajdują się w tym folderze:

  • ~/logs/perf: ustaw --resource_monitor_interval , aby zmienić interwał sprawdzania w sekundach. Domyślny interwał to 600, czyli około 10 minut. Aby zatrzymać monitorowanie, ustaw wartość na 0. Każdy <node_id> folder zawiera:

    • os/: informacje o wszystkich uruchomionych procesach w węźle. Jedno sprawdzenie uruchamia polecenie systemu operacyjnego i zapisuje wynik w pliku. W systemie Linux polecenie to ps. W systemie Windows użyj polecenia tasklist.
      • %Y%m%d%H: nazwa podfolderu to godzina.
        • processes_%M: plik kończy się minutą czasu sprawdzania.
    • node_disk_usage.csv: Szczegółowe użycie dysku węzła.
    • node_resource_usage.csv: Omówienie użycia zasobów węzła.
    • processes_resource_usage.csv: Omówienie użycia zasobów dla każdego procesu.

Jak mogę zalogować się ze skryptu użytkownika z kontekstu zdalnego?

ParallelRunStep może uruchamiać wiele procesów w jednym węźle na podstawie process_count_per_node. Aby zorganizować dzienniki z każdego procesu w węźle i połączyć instrukcję drukowania i dziennika, zalecamy użycie rejestratora ParallelRunStep, jak pokazano poniżej. Dziennik jest pobierany z języka EntryScript i sprawia, że dzienniki są wyświetlane w folderze logs/user w portalu.

Przykładowy skrypt wpisu przy użyciu rejestratora:

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

Gdzie jest wyświetlany komunikat z ujścia języka Python logging ?

ParallelRunStep ustawia procedurę obsługi na głównym rejestratorze, który powoduje ujście komunikatu na logs/user/stdout/<node_id>/processNNN.stdout.txtwartość .

logging wartość domyślna to INFO poziom. Domyślnie poniższe poziomy INFO nie będą wyświetlane, takie jak DEBUG.

Jak mogę zapisać plik, aby był wyświetlany w portalu?

Pliki w logs folderze zostaną przekazane i wyświetlone w portalu. Możesz pobrać folder logs/user/entry_script_log/<node_id> podobny do poniższego i utworzyć ścieżkę pliku do zapisu:

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.

Jak obsługiwać logowanie w nowych procesach?

Możesz zduplikować nowe procesy w skrypicie wpisu za pomocą modułu, połączyć się z potokami subprocess danych wejściowych/wyjściowych/błędów i uzyskać kody powrotne.

Zalecaną metodą jest użycie run() funkcji z capture_output=Trueprogramem . Błędy będą wyświetlane w pliku logs/user/error/<node_id>/<process_name>.txt.

Jeśli chcesz użyć Popen()polecenia , należy przekierować plik stdout/stderr do plików, takich jak:

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"),
        # ...
    )

Uwaga

Proces roboczy uruchamia kod "system" i kod skryptu wpisu w tym samym procesie.

Jeśli nie stdout zostanie określony lub stderr określony, podproces utworzony za pomocą Popen() skryptu wpisu odziedziczy ustawienie procesu roboczego.

stdout będzie zapisywać do i logs/sys/node/<node_id>/processNNN.stdout.txtstderr na logs/sys/node/<node_id>/processNNN.stderr.txt.

Jak mogę zapisać plik w katalogu wyjściowym, a następnie wyświetlić go w portalu?

Katalog wyjściowy można pobrać z EntryScript klasy i zapisać w nim. Aby wyświetlić zapisane pliki, w widoku Przebiegu kroku w portalu usługi Azure Machine Learning wybierz kartę Dane wyjściowe i dzienniki . Wybierz link Dane wyjściowe , a następnie wykonaj kroki opisane w oknie dialogowym.

Użyj EntryScript w skryscie wpisu, tak jak w tym przykładzie:

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

Jak przekazać dane wejściowe po stronie, takie jak plik lub pliki zawierające tabelę odnośników, do wszystkich moich procesów roboczych?

Użytkownik może przekazać dane referencyjne do skryptu przy użyciu parametru side_inputs Parametru ParalleRunStep. Wszystkie zestawy danych podane jako side_inputs zostaną zainstalowane w każdym węźle roboczym. Użytkownik może uzyskać lokalizację instalacji, przekazując argument.

Skonstruuj zestaw danych zawierający dane referencyjne, określ lokalną ścieżkę instalacji i zarejestruj go w obszarze roboczym. Przekaż go do side_inputs parametru .ParallelRunStep Ponadto możesz dodać swoją ścieżkę w arguments sekcji, aby łatwo uzyskać dostęp do jej zainstalowanej ścieżki.

Uwaga

Użyj zestawów FileDataset tylko dla 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,
)

Następnie możesz uzyskać do niego dostęp w skrypcie wnioskowania (na przykład w metodzie init() w następujący sposób:

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

labels_path = args.labels_dir

Jak używać wejściowych zestawów danych z uwierzytelnianiem jednostki usługi?

Użytkownik może przekazywać wejściowe zestawy danych z uwierzytelnianiem jednostki usługi używanym w obszarze roboczym. Użycie takiego zestawu danych w elemecie ParallelRunStep wymaga zarejestrowania zestawu danych w celu skonstruowania konfiguracji 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)

Jak sprawdzić postęp i przeanalizować go

W tej sekcji o tym, jak sprawdzić postęp zadania ParallelRunStep i sprawdzić przyczynę nieoczekiwanego zachowania.

Jak sprawdzić postęp zadania?

Oprócz sprawdzenia ogólnego stanu kroku, liczba zaplanowanych/przetworzonych minisadów i postęp generowania danych wyjściowych można wyświetlić w pliku ~/logs/job_progress_overview.<timestamp>.txt. Plik jest obracany codziennie, możesz sprawdzić ten z największą sygnaturą czasowa, aby uzyskać najnowsze informacje.

Co należy sprawdzić, czy na jakiś czas nie ma postępu?

Możesz przejść do ~/logs/sys/errror sekcji , aby sprawdzić, czy istnieje jakikolwiek wyjątek. Jeśli nie ma żadnego, prawdopodobnie skrypt wprowadzania trwa długo, możesz wydrukować informacje o postępie w kodzie, aby zlokalizować część czasochłonną lub dodać "--profiling_module", "cProfile" do ParallelRunSteparguments elementu w celu wygenerowania pliku profilu o nazwie w <process_name>.profile folderze~/logs/sys/node/<node_id>.

Kiedy zadanie zostanie zatrzymane?

jeśli nie zostanie anulowane, zadanie zostanie zatrzymane ze stanem:

  • Zakończone. Jeśli wszystkie minisady zostały przetworzone, a dane wyjściowe zostały wygenerowane dla append_row trybu.
  • Niepowodzenie. Jeśli error_threshold wartość in Parameters for ParallelRunConfig jest przekroczona lub wystąpił błąd systemowy podczas zadania.

Gdzie znaleźć główną przyczynę awarii?

Aby znaleźć przyczynę i szczegółowy dziennik błędów, możesz skorzystać z potencjalnych klientów ~logs/job_result.txt .

Czy awaria węzła wpłynie na wynik zadania?

Nie, jeśli istnieją inne dostępne węzły w wyznaczonym klastrze obliczeniowym. Orkiestrator uruchomi nowy węzeł jako zamiennik, a element ParallelRunStep jest odporny na taką operację.

Co się stanie, jeśli init funkcja w skry skrycie wejściowym zakończy się niepowodzeniem?

ParallelRunStep ma mechanizm ponawiania próby przez określony czas, aby dać szansę na odzyskanie z powodu przejściowych problemów bez opóźnienia niepowodzenia zadania przez zbyt długi czas, mechanizm jest następujący:

  1. Jeśli po uruchomieniu init węzła na wszystkich agentach kończy się niepowodzeniem, przestaniemy próbować po 3 * process_count_per_node awariach.
  2. Jeśli po uruchomieniu init zadania na wszystkich agentach wszystkich węzłów kończy się niepowodzeniem, przestaniemy próbować, jeśli zadanie będzie działać dłużej niż 2 minuty i wystąpią 2 * node_count * process_count_per_node błędy.
  3. Jeśli wszyscy agenci są zablokowani init przez więcej niż 3 * run_invocation_timeout + 30 kilka sekund, zadanie zakończy się niepowodzeniem z powodu zbyt długiego postępu.

Co się stanie w outOfMemory? Jak sprawdzić przyczynę?

Parametr ParallelRunStep ustawi bieżącą próbę przetworzenia stanu niepowodzenia mini-batch i spróbuje ponownie uruchomić proces, który zakończył się niepowodzeniem. Aby znaleźć proces zużywania pamięci, możesz sprawdzić ~logs/perf/<node_id> .

Dlaczego mam wiele plików processNNN?

ParallelRunStep uruchomi nowe procesy robocze w zamian tych, które zakończą się nieprawidłowo, a każdy proces wygeneruje processNNN plik jako dziennik. Jeśli jednak proces nie powiódł się z powodu wyjątku podczas init działania skryptu użytkownika i że błąd jest powtarzany w sposób ciągły, 3 * process_count_per_node nie zostanie uruchomiony nowy proces roboczy.

Następne kroki