Se usó la API de Cloud Translation para traducir esta página.

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:

La canalización no lee datos de la fuente. Por ejemplo, Pub/Sub tiene un trabajo pendiente en aumento.
La canalización no escribe datos en el receptor.
La métrica de actualidad de los datos está aumentando.
La métrica de latencia del sistema aumenta.

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

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.

Si la excepción es con el código de usuario, depura y corrige el problema en el código o en los datos.
Para evitar fallas inesperadas que detengan tu canalización, implementa una cola de mensajes no entregados. Para ver una implementación de ejemplo, consulta Patrones de BigQuery en la documentación de Apache Beam.
Si la excepción es un error de memoria insuficiente (OOM), consulta Soluciona problemas de errores de memoria insuficiente de Dataflow.
Para obtener información sobre otras excepciones, consulta Soluciona errores de Dataflow.

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:

Verifica la presión de memoria mediante las métricas de uso de memoria y busca errores de memoria insuficiente en los registros del trabajador. Para obtener más información, consulta Cómo solucionar problemas de errores de memoria en Dataflow.
Si usas Streaming Engine, usa las métricas de persistencia para identificar los cuellos de botella con las operaciones de entrada y salida del disco (IOPS).
Revisa los registros del trabajador para detectar otros errores. Para obtener más información, consulta Trabaja con registros de canalización y Soluciona errores de Dataflow.

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 insuficiente

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 Pub/Sub.
La clave se define de manera explícita mediante la lógica de agregación en la canalización, como GroupByKey.

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.

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:

En la consola de Google Cloud, en la página Información del trabajo, usa la pestaña Ajuste de escala automático para ver si el trabajo tiene problemas de escalamiento vertical. Si el ajuste de escala automático es el problema, consulta Soluciona problemas del ajuste de escala automático de Dataflow.
Usa el grafo de trabajo para verificar los pasos en la etapa. Si la etapa lee de una fuente o escribe en un receptor, revisa la documentación del servicio de la fuente o del receptor. Usa la documentación a fin de determinar si ese servicio está configurado para una escalabilidad suficiente.
- Para recopilar más información, usa las métricas de entrada y salida que proporciona Dataflow.
- Si usas Kafka, revisa la cantidad de particiones de Kafka. Para obtener más información, consulta la documentación de Apache Kafka.
- Si usas un receptor de BigQuery, habilita la fragmentación automática para mejorar el paralelismo. Para obtener más información, consulta Capacidad de procesamiento de Dataflow 3 veces mayor con Fragmentación automática para BigQuery.

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. 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 proyecto de Google Cloud 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:

Ve a la consola de Google Cloud.
En el panel de navegación, haz clic en API y servicios.
En el menú, haz clic en Biblioteca.
Usa el cuadro de búsqueda para buscar Pub/Sub.
Haz clic en API de Cloud Pub/Sub.
Haz clic en Administrar.
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:

En la consola de Google Cloud, selecciona Monitoring:

Ir a Monitoring
En el panel de navegación, selecciona Explorador de métricas.
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 los rezagados

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 el trabajador atrasado dentro de esa etapa.
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 detectar cuellos de botella de paralelismo, usa las métricas de supervisión de Dataflow.

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:

Consulta los archivos de registro de ese trabajador. Para obtener más información, consulta Supervisa y visualiza los registros de canalización.
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:
- A hot key ... was detected
- Processing stuck ... Operation ongoing

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 la página sobre métricas de Google Cloud.