Soluciona problemas de trabajos lentos o atascados

En esta página, se explica cómo solucionar las causas comunes de trabajos de transmisión y por lotes de Dataflow lentos o atascados

Transmisión

Si observas los siguientes síntomas, es posible que tu trabajo de transmisión de Dataflow se ejecute con lentitud o se detenga:

Usa la información de las siguientes secciones para identificar y diagnosticar el problema.

Identifica la causa raíz

  1. Verifica las métricas de actualidad de los datos y bytes pendientes.

    • Si ambas métricas aumentan de forma monótona, significa que la canalización está atascada y no avanza.
    • Si la actualidad de los datos aumenta, pero los bytes pendientes siguen siendo normales, significa que uno o más elementos de trabajo están atascados en la canalización.

    Busca las etapas en las que aumentan estas métricas para identificar cualquier etapa con problemas y las operaciones que se realizan en ella.

  2. Consulta el gráfico de procesamiento paralelo para ver si alguna etapa está atascada debido a un paralelismo excesivo o insuficiente. Consulta Soluciona problemas de paralelismo.

  3. Revisa los registros de trabajos para detectar problemas, como límites de cuota, problemas de falta de stock o agotamiento de direcciones IP.

  4. Revisa los registros del trabajador para detectar advertencias y errores.

    • Si los registros de trabajador contienen errores, consulta el seguimiento de pila. Investiga si el error se debe a un bug en tu código.
    • Busca errores de Dataflow. Consulta Soluciona errores de Dataflow.
    • Busca errores que indiquen que el trabajo superó un límite, como el tamaño máximo del mensaje de Pub/Sub.
    • Busca errores de memoria insuficiente, que pueden provocar que la canalización se detenga. Si ves errores de memoria insuficiente, sigue los pasos que se indican en Soluciona problemas de errores de memoria insuficiente de Dataflow.
    • 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.

  5. Si un elemento de trabajo está atascado en un trabajador específico, reinicia la VM de ese trabajador.

  6. Si no usas Streaming Engine, consulta los registros del mezclador para ver si hay advertencias y errores. Si ves un error de tiempo de espera de RPC en el puerto 12345 o 12346, es posible que a tu trabajo le falte una regla de firewall. Consulta Reglas de firewall para Dataflow.

  7. Verifica las teclas de acceso rápido.

  8. Si Runner v2 está habilitado, verifica los registros de arnés para detectar errores. Para obtener más información, consulta Soluciona problemas de Runner v2.

Investiga fallas repetidas

En un trabajo de transmisión, algunas fallas se reintentan indefinidamente. Estos reintentos evitan que la canalización progrese. Para identificar fallas repetidas, verifica los registros del trabajador en busca de excepciones.

Identifica a los trabajadores en mal estado

Si los trabajadores que procesan el trabajo de transmisión no están en buen estado, es posible que el trabajo sea lento o aparezca como bloqueado. Para identificar a los trabajadores en mal estado, sigue estos pasos:

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 los trabajos de transmisión.

Soluciona problemas de paralelismo

Para obtener escalabilidad y eficiencia, Dataflow ejecuta las etapas de la canalización en paralelo en varios trabajadores. La unidad más pequeña de procesamiento paralelo en Dataflow es una clave. Los mensajes entrantes para cada etapa fusionada se asocian con una clave. La clave se define de una de las siguientes maneras:

  • La clave se define de forma implícita mediante las propiedades de la fuente, como las particiones de Kafka.
  • La clave se define de manera explícita mediante la lógica de agregación en la canalización, como GroupByKey.

En Dataflow, los subprocesos de trabajadores son responsables de controlar el procesamiento de paquetes de trabajo (mensajes) para una clave. La cantidad de subprocesos disponibles para procesar las claves del trabajo es igual a num_of_workers * threads_per_worker. El recuento de subprocesos por trabajador se determina en función del SDK (Java, Python o Go) y el tipo de trabajo (por lotes o de transmisión).

Si la canalización no tiene suficientes claves para una etapa determinada, limita el procesamiento paralelo. Esa etapa podría convertirse en un cuello de botella.

Si la canalización usa una gran cantidad de claves para una etapa determinada, puede limitar el rendimiento de la etapa y acumular un backlog en las etapas anteriores, ya que hay cierta sobrecarga por clave. La sobrecarga puede incluir la comunicación del backend con los trabajadores, las RPC externas a un receptor, como BigQuery, y otros procesamientos. Por ejemplo, si procesar una clave con un mensaje lleva 100 ms, también podría llevar alrededor de 100 ms procesar 1,000 mensajes en ese paquete de claves.

Identifica etapas con paralelismo bajo

Para identificar si la lentitud de la canalización se debe a un paralelismo bajo, consulta las métricas de uso de CPU. Si la CPU es baja, pero se distribuye de manera uniforme entre los trabajadores, es posible que tu trabajo tenga un paralelismo insuficiente. Si el trabajo usa Streaming Engine, para ver si una etapa tiene un paralelismo bajo, en la pestaña Métricas del trabajo, consulta las métricas de paralelismo. Para mitigar este problema:

Identifica etapas con paralelismo alto

Una combinación de baja latencia del sistema, aumento de la actualidad de los datos y aumento de la cantidad de tareas pendientes y de las CPU de los trabajadores subutilizadas sugiere que la canalización se limita debido a una gran cantidad de claves. Consulta el gráfico de procesamiento paralelo para identificar las etapas con una gran cantidad de claves.

Las transformaciones como Reshuffle pueden generar millones de claves si no especificas withNumBuckets de forma explícita. Una gran cantidad de claves puede generar numerosos paquetes de trabajo más pequeños, cada uno de los cuales requiere un subproceso de trabajador dedicado para procesarse. Dado que los subprocesos de trabajador disponibles son limitados, esto puede generar una acumulación significativa de claves de procesamiento, lo que provoca demoras mientras esperan recursos. Como resultado, los subprocesos de trabajo no se usan de manera eficiente.

Recomendamos limitar la cantidad de claves configurando la opción withNumBuckets en la transformación Reshuffle. El valor no debe exceder la cantidad total de subprocesos en todos los trabajadores. Es posible que las claves de segmentación (threads_per_worker * max_workers) de la canalización no sean óptimas. A veces, es posible usar menos claves y paquetes más grandes, y Dataflow los procesa de manera más eficiente porque usa menos trabajadores. Una menor cantidad de claves crea paquetes de trabajo más grandes, lo que usa de manera eficiente los subprocesos de trabajo y aumenta la capacidad de procesamiento de la etapa.

Si hay varios pasos Reshuffle en la canalización, divide la cantidad total de subprocesos por la cantidad de pasos Reshuffle para calcular withNumBuckets.

Verifica las teclas de acceso rápido

Si las tareas están distribuidas de manera desigual entre los trabajadores y el uso de los trabajadores es muy desigual, es posible que la canalización tenga una clave de acceso rápido. Una clave de acceso rápido es una clave que tiene muchos más elementos para procesar en comparación con otras claves.

Verifica las teclas de acceso rápido con el siguiente filtro de registro:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Reemplaza JOB_ID por el ID de tu trabajo.

Para resolver este problema, realiza uno o más de los siguientes pasos:

  • Cambia la clave de tus datos. Para generar pares clave-valor nuevos, aplica una transformación ParDo. Para obtener más información, consulta la página de transformación ParDo de Java o la página de transformación ParDo de Python en la documentación de Apache Beam.
  • Usa .withFanout en tus transformaciones de combinación Para obtener más información, consulta la clase Combine.PerKey en el SDK de Java o la operación with_hot_key_fanout en el SDK de Python.
  • Si tienes una canalización de Java que procesa PCollections de gran volumen y no delimitadas, te recomendamos que hagas lo siguiente:
    • Usar Combine.Globally.withFanout en lugar de Combine.Globally
    • Usar Combine.PerKey.withHotKeyFanout en lugar de Count.PerKey

Comprueba que no hay una cuota insuficiente

Asegúrate de tener suficiente cuota para tu fuente y receptor. Por ejemplo, si tu canalización lee la entrada desde Pub/Sub o BigQuery, tu Google Cloud proyecto puede tener una cuota insuficiente. Para obtener más información sobre los límites de cuota de estos servicios, consulta Cuota de Pub/Sub o Cuota de BigQuery.

Si tu trabajo genera una gran cantidad de errores 429 (Rate Limit Exceeded), puede que tenga una cuota insuficiente. Para verificar si hay errores, prueba los siguientes pasos:

  1. Ve a la consola deGoogle Cloud .
  2. En el panel de navegación, haz clic en API y servicios.
  3. En el menú, haz clic en Biblioteca.
  4. Usa el cuadro de búsqueda para buscar Pub/Sub.
  5. Haz clic en API de Cloud Pub/Sub.
  6. Haz clic en Administrar.
  7. En el gráfico Tráfico por código de respuesta, busca códigos de error de cliente (4xx).

También puedes usar el Explorador de métricas para verificar el uso de la cuota. Si tu canalización usa una fuente o un receptor de BigQuery para solucionar problemas de cuota, usa las métricas de la API de BigQuery Storage. Por ejemplo, para crear un gráfico que muestre el recuento de conexiones simultáneas de BigQuery, sigue estos pasos:

  1. En la consola de Google Cloud , selecciona Monitoring:

    Ir a Monitoring

  2. En el panel de navegación, selecciona   Explorador de métricas.

  3. En el panel Selecciona una métrica, para filtrar a un Métrica, Proyecto de BigQuery > escribe > recuento de conexiones simultáneas.

Para obtener instrucciones sobre cómo ver las métricas de Pub/Sub, consulta Supervisa el uso de cuota en “Supervisa Pub/Sub en Cloud Monitoring”. Si deseas obtener instrucciones para ver las métricas de BigQuery, consulta Visualiza el uso y los límites de cuotas en “Crea paneles, gráficos y alertas”.

Por lotes

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

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

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

  3. Verifica los registros de job-message para detectar problemas, como límites de cuota, problemas de falta de stock o agotamiento de direcciones IP.

  4. En la pestaña Detalles de ejecución, compara el progreso de la etapa para identificar las etapas que tardaron más.

  5. Busca cualquier rezagado en el trabajo. Para obtener más información, consulta Solución de problemas de rezagados en trabajos por lotes.

  6. Verifica las métricas de capacidad de procesamiento, CPU y uso de memoria.

  7. Revisa los registros del trabajador para detectar advertencias y errores.

  8. Verifica las teclas de acceso rápido.

  9. Si no usas Dataflow Shuffle, consulta los registros del mezclador para ver las advertencias y los errores durante la operación de mezcla. Si ves un error de tiempo de espera de RPC en el puerto 12345 o 12346, es posible que a tu trabajo le falte una regla de firewall. Consulta Reglas de firewall para Dataflow.

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

Identifica a un trabajador que se retrasa

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:

Herramientas para la depuración

Cuando tienes una canalización lenta o atascada, las siguientes herramientas pueden ayudarte a diagnosticar el problema.

  • Para correlacionar incidentes y, también, identificar cuellos de botella, usa Cloud Monitoring para Dataflow.
  • 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 .