Soluciona problemas de trabajos por lotes lentos o atascados
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se explica cómo solucionar las causas comunes de trabajos por lotes de Dataflow lentos o atascados.
Si tu trabajo por lotes es lento o está bloqueado, usa la pestaña Detalles de la ejecución para encontrar más información sobre el trabajo y, también, identificar la etapa o el trabajador que genera un cuello de botella.
Identifica la causa raíz
Comprueba si el trabajo tiene problemas durante el inicio del trabajador. Para obtener más información, consulta Error de sincronización del Pod.
Para verificar que el trabajo haya comenzado a procesar datos, busca la siguiente entrada de registro en el registro job-message:
All workers have finished the startup processes and began to receive work requests
Para comparar el rendimiento de diferentes trabajos, asegúrate de que el volumen de datos de entrada, la configuración de los trabajadores, el comportamiento del ajuste de escala automático y la configuración de Dataflow Shuffle sean los mismos.
Verifica los registros de job-message para detectar problemas, como límites de cuota, problemas de falta de stock o agotamiento de direcciones IP.
Para identificar un paso lento o atascado, verifica los registros del trabajador en busca de mensajes de Operation ongoing. Consulta el seguimiento de pila para ver dónde se detiene el paso. Para obtener más información, consulta Procesamiento atascado o en curso.
Si Runner v2 está habilitado, verifica los registros de harness para detectar errores. Si deseas obtener más información, consulta Soluciona problemas de Runner v2.
Identifica los rezagados
Un retraso es un elemento de trabajo que es lento en relación con otros elementos de trabajo en la etapa. Para obtener información sobre cómo identificar y corregir rezagados, consulta Solución de problemas de los rezagados en trabajos por lotes.
Identifica etapas lentas o bloqueadas
Para identificar etapas lentas o atascadas, usa la vista Progreso de la etapa.
Las barras más largas indican que la etapa tarda más tiempo. Usa esta vista para identificar las etapas más lentas en tu canalización.
Después de encontrar la etapa de cuello de botella, puedes seguir los siguientes pasos:
Si no hay trabajadores atrasados, identifica el paso más lento mediante el panel Información de la etapa. Usa esta información a fin de identificar candidatos para la optimización del código de usuario.
Para identificar a un trabajador atrasado en una etapa específica, usa la vista Progreso del trabajador. En esta vista, se muestra si todos los trabajadores están procesando el trabajo hasta el final del escenario o si un solo trabajador está atascado en una tarea de retraso. Si encuentras un trabajador atrasado, sigue estos pasos:
Consulta las métricas de uso de CPU y los detalles de progreso del trabajador para los trabajadores atrasados. Si ves un uso de CPU inusualmente alto o bajo, en los archivos de registro de ese trabajador, busca los siguientes problemas:
Para supervisar el rendimiento de la canalización, usa Cloud Profiler.
Algunas transformaciones son más adecuadas para canalizaciones de gran volumen que otras. Los mensajes de registro pueden identificar una transformación de usuario atascado en canalizaciones por lotes o de transmisión.
Para obtener más información sobre un trabajo atascado, usa las métricas del trabajo de Dataflow.
En la siguiente lista, se incluyen métricas útiles:
La métrica Bytes de tareas pendientes (backlog_bytes) mide la cantidad de entradas sin procesar en bytes por etapa. Usa esta métrica para encontrar un paso fusionado que no tenga capacidad de procesamiento.
De manera similar, la métrica de elementos pendientes (backlog_elements) mide la cantidad de elementos de entrada no procesados de una etapa.
La métrica Procesa claves de paralelismo (processing_parallelism_keys) mide la cantidad de claves de procesamiento paralelo para una etapa en particular de la canalización durante los últimos cinco minutos.
Usa esta métrica para investigar de las siguientes maneras:
Limita el problema a etapas específicas y confirma las advertencias de claves de acceso rápido, como A hot key ... was detected.
Detecta cuellos de botella de capacidad de procesamiento causados por un paralelismo insuficiente.
Estos cuellos de botella pueden provocar canalizaciones lentas o atascadas.
La métrica Retraso del sistema (system_lag) y la métrica Retraso del sistema por etapa (per_stage_system_lag) miden la cantidad máxima de tiempo que se procesa un elemento de datos. o en espera de procesamiento. Usa estas métricas para identificar etapas ineficaces y cuellos de botella en las fuentes de datos.
Para obtener métricas adicionales que no están incluidas en la interfaz web de supervisión de Dataflow, consulta la lista completa de métricas de Dataflow en las métricas deGoogle Cloud .
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Troubleshoot slow or stuck batch jobs\n\nThis page explains how to troubleshoot common causes of slow or stuck\nDataflow batch jobs. \n\nIf your batch job is slow or stuck, use the\n[Execution details](/dataflow/docs/concepts/execution-details) tab to find more\ninformation about the job and to identify the stage or worker that's causing a bottleneck.\n\nIdentify the root cause\n-----------------------\n\n1. Check whether the job is running into issues during worker startup. For more\n information, see\n [Error syncing pod](/dataflow/docs/guides/common-errors#error-syncing-pod).\n\n To verify the job has started processing data, look in the\n [job-message](/dataflow/docs/guides/logging#log-types) log for the following\n log entry: \n\n All workers have finished the startup processes and began to receive work requests\n\n2. To compare job performance between different jobs, make sure the volume of\n input data, worker configuration, autoscaling behavior, and\n [Dataflow Shuffle](/dataflow/docs/shuffle-for-batch) settings\n are the same.\n\n3. Check the [job-message](/dataflow/docs/guides/logging#log-types) logs for\n issues such as quota limits, stockout issues, or IP address exhaustion.\n\n4. In the [**Execution details**](/dataflow/docs/concepts/execution-details)\n tab, compare the\n [stage progress](/dataflow/docs/concepts/execution-details#progress-batch)\n to identify stages that took longer.\n\n5. Look for any stragglers in the job. For more information, see\n [Troubleshooting stragglers in batch jobs](/dataflow/docs/guides/troubleshoot-batch-stragglers).\n\n6. Check the throughput, CPU, and memory utilization metrics.\n\n7. Check the [worker logs](/dataflow/docs/guides/logging#log-types) for warnings\n and errors.\n\n - If the worker logs contain errors, view the stack trace. Investigate whether the error is caused by a bug in your code.\n - Look for Dataflow errors. See [Troubleshoot Dataflow errors](/dataflow/docs/guides/common-errors).\n - Look for [out-of-memory errors](/dataflow/docs/guides/troubleshoot-oom#find-errors), which can cause a stuck pipeline. If you see out-of-memory errors, follow the steps in [Troubleshoot Dataflow out of memory errors](/dataflow/docs/guides/troubleshoot-oom).\n - To identify a slow or stuck step, check the worker logs for `Operation ongoing` messages. View the stack trace to see where the step is spending time. For more information, see [Processing stuck or operation ongoing](/dataflow/docs/guides/common-errors#processing-stuck).\n8. [Check for hot keys](#hot-keys).\n\n9. If you aren't using\n [Dataflow Shuffle](/dataflow/docs/shuffle-for-batch), check the\n [shuffler logs](/dataflow/docs/guides/logging#log-types) for warnings and\n errors during shuffle operation. If you see an\n [RPC timeout error](/dataflow/docs/guides/troubleshoot-networking#worker-communicate-firewall-ports)\n on port 12345 or 12346, your job might be missing a firewall rule. See\n [Firewall rules for Dataflow](/dataflow/docs/guides/routes-firewall#firewall_rules).\n\n10. If Runner v2 is enabled, check the\n [harness](/dataflow/docs/guides/logging#log-types) logs for errors. For more\n information, see [Troubleshoot Runner v2](/dataflow/docs/runner-v2#debugging).\n\nIdentify stragglers\n-------------------\n\nA straggler is a work item that is slow relative to other work items in the\nstage. For information about identifying and fixing stragglers, see\n[Troubleshoot stragglers in batch jobs](/dataflow/docs/guides/troubleshoot-batch-stragglers).\n\nIdentify slow or stuck stages\n-----------------------------\n\nTo identify slow or stuck stages, use the\n[**Stage progress**](/dataflow/docs/concepts/execution-details#progress-batch) view.\nLonger bars indicate that the stage takes more time. Use this view to\nidentify the slowest stages in your pipeline.\n\nAfter you find the bottleneck stage, you can take the following steps:\n\n- Identify the [lagging worker](#lagging-worker) within that stage.\n- If there are no lagging workers, identify the slowest step by using the [**Stage info**](/dataflow/docs/concepts/execution-details#stage-info) panel. Use this information to identify candidates for user code optimization.\n- To find parallelism bottlenecks, use [Dataflow monitoring metrics](#debug-tools).\n\nIdentify a lagging worker\n-------------------------\n\nTo identify a lagging worker for a specific stage, use the\n[**Worker progress**](/dataflow/docs/concepts/execution-details#worker-progress)\nview. This view shows whether all workers are processing work until the end of the stage,\nor if a single worker is stuck on a lagging task. If you find a lagging worker,\ntake the following steps:\n\n- View the log files for that worker. For more information, see [Monitor and view pipeline logs](/dataflow/docs/guides/logging#MonitoringLogs).\n- View the [CPU utilization metrics](/dataflow/docs/guides/using-monitoring-intf#cpu-use) and the [worker progress](/dataflow/docs/concepts/execution-details#worker-progress) details for lagging workers. If you see unusually high or low CPU utilization, in the log files for that worker, look for the following issues:\n - [`A hot key ... was detected`](/dataflow/docs/guides/common-errors#hot-key-detected)\n - [`Processing stuck ... Operation ongoing`](/dataflow/docs/guides/common-errors#processing-stuck)\n\nTools for debugging\n-------------------\n\nWhen you have a slow or stuck pipeline, the following tools can help you\ndiagnose the problem.\n\n- To correlate incidents and identify bottlenecks, use [Cloud Monitoring for Dataflow](/dataflow/docs/guides/using-cloud-monitoring).\n- To monitor pipeline performance, use [Cloud Profiler](/dataflow/docs/guides/profiling-a-pipeline).\n- Some transforms are better suited to high-volume pipelines than others. Log messages can [identify a stuck user transform](/dataflow/docs/guides/common-errors#processing-stuck) in either batch or streaming pipelines.\n- To learn more about a stuck job, use [Dataflow job metrics](/dataflow/docs/guides/using-monitoring-intf). The following list includes useful metrics:\n - The [Backlog bytes](/dataflow/docs/guides/using-monitoring-intf#backlog) metric (`backlog_bytes`) measures the amount of unprocessed input in bytes by stage. Use this metric to find a fused step that has no throughput. Similarly, the backlog elements metric (`backlog_elements`) measures the number of unprocessed input elements for a stage.\n - The [Processing parallelism keys](/dataflow/docs/guides/using-monitoring-intf#parallelism) (`processing_parallelism_keys`) metric measures the number of parallel processing keys for a particular stage of the pipeline over the last five minutes. Use this metric to investigate in the following ways:\n - Narrow the issue down to specific stages and confirm hot key warnings, such as [`A hot key ... was detected`](/dataflow/docs/guides/common-errors#hot-key-detected).\n - Find throughput bottlenecks caused by insufficient parallelism. These bottlenecks can result in slow or stuck pipelines.\n - The [System lag](/dataflow/docs/guides/using-monitoring-intf#system_latency_streaming) metric (`system_lag`) and the per-stage system lag metric (`per_stage_system_lag`) measure the maximum amount of time an item of data has been processing or awaiting processing. Use these metrics to identify inefficient stages and bottlenecks from data sources.\n\nFor additional metrics that aren't included in the Dataflow\nmonitoring web interface, see the complete list of Dataflow metrics in\n[Google Cloud metrics](/monitoring/api/metrics_gcp_d_h#gcp-dataflow)."]]