En esta página, se muestra cómo resolver problemas con las características de ajuste de escala automático de Dataflow y se proporciona información para administrar el ajuste de escala automático.
El trabajo no aumenta ni reduce la escala
En esta sección, se proporciona información sobre situaciones que podrían evitar que los trabajadores aumenten o disminuyan la escala.
El trabajo de transmisión no reduce la escala verticalmente
Cuando tu canalización de transmisión tiene tareas pendientes, los trabajadores no escalan verticalmente.
Este problema se produce cuando las tareas pendientes duran menos de unos minutos o cuando los trabajadores usan menos del 20% de sus CPUs.
A veces, el trabajo pendiente es elevado, pero el uso de CPU es bajo. Agregar trabajadores no mejora el rendimiento debido a que algunas tareas no requieren un alto uso de CPU. En esos casos, Dataflow no escala verticalmente. Para obtener más información, consulta Ajuste de escala automático de transmisión. Esto puede suceder por los siguientes motivos:
- La canalización es E/S intensa.
- La canalización espera llamadas RPC externas.
- Las teclas de acceso rápido causan un uso de CPU desigual de los trabajadores.
- La canalización no tiene suficientes claves.
Los trabajos por lotes y de transmisión no escalan verticalmente
Tu trabajo por lotes o de transmisión se ejecuta como se espera, pero cuando se necesitan más trabajadores, el trabajo no se escala verticalmente.
Este problema puede ocurrir por uno de los siguientes motivos:
- No se puede acceder a los archivos temporales o de etapa de pruebas. Si tu trabajo usa un bucket de Cloud Storage, el bucket puede tener una configuración del ciclo de vida que borra objetos en el bucket. Los objetos borrados incluyen carpetas y archivos de etapa de pruebas y temporales. Para verificar si se borraron los archivos, verifica la configuración del ciclo de vida del depósito. Si se borraron las carpetas o los archivos temporales de etapa de pruebas después de que empezó el trabajo, es posible que los paquetes necesarios para crear nuevos trabajadores no existan. Para resolver este problema, vuelve a crear las carpetas y los archivos en el bucket.
- Las reglas de firewall evitan que los trabajadores envíen y reciban tráfico en los puertos TCP necesarios. Es posible que las reglas de firewall impidan que se inicien los trabajadores. Los trabajadores de Dataflow deben poder enviar y recibir tráfico en los puertos TCP 12345 y 12346. Si deseas obtener más información, incluidos los pasos para resolver este problema, consulta Reglas de firewall para Dataflow.
- Una fuente personalizada tiene un método
getProgress()
que muestra un valor NULL. Cuando usas una fuente personalizada, las métricas de tareas pendientes dependen del valor de retorno del métodogetProgress()
de tu fuente personalizada para comenzar a recopilar datos. La implementación predeterminada paragetProgress()
muestra un valor NULL. Para resolver este problema, asegúrate de que la fuente personalizada anule el métodogetProgress()
predeterminado para mostrar un valor distinto de NULL. - Una actualización activada por el ajuste de escala automático vertical desactiva temporalmente el ajuste de escala automático horizontal. Para obtener más información, consulta Efecto en el ajuste de escala automático horizontal.
- Si usas una operación
map
en una canalización de Python y tu trabajo no escala verticalmente, es posible que debas agregar una transformaciónReshuffle
al código de canalización. Para obtener más información, consulta Redistribuye en la documentación de Apache Beam.
El trabajo de transmisión no reduce la escala
Cuando el trabajo de transmisión tiene una acumulación baja y un uso de CPU bajo, los trabajadores no reducen la escala verticalmente. Este error se puede generar por varios motivos.
Cuando los trabajos no usan Streaming Engine, Dataflow balancea la cantidad de discos persistentes entre los trabajadores. Como resultado, cada trabajador debe tener la misma cantidad de discos persistentes. Por ejemplo, si hay 100 discos y 100 trabajadores, cada trabajador tiene un disco. Cuando el trabajo se reduce, puede tener 50 trabajadores con dos discos persistentes por trabajador. El trabajo no se reduce la escala verticalmente hasta que pueda tener 25 trabajadores con cuatro discos persistentes por trabajador. Además, la cantidad mínima de trabajadores es el valor asignado a
maxNumWorkers
dividido por 15. Si deseas obtener más información, consulta Rango de escalamiento para canalizaciones de ajuste de escala automático de transmisión.Cuando los trabajos usan Streaming Engine, el objetivo de escalamiento descendente se basa en el uso de CPU objetivo del 75%. Cuando no se puede lograr este uso de CPU, el escalamiento descendente está inhabilitado.
El tiempo estimado de trabajo pendiente debe permanecer por debajo de los diez segundos durante al menos dos minutos antes de que los trabajadores reduzcan la escala verticalmente. Las fluctuaciones en el tiempo de tareas pendientes pueden inhabilitar la reducción de la escala verticalmente. Además, una capacidad de procesamiento baja puede sesgar la estimación de tiempo.
PeriodicImpulse
es compatible con las versiones 2.60.0 y posteriores del SDK de Apache Beam. Cuando tu canalización usaPeriodicImpulse
con las versiones 2.59.0 y anteriores del SDK de Apache Beam, los trabajadores de Dataflow no reducen la escala verticalmente como se espera.
Escalamiento vertical de paradas
Tu trabajo por lotes o de transmisión empieza a escalar verticalmente, pero los trabajadores dejan de escalar verticalmente aunque quedan tareas pendientes.
Este problema se produce cuando se alcanzan los límites de cuota.
- Cuotas de Compute Engine: los trabajos de Dataflow están sujetos a la cuota de Compute Engine del proyecto. Si se ejecutan varios trabajos, es posible que el proyecto esté al límite de su cuota de Compute Engine. En ese caso, Dataflow no puede aumentar la cantidad de trabajadores.
- Cuotas de CPU: Los trabajos de Dataflow también están sujetos a la cuota de CPU del proyecto. Si el tipo de trabajador usa más de una CPU, el proyecto podría estar al límite de la cuota de CPU.
- Cuotas de direcciones IP externas: Cuando tu trabajo usa direcciones IP externas para comunicarse con recursos, necesitas tantas direcciones IP externas como trabajadores. Cuando la cantidad de trabajadores escala verticalmente, la cantidad de direcciones IP externas también aumenta. Cuando alcanzas el límite de direcciones IP, los trabajadores dejan de escalar verticalmente.
Además, si la región que eliges no tiene un recurso, no podrás crear recursos nuevos de ese tipo, incluso si queda una cuota restante en tu región o proyecto. Por ejemplo, es posible que aún tengas cuota para crear direcciones IP externas en us-central1
, pero esa región podría no tener direcciones IP disponibles. Para obtener más información, consulta Disponibilidad de cuotas y recursos.
Para resolver este problema, solicita un aumento de la cuota o ejecuta el trabajo en una región diferente.
La sugerencia de uso del trabajador no tiene efecto
Debes establecer la sugerencia de uso del trabajador, pero el comportamiento del ajuste de escala automático no cambia.
Para comprender este problema, ve al gráfico de uso de CPU de los trabajadores y verifica si la sugerencia de uso del trabajador se usa de forma activa. Si se usa la sugerencia, el gráfico muestra CPU utilization hint (actively used by autoscaler)
. De lo contrario, muestra CPU utilization hint (not actively used by autoscaler)
.
La sugerencia de uso es solo un factor que afecta el ajuste de escala automático. En la siguiente tabla, se enumeran algunos motivos por los que el escalador automático podría no usar la sugerencia de forma activa:
Comportamiento de escalamiento observado | Causas | Métricas que se deben verificar |
---|---|---|
Sin cambios |
|
|
Escalamiento vertical |
|
|
Reducción de escala |
|
Para obtener más información, consulta Heurísticas del ajuste de escala automático de transmisión.
Brechas en las métricas del ajuste de escala automático
Hay brechas temporales y temporales en las métricas de ajuste de escala automático.
Este problema puede ocurrir si se reinician las tareas de backend. Estas brechas en las métricas no indican un problema con el ajuste de escala automático o el estado de tu trabajo de transmisión.
La CPU está distribuida de manera desigual
Cuando el trabajo tiene ajuste de escala automático, el uso de CPU se distribuye de manera desigual entre los trabajadores. Algunos trabajadores tienen un uso de CPU, latencia del sistema o actualidad de los datos más altos que otros.
Este problema puede ocurrir si tus datos contienen una clave de acceso rápido. Una clave de acceso rápido es una clave con suficientes elementos para impactar negativamente en el rendimiento de la canalización. Un solo trabajador debe procesar cada clave, por lo que el trabajo no se puede dividir entre los trabajadores.
Para obtener más información, consulta la guía de errores de clave de acceso rápido.
El elemento de trabajo que solicita la lectura del estado ya no es válido en el backend
Durante la comunicación entre instancias de VM de trabajador y tareas de Streaming Engine en una canalización de transmisión, se produce el siguiente error:
The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.
Durante el ajuste de escala automático, las instancias de VM de trabajador se comunican con varias tareas de Streaming Engine, y cada tarea realiza entregas para varias instancias de VM de trabajador. Se usan claves de elementos para distribuir el trabajo. Cada tarea y cada instancia de VM de trabajador tiene una colección de rangos de clave y la distribución de estos rangos puede cambiar de forma dinámica. Por ejemplo, durante el ajuste de escala automático, el cambio de tamaño del trabajo puede hacer que la distribución del rango de claves cambie. Cuando se modifica el rango de una clave, puede ocurrir este error. Se espera que surja el error y, a menos que veas una correlación entre estos mensajes y una canalización con bajo rendimiento, puedes ignorarlo.
Recursos de Streaming Engine insuficientes
Si Streaming Engine no puede asignar el número mínimo de trabajadores que solicitas, se muestra el siguiente error:
Streaming Engine does not currently have enough resources available to fulfill
the request.
Para resolver este problema, intenta configurar una cantidad mínima de trabajadores más pequeña. Consulta Configura el rango del ajuste de escala automático.
Rango de escalamiento para canalizaciones de ajuste de escala automático de transmisión
En esta sección, se proporcionan detalles sobre el rango de escalamiento para las canalizaciones de ajuste de escala automático de transmisión.
Java
Para trabajos de ajuste de escala automático de transmisión que no usen Streaming Engine, el servicio de Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que la cantidad mínima de trabajadores usados para una canalización de ajuste de escala automático es N/15, en la que N es el valor de --maxNumWorkers
.
Para trabajos de ajuste de escala automático de transmisión que usan Streaming Engine, la cantidad mínima de trabajadores es 1.
Dataflow balancea la cantidad de discos persistentes entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes establecer --maxNumWorkers=15
. La canalización escala de manera automática entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que se corresponden con 15, 8, 5, 4, 3, 2 o 1 disco persistente por trabajador, respectivamente.
--maxNumWorkers
puede ser 1,000 como máximo.
Python
Para trabajos de ajuste de escala automático de transmisión que no usen Streaming Engine, el servicio de Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que la cantidad mínima de trabajadores usados para una canalización de ajuste de escala automático es N/15, en la que N es el valor de --max_num_workers
.
Para trabajos de ajuste de escala automático de transmisión que usan Streaming Engine, la cantidad mínima de trabajadores es 1.
Dataflow balancea la cantidad de discos persistentes entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes establecer --max_num_workers=15
. La canalización escala de manera automática entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que se corresponden con 15, 8, 5, 4, 3, 2 o 1 disco persistente por trabajador, respectivamente.
--max_num_workers
puede ser 1,000 como máximo.
Go
Para trabajos de ajuste de escala automático de transmisión que no usen Streaming Engine, el servicio de Dataflow asigna entre 1 y 15 discos persistentes a cada trabajador. Esta asignación significa que la cantidad mínima de trabajadores usados para una canalización de ajuste de escala automático es N/15, en la que N es el valor de --max_num_workers
.
Para trabajos de ajuste de escala automático de transmisión que usan Streaming Engine, la cantidad mínima de trabajadores es 1.
Dataflow balancea la cantidad de discos persistentes entre los trabajadores. Por ejemplo, si tu canalización necesita tres o cuatro trabajadores en estado estable, puedes establecer --max_num_workers=15
. La canalización escala de manera automática entre 1 y 15 trabajadores, con 1, 2, 3, 4, 5, 8 o 15 trabajadores, que se corresponden con 15, 8, 5, 4, 3, 2 o 1 disco persistente por trabajador, respectivamente.
--max_num_workers
puede ser 1,000 como máximo.
Cantidad máxima de trabajadores que puede usar el ajuste de escala automático de transmisión
Java
Dataflow funciona dentro de los límites de la cuota de recuento de instancias de Compute Engine de tu proyecto o maxNumWorkers
, lo que sea menor.
Python
Dataflow funciona dentro de los límites de la cuota de recuento de instancias de Compute Engine de tu proyecto o max_num_workers
, lo que sea menor.
Go
Dataflow funciona dentro de los límites de la cuota de recuento de instancias de Compute Engine de tu proyecto o max_num_workers
, lo que sea menor.
Limita el ajuste de escala automático para reducir el impacto en la facturación
Si no deseas que el ajuste de escala automático aumente la factura, puedes limitar la cantidad máxima de trabajadores que puede usar el trabajo de transmisión.
Java
Cuando especificas --maxNumWorkers
, limitas el rango de escalamiento usado para procesar el trabajo.
Python
Cuando especificas --max_num_workers
, limitas el rango de escalamiento usado para procesar el trabajo.
Go
Cuando especificas --max_num_workers
, limitas el rango de escalamiento usado para procesar el trabajo.
Cambia el rango de escalamiento
Para obtener información sobre cómo cambiar el rango de escalamiento en una canalización de transmisión, consulta Configura el rango de ajuste de escala automático.
Desactiva el ajuste de escala automático en las canalizaciones de transmisión
Para desactivar el ajuste de escala automático en la canalización de transmisión, sigue estos pasos.
Java
Establece --autoscalingAlgorithm=NONE
. Para obtener más información, consulta Inhabilita el ajuste de escala automático horizontal.
Python
Establece --autoscaling_algorithm=NONE
. Para obtener más información, consulta Inhabilita el ajuste de escala automático horizontal.
Go
Establece --autoscaling_algorithm=NONE
. Para obtener más información, consulta Inhabilita el ajuste de escala automático horizontal.
Usa una cantidad fija de trabajadores
Para los trabajos de transmisión que no usan Streaming Engine, el comportamiento predeterminado es usar una cantidad fija de trabajadores. Para usar el ajuste de escala automático de transmisión con estas canalizaciones, debes habilitar la opción de forma explícita, ya que no está activada de forma predeterminada.