Probleem met de ParallelRunStep oplossen

  • Artikel

VAN TOEPASSING OP:Python SDK azureml v1

In dit artikel leert u hoe u problemen kunt oplossen wanneer u fouten krijgt met behulp van de klasse ParallelRunStep van de Azure Machine Learning SDK.

Zie Problemen met machine learning-pijplijnen oplossen voor algemene tips voor het oplossen van problemen met een pijplijn.

Scripts lokaal testen

Uw ParallelRunStep wordt uitgevoerd als een stap in ML-pijplijnen. U kunt uw scripts lokaal testen als eerste stap.

Vereisten voor invoerscript

Het invoerscript voor een ParallelRunStepmoet een run() functie bevatten en optioneel een init() functie:

  • init(): Gebruik deze functie voor een kostbare of algemene voorbereiding voor latere verwerking. Gebruik het bijvoorbeeld om het model in een algemeen object te laden. Deze functie wordt slecht één keer aangeroepen, aan het begin van het proces.

    Notitie

    Als uw init methode een uitvoermap maakt, geeft u op dat parents=True en exist_ok=True. De init methode wordt aangeroepen vanuit elk werkproces op elk knooppunt waarop de taak wordt uitgevoerd.

  • run(mini_batch): De functie wordt uitgevoerd voor elk exemplaar van mini_batch.
    • mini_batch: ParallelRunStep roept de uitvoermethode aan en geeft een lijst of pandas-DataFrame op als argument aan de methode. Elke vermelding in mini_batch is een bestandspad als de invoer een FileDataset is, of een pandas-DataFrame als de invoer een TabularDataset is.
    • response: run()-methode moet resulteren in een pandas-DataFrame of een matrix. Voor append_row output_action worden deze geretourneerde elementen toegevoegd aan het algemene uitvoerbestand. Voor summary_only wordt de inhoud van de elementen genegeerd. Voor alle uitvoeracties geeft elk geretourneerde uitvoerelement een geslaagde uitvoering van een invoerelement in de mini-batch aan. Zorg dat er voldoende gegevens worden opgenomen in het resultaat van de uitvoering om invoer toe te wijzen aan de uitvoerresultaten. Uitvoer wordt naar het uitvoerbestand geschreven en bevindt zich niet altijd in de juiste volgorde. Gebruik een sleutel in de uitvoer om deze toe te wijzen aan de invoer.

      Notitie

      Er wordt één uitvoerelement verwacht voor één invoerelement.

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

Als u een ander bestand of een andere map hebt in dezelfde map als uw deductiescript, dan kunt u ernaar verwijzen door de huidige werkmap te zoeken. Als u uw pakketten wilt importeren, kunt u ook uw pakketmap toevoegen aan 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>

Parameters voor ParallelRunConfig

ParallelRunConfig is de voornaamste configuratie voor ParallelRunStep-exemplaar in de Azure Machine Learning-pijplijn. U gebruikt dit om uw script te verpakken en de nodige parameters te configureren, waaronder alle volgende vermeldingen:

  • entry_script: Een gebruikersscript als een lokaal bestandspad dat parallel wordt uitgevoerd op meerdere knooppunten. Als source_directory aanwezig is, gebruikt dan een relatief pad. Zoniet, gebruik dan een pad dat toegankelijk is op de machine.

  • mini_batch_size: De grootte van de mini-batch die is doorgegeven aan een enkele run()-aanroep. (optioneel; de standaardwaarde is 10-bestanden voor FileDataset en 1MB voor TabularDataset.)

    • Voor FileDataset is dit het aantal bestanden met een minimumwaarde 1. U kunt meerdere bestanden combineren in één mini-batch.
    • Voor TabularDataset is dit de grootte van de gegevens. Voorbeeldwaarden zijn 1024, 1024KB, 10MB en 1GB. De aanbevolen waarde is 1MB. De mini-batch van TabularDataset zal nooit bestandsgrenzen overschrijden. Als u bijvoorbeeld een .csv-bestand heeft met verschillende groottes, dan is het kleinste bestan 100 KB en het grootste 10 MB. Als u mini_batch_size = 1MB instelt, worden bestanden met een grootte van minder dan 1 MB beschouwd als één mini-batch. Bestanden met een grootte van meer dan 1 MB, worden in verschillende mini-batches opgedeeld.

      Notitie

      TabularDatasets die worden ondersteund door SQL kunnen niet worden gepartitioneerd. TabularDatasets uit één parquet-bestand en één rijgroep kunnen niet worden gepartitioneerd.

  • error_threshold: Het aantal recordfouten voor TabularDataset en bestandsfouten voor FileDataset die tijdens de verwerking genegeerd mogen worden. Als het aantal fouten voor de volledige invoer boven deze waarde komt, wordt de taak afgebroken. De drempelwaarde voor fouten geldt voor de volledige invoer, niet voor afzonderlijke mini-batches die naar de run()-methode verzonden worden. Het bereik is [-1, int.max]. Het deel -1 geeft aan dat alle fouten tijdens de verwerking genegeerd worden.

  • output_action: Een van de volgende waarden geeft aan wat er met de uitvoer gebeurt:

    • summary_only: Het gebruikersscript slaat de uitvoer op. ParallelRunStep gebruikt de uitvoer enkel voor de berekening van de drempelwaarde voor fouten.
    • append_row: Er wordt slechts één bestand gemaakt in de uitvoermap voor alle invoerwaarden, waarbij elke uitvoerwaarde een aparte regel krijgt.

  • append_row_file_name: Om de naam van het uitvoerbestand voor append_row output_action aan te passen (optioneel; de standaardwaarde is parallel_run_step.txt).

  • source_directory: Paden naar mappen met alle bestanden die moeten worden uitgevoerd op het rekendoel (optioneel).

  • compute_target: Alleen AmlCompute wordt ondersteund.

  • node_count: Het aantal rekenknooppunten dat moet worden gebruikt voor de uitvoering van het gebruikersscript.

  • process_count_per_node: het aantal werkprocessen per knooppunt om het invoerscript parallel uit te voeren. Voor een GPU-machine is de standaardwaarde 1. Voor een CPU-machine is de standaardwaarde het aantal kernen per knooppunt. Een werkproces roept herhaaldelijk aan run() door de minibatch door te geven. Het totale aantal werkprocessen in uw taak is process_count_per_node * node_count, waarmee het maximum aantal run() wordt bepaald dat parallel moet worden uitgevoerd.

  • environment: De definitie van de Python-omgeving. U kunt deze configureren om een bestaande Python-omgeving te gebruiken of om een tijdelijke omgeving in te stellen. De definitie zorgt er ook voor dat de vereiste toepassingsafhankelijkheden worden ingesteld (optioneel).

  • logging_level: Uitgebreidheid van het logboek. De waarden om uitgebreidheid te verhogen zijn: WARNING, INFO en DEBUG. (optioneel; de standaardwaarde is INFO)

  • run_invocation_timeout: De aanroeptime-out voor de run()-methode in seconden. (optioneel; standaardwaarde is 60)

  • run_max_try: Maximum aantal pogingen van run() voor een mini-batch. Een run() is mislukt als er een uitzondering wordt gegenereerd of er niets wordt geretourneerd wanneer run_invocation_timeout is bereikt (optioneel; de standaardwaarde is 3).

U kunt mini_batch_size, node_count, process_count_per_node, logging_level, run_invocation_timeout en run_max_try als PipelineParameter opgeven, zodat u de parameterwaarden kunt aanpassen wanneer u een pijplijnuitvoering opnieuw verzendt. In dit voorbeeld gebruikt PipelineParameter u voor mini_batch_size en Process_count_per_node en wijzigt u deze waarden wanneer u een andere uitvoering opnieuw indient.

Zichtbaarheid van CUDA-apparaten

Voor rekendoelen die zijn uitgerust met GPU's, wordt de omgevingsvariabele CUDA_VISIBLE_DEVICES ingesteld in werkprocessen. In AmlCompute vindt u het totale aantal GPU-apparaten in de omgevingsvariabele AZ_BATCHAI_GPU_COUNT_FOUND, die automatisch wordt ingesteld. Als u wilt dat elk werkproces een toegewezen GPU heeft, stelt u process_count_per_node in op het aantal GPU-apparaten op een computer. Elk werkproces wijst een unieke index toe aan CUDA_VISIBLE_DEVICES. Als een werkproces om welke reden dan ook stopt, gebruikt het volgende gestarte werkproces de vrijgegeven GPU-index.

Als het totale aantal GPU-apparaten kleiner is dan process_count_per_node, wordt aan de werkprocessen gpu-index toegewezen totdat alle apparaten zijn gebruikt.

Gezien het totale aantal GPU-apparaten is 2 en process_count_per_node = 4 als voorbeeld hebben proces 0 en proces 1 index 0 en 1. Proces 2 en 3 hebben geen omgevingsvariabele. Voor een bibliotheek die deze omgevingsvariabele gebruikt voor GPU-toewijzing, hebben proces 2 en 3 geen GPU-apparaten en proberen ze geen GPU-apparaten te verkrijgen. Als proces 0 stopt, wordt GPU-index 0 vrijgegeven. Aan het volgende proces, dat proces 4 is, wordt GPU-index 0 toegewezen.

Zie CUDA Pro Tip: Gpu-zichtbaarheid beheren met CUDA_VISIBLE_DEVICES voor meer informatie.

Parameters voor het maken van de ParallelRunStep

Maak de ParallelRunStep met het script, de omgevingsconfiguratie en de parameters. Geef het rekendoel op dat u al aan uw werkruimte hebt gekoppeld als het doel van de uitvoering voor uw deductiescript. Gebruik ParallelRunStep om de stap voor de batchdeductiepijplijn te maken, met de volgende parameters:

  • name: De naam van de stap, met de volgende naamgevingsbeperkingen: uniek, 3-32 tekens en regex ^[a-z]([-a-z0-9]*[a-z0-9])?$.
  • parallel_run_config: Een ParallelRunConfig-object, zoals eerder gedefinieerd.
  • inputs: Een of meer Azure Machine Learning-gegevenssets van één type die moeten worden gepartitioneerd voor parallelle verwerking.
  • side_inputs: Een of meer referentiegegevens of gegevenssets die worden gebruikt als aanvullende invoerwaarden en niet gepartitioneerd moeten worden.
  • output: Een OutputFileDatasetConfig object dat het mappad vertegenwoordigt waarop de uitvoergegevens worden opgeslagen.
  • arguments: Een lijst van argumenten die worden doorgegeven aan het gebruikersscript. Gebruik unknown_args om deze op te halen in uw invoerscript (optioneel).
  • allow_reuse: Of de stap vorige resultaten moet hergebruiken wanneer dezelfde instellingen/invoerwaarden worden uitgevoerd. Als deze parameter False is, dan wordt er altijd een nieuwe uitvoering gegenereerd voor deze stap tijdens pijplijnuitvoering. (optioneel; de standaardwaarde is 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
)

Fouten opsporen in scripts vanuit externe context

De overgang van het lokaal opsporen van een scorescript naar het opsporen van fouten in een scorescript in een daadwerkelijke pijplijn kan een moeilijke stap zijn. Zie de sectie machine learning-pijplijnen over foutopsporing van scripts vanuit een externe context voor meer informatie over het zoeken naar uw logboeken in de portal. De informatie in die sectie is ook van toepassing op een ParallelRunStep.

Het logboekbestand 70_driver_log.txt bevat bijvoorbeeld informatie van de controller die de ParallelRunStep-code start.

Vanwege de gedistribueerde aard van ParallelRunStep-taken zijn er logboeken uit verschillende bronnen. Er worden echter twee geconsolideerde bestanden gemaakt die informatie op hoog niveau bieden:

  • ~/logs/job_progress_overview.txt: dit bestand bevat informatie op hoog niveau over het aantal minibatches (ook wel taken genoemd) dat tot nu toe is gemaakt en het aantal minibatches dat tot nu toe is verwerkt. Aan dit einde wordt het resultaat van de taak weergegeven. Als de taak is mislukt, wordt het foutbericht weergegeven en waar u de probleemoplossing kunt starten.

  • ~/logs/sys/master_role.txt: dit bestand biedt de weergave van het hoofdknooppunt (ook wel orchestrator genoemd) van de actieve taak. Omvat het maken van taken, voortgangsbewaking en het uitvoeringsresultaat.

Logboeken die zijn gegenereerd op basis van invoerscript met behulp van EntryScript-helper en afdrukinstructies, vindt u in de volgende bestanden:

  • ~/logs/user/entry_script_log/<node_id>/<process_name>.log.txt: Deze bestanden zijn de logboeken die zijn geschreven van entry_script met behulp van entryScript-helper.

  • ~/logs/user/stdout/<node_id>/<process_name>.stdout.txt: deze bestanden zijn de logboeken van stdout (bijvoorbeeld afdrukinstructie) van entry_script.

  • ~/logs/user/stderr/<node_id>/<process_name>.stderr.txt: Deze bestanden zijn de logboeken van stderr van entry_script.

Voor een beknopt begrip van fouten in uw script is er:

  • ~/logs/user/error.txt: dit bestand probeert de fouten in uw script samen te vatten.

Voor meer informatie over fouten in uw script vindt u:

  • ~/logs/user/error/: Bevat volledige stacktraceringen van uitzonderingen die zijn opgetreden tijdens het laden en uitvoeren van het invoerscript.

Wanneer u een volledig begrip nodig hebt van de wijze waarop elk knooppunt het scorescript heeft uitgevoerd, bekijkt u de afzonderlijke proceslogboeken voor elk knooppunt. De proceslogboeken zijn te vinden in de sys/node map, gegroepeerd op werkknooppunten:

  • ~/logs/sys/node/<node_id>/<process_name>.txt: dit bestand bevat gedetailleerde informatie over elke minibatch wanneer deze wordt opgehaald of voltooid door een werkrol. Voor elke minibatch bevat dit bestand:

    • Het IP-adres en de PID van het werkproces.
    • Het totale aantal items, het aantal verwerkte items en het aantal mislukte items.
    • De begintijd, duur, procestijd en tijd van de uitvoeringsmethode.

U kunt ook de resultaten bekijken van periodieke controles van het resourcegebruik voor elk knooppunt. De logboekbestanden en installatiebestanden bevinden zich in deze map:

  • ~/logs/perf: stel in om --resource_monitor_interval het controleinterval in seconden te wijzigen. Het standaardinterval is 600, wat ongeveer 10 minuten is. Als u de bewaking wilt stoppen, stelt u de waarde in op 0. Elke <node_id> map bevat:

    • os/: informatie over alle actieve processen in het knooppunt. Met één controle wordt een opdracht van het besturingssysteem uitgevoerd en wordt het resultaat opgeslagen in een bestand. In Linux is psde opdracht . In Windows gebruikt u tasklist.
      • %Y%m%d%H: De naam van de submap is de tijd tot uur.
        • processes_%M: Het bestand eindigt met de minuut van de controletijd.
    • node_disk_usage.csv: gedetailleerd schijfgebruik van het knooppunt.
    • node_resource_usage.csv: Overzicht van resourcegebruik van het knooppunt.
    • processes_resource_usage.csv: Overzicht van resourcegebruik van elk proces.

Hoe kan ik logboek van mijn gebruikersscript vanuit een externe context?

ParallelRunStep kan meerdere processen uitvoeren op één knooppunt op basis van process_count_per_node. Als u logboeken van elk proces op het knooppunt wilt ordenen en afdruk- en logboekinstructie wilt combineren, raden we u aan parallelrunstep-logboekregistratie te gebruiken, zoals hieronder wordt weergegeven. U krijgt een logboekregistratie van EntryScript en zorgt ervoor dat de logboeken worden weergegeven in de map logboeken/gebruikers in de portal.

Een voorbeeld van een invoerscript met behulp van de logboekregistratie:

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

Waar gaat het bericht van Python logging naartoe?

ParallelRunStep stelt een handler in op de root-logger, waardoor het bericht wordt gezonken naar logs/user/stdout/<node_id>/processNNN.stdout.txt.

logging standaard ingesteld op INFO niveau. Standaard worden de onderstaande INFO niveaus niet weergegeven, zoals DEBUG.

Hoe kan ik schrijven naar een bestand dat wordt weergegeven in de portal?

Bestanden in logs de map worden geüpload en weergegeven in de portal. U kunt de map logs/user/entry_script_log/<node_id> ophalen zoals hieronder en uw bestandspad opstellen om te schrijven:

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.

Hoe om te gaan met nieuwe processen aanmelden?

U kunt nieuwe processen in uw invoerscript genereren met module subprocess , verbinding maken met hun invoer-/uitvoer-/foutpijpen en hun retourcodes verkrijgen.

De aanbevolen aanpak is om de run() functie te gebruiken met capture_output=True. Fouten worden weergegeven in logs/user/error/<node_id>/<process_name>.txt.

Als u wilt gebruiken Popen(), moet u stdout/stderr omleiden naar bestanden, zoals:

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

Notitie

Een werkproces voert systeemcode en de code van het invoerscript in hetzelfde proces uit.

Als dit niet stdout is of stderr is opgegeven, neemt een subproces dat is gemaakt met Popen() in het invoerscript, de instelling van het werkproces over.

stdout schrijft naar logs/sys/node/<node_id>/processNNN.stdout.txt en stderr naar logs/sys/node/<node_id>/processNNN.stderr.txt.

Hoe kan ik een bestand naar de uitvoermap schrijven en het vervolgens weergeven in de portal?

U kunt de uitvoermap ophalen uit de EntryScript klasse en ernaar schrijven. Als u de geschreven bestanden wilt weergeven, selecteert u in de weergave Uitvoeren in de Azure Machine Learning-portal het tabblad Uitvoer en logboeken . Selecteer de koppeling Gegevensuitvoer en voer de stappen uit die worden beschreven in het dialoogvenster.

Gebruik EntryScript in uw invoerscript, zoals in dit voorbeeld:

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

Hoe kan ik een side-invoer, zoals een bestand of bestand(en) met een opzoektabel, doorgeven aan al mijn werkrollen?

Gebruiker kan referentiegegevens doorgeven aan het script met behulp van side_inputs parameter van ParalleRunStep. Alle gegevenssets die als side_inputs worden opgegeven, worden gekoppeld aan elk werkknooppunt. De gebruiker kan de locatie van de koppeling ophalen door het argument door te geven.

Stel een gegevensset samen met de referentiegegevens, geef een lokaal koppelingspad op en registreer deze bij uw werkruimte. Geef deze door aan de side_inputs parameter van uw ParallelRunStep. Daarnaast kunt u het pad toevoegen in de sectie om eenvoudig toegang te krijgen tot het arguments gekoppelde pad.

Notitie

Gebruik FileDatasets alleen voor 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,
)

Daarna kunt u het als volgt openen in uw deductiescript (bijvoorbeeld in uw init()-methode:

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

labels_path = args.labels_dir

Invoergegevenssets gebruiken met verificatie van service-principals

Gebruiker kan invoergegevenssets doorgeven met service-principal-verificatie die wordt gebruikt in de werkruimte. Voor het gebruik van een dergelijke gegevensset in ParallelRunStep moet de gegevensset worden geregistreerd om de ParallelRunStep-configuratie te maken.

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)

Voortgang controleren en analyseren

Deze sectie gaat over het controleren van de voortgang van een ParallelRunStep-taak en het controleren van de oorzaak van onverwacht gedrag.

Hoe kan ik de voortgang van de taak controleren?

Naast het bekijken van de algemene status van de StepRun, kan het aantal geplande/verwerkte minibatches en de voortgang van het genereren van uitvoer worden weergegeven in ~/logs/job_progress_overview.<timestamp>.txt. Het bestand wordt dagelijks geroteerd. U kunt het bestand met het grootste tijdstempel controleren op de meest recente informatie.

Wat moet ik controleren als er een tijdje geen voortgang is?

U kunt naar binnen ~/logs/sys/errror gaan om te zien of er een uitzondering is. Als er geen is, is het waarschijnlijk dat het invoerscript lang duurt. U kunt voortgangsinformatie in uw code afdrukken om het tijdrovende deel te vinden of toevoegen "--profiling_module", "cProfile" aan de van ParallelRunStep om een profielbestand te genereren met de arguments naam as <process_name>.profile onder ~/logs/sys/node/<node_id> map.

Wanneer stopt een taak?

als deze niet wordt geannuleerd, stopt de taak met de status:

  • Voltooid. Als alle minibatches zijn verwerkt en de uitvoer is gegenereerd voor append_row de modus.
  • Mislukt. Als error_threshold in Parameters for ParallelRunConfig wordt overschreden of als er een systeemfout is opgetreden tijdens de taak.

Waar kan ik de hoofdoorzaak van de fout vinden?

U kunt de lead in ~logs/job_result.txt volgen om de oorzaak en het gedetailleerde foutenlogboek te vinden.

Heeft een knooppuntfout invloed op het taakresultaat?

Niet als er andere beschikbare knooppunten in het toegewezen rekencluster zijn. De orchestrator start een nieuw knooppunt als vervanging en ParallelRunStep is bestand tegen een dergelijke bewerking.

Wat gebeurt er als init de functie in het invoerscript mislukt?

ParallelRunStep heeft een mechanisme om het gedurende een bepaalde tijd opnieuw te proberen om kans te geven op herstel van tijdelijke problemen zonder de taakfout te lang te vertragen. Het mechanisme is als volgt:

  1. Als nadat een knooppunt is gestart, init op alle agents blijft mislukken, stoppen we het proberen na 3 * process_count_per_node fouten.
  2. Als na het starten init van de taak op alle agents van alle knooppunten blijft mislukken, stoppen we het proberen als de taak langer dan 2 minuten wordt uitgevoerd en er fouten optreden 2 * node_count * process_count_per_node .
  3. Als alle agents langer dan 3 * run_invocation_timeout + 30 seconden zijn vastgelopeninit, mislukt de taak omdat er te lang geen voortgang is.

Wat gebeurt er op OutOfMemory? Hoe kan ik de oorzaak controleren?

ParallelRunStep stelt de huidige poging om de minibatch te verwerken in op de foutstatus en probeert het mislukte proces opnieuw te starten. U kunt controleren om ~logs/perf/<node_id> het proces voor geheugenverbruik te vinden.

Waarom heb ik veel procesNNN-bestanden?

ParallelRunStep start nieuwe werkprocessen ter vervanging van de processen die abnormaal zijn afgesloten, en elk proces genereert een processNNN bestand als logboek. Als het proces echter is mislukt vanwege een uitzondering tijdens de functie van het init gebruikersscript en dat de fout zich continu herhaalt, 3 * process_count_per_node wordt er geen nieuw werkproces gestart.

Volgende stappen