Problemas conocidos

En esta página se describen los problemas conocidos que pueden surgir al usar Batch.

Si necesitas más ayuda para usar Batch, consulta la documentación sobre solución de problemas o ponte en contacto con el equipo de Asistencia.

Es posible que Pub/Sub no envíe notificaciones de estados intermedios durante los cambios rápidos

Es posible que Pub/Sub no envíe notificaciones de todos los estados intermedios cuando un trabajo o una tarea cambien muy rápido. Por ejemplo, supongamos que una tarea cambia rápidamente de estado: ASSIGNED, RUNNING y, después, FAILED. En ese caso, es posible que no recibas ninguna notificación de que la tarea ha alcanzado el estado RUNNING.

Para mitigar este problema, te recomendamos que, cuando quieras ver el historial de estados completo de un trabajo o una tarea, consultes los eventos de estado en lugar de las notificaciones de Pub/Sub.

Para obtener más información sobre las notificaciones de Pub/Sub, consulta Monitorizar el estado de los trabajos con notificaciones de Pub/Sub y BigQuery.

Los registros de tiempo de espera no indican si se ha superado el tiempo de espera de la tarea o del elemento Runnable

Cuando un trabajo falla porque se supera un tiempo de espera, los registros asociados al trabajo no indican si el fallo se ha debido al tiempo de espera de la tarea correspondiente o al tiempo de espera del elemento ejecutable correspondiente.

Para solucionar este problema, defina valores de tiempo de espera diferentes para las tareas y los elementos ejecutables. A continuación, puedes identificar si el error se ha producido por superar el tiempo de espera de la tarea o el elemento ejecutable correspondiente siguiendo este procedimiento:

1. Identifica la tarea, el elemento ejecutable y la hora de un error de tiempo de espera superado.

   1. Consulta los registros de la tarea.

   2. Busca un registro que mencione el código de salida de tiempo de espera superado, 50005. Este registro tiene un textPayload similar al siguiente mensaje:

      Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
      

      En ese registro, anota TASK_INDEX como tarea fallida, RUNNABLE_INDEX como ejecutable fallido y el valor timestamp del registro como la hora del error de tiempo de espera superado.

2. Identifica la hora de inicio de la tarea fallida.

   1. Consulta los eventos de estado de la tarea fallida.

   2. Busca el evento de estado que mencione el siguiente mensaje:

      Task state is updated from ASSIGNED to RUNNING
      

      En ese evento de estado, registra el campo eventTime como la hora de inicio de la tarea fallida.

3. Calcula el tiempo total de ejecución de la tarea fallida, \({failedTaskRunTime}\), con la siguiente fórmula:

   \[{failedTaskRunTime}={failureTime}-{failedTaskStartTime}\]

   Sustituye los siguientes valores:

   • \({failureTime}\): la hora en la que se ha producido el error de tiempo de espera superado.
   • \({failedTaskStartTime}\): la hora de inicio de la tarea fallida.

4. Identifica el tiempo de espera superado:

   • Si \({failedTaskRunTime}\) coincide con el tiempo de espera que has configurado para la tarea fallida, significa que se ha superado el tiempo de espera de esa tarea y se ha producido el fallo.

   • De lo contrario, se ha superado el tiempo de espera que has configurado para el elemento Runnable fallido y se ha producido el error.

Es posible que los trabajos que consumen reservas se retrasen o no se puedan ejecutar

Cuando intentas crear y ejecutar un trabajo que consume reservas de Compute Engine, es posible que Batch retrase o impida incorrectamente que se ejecute. En concreto, Batch requiere que los proyectos tengan suficientes cuotas de recursos de Compute Engine, incluso cuando esas cuotas de recursos se estén usando en reservas no consumidas.

Solucionar el problema

Para solucionar este problema en un trabajo, añada una etiqueta con el nombre goog-batch-skip-quota-check y el valor true al campo labels a nivel de trabajo. Esta etiqueta hace que Batch omita la verificación de las cuotas de recursos de tu proyecto antes de intentar crear un trabajo.

Importante: No se recomienda habilitar la etiqueta goog-batch-skip-quota-check en los trabajos que no puedan usar ninguna reserva de tu proyecto. Por ejemplo, no utilices esta solución alternativa si tu proyecto no tiene ninguna reserva de Compute Engine o si un trabajo requiere VMs que no sean compatibles con esas reservas. De lo contrario, si los trabajos omiten innecesariamente las comprobaciones de cuota, es posible que se produzcan errores de cuota insuficiente innecesarios.

Por ejemplo, para evitar o resolver este problema en un trabajo de script básico que pueda consumir reservas, crea y ejecuta un trabajo con la siguiente configuración JSON:

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [
          {
            "script": {
              "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
            }
          }
        ]
      },
      "taskCount": 3
    }
  ],
  "allocationPolicy": {
    "instances": [
      {
        VM_RESOURCES
      }
    ],
  },
  "labels": {
    "goog-batch-skip-quota-check": "true"
  },
  "logsPolicy": {
    "destination": "CLOUD_LOGGING"
  }
}

Sustituye VM_RESOURCES por los recursos de VM que coincidan con la reserva que quieras que consuma el trabajo.

Para obtener más instrucciones, consulta los artículos Crear y ejecutar un trabajo que pueda consumir máquinas virtuales reservadas y Definir etiquetas personalizadas para el trabajo.

Identificar el problema

Este problema no se indica con ningún mensaje de error específico. En su lugar, este problema puede producirse en las siguientes circunstancias:

• Si tu proyecto reserva todos los recursos para los que tiene cuota, este problema impide que se ejecuten los trabajos que especifican esos recursos.

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

  • Una cuota máxima de 16 GPUs H100.
  • Una reserva de un solo proyecto sin consumir para 2 máquinas virtuales a3-highgpu-8g, que reserva 16 GPUs H100 en total.

  En este caso, este problema impide que tu proyecto programe y ejecute cualquier trabajo que esté configurado correctamente para consumir cualquiera de las GPUs H100 reservadas.

• Si tu proyecto reserva algunos de los recursos para los que tiene cuota, este problema puede impedir o retrasar las tareas que especifican esos recursos.

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

  • Una cuota máxima de 16 GPUs H100.
  • Una reserva de un solo proyecto sin consumir para 1 máquina virtual a3-highgpu-8g, que reserva 8 GPUs H100 en total.
  • Una a3-highgpu-8g VM configurada para no consumir ninguna reserva y que se elimina y se vuelve a crear de vez en cuando. Esta VM usa 8 GPUs H100 sin reservar cuando existe.

  En este caso, este problema solo permite que tu proyecto programe e inicie cualquier trabajo que esté configurado correctamente para consumir cualquiera de las GPUs H100 reservadas cuando la VM a3-highgpu-8g no exista.

Es posible que las tareas fallen al especificar imágenes de SO de VMs de Compute Engine (o personalizadas) con kernels obsoletos

Es posible que un trabajo falle si especifica una imagen de SO de VM de Compute Engine que no tenga la versión más reciente del kernel. Este problema también afecta a las imágenes personalizadas basadas en imágenes de SO de máquinas virtuales de Compute Engine. Las imágenes públicas de Compute Engine que provocan este problema no se pueden identificar fácilmente y están sujetas a cambios en cualquier momento.

Este problema no se indica con un mensaje de error específico. En su lugar, ten en cuenta este problema si tienes un trabajo que falla inesperadamente y especifica una imagen de SO de VM de Compute Engine o una imagen personalizada similar.

Para evitar o solucionar este problema, puedes hacer lo siguiente:

Nota: Si tu trabajo usa GPUs, consulta también Los trabajos que usan GPUs y las imágenes de SO de máquinas virtuales con kernels obsoletos fallan solo cuando se instalan controladores automáticamente.

1. Siempre que sea posible, usa imágenes de lote o imágenes personalizadas basadas en imágenes de lote, que no se ven afectadas por este problema.
2. Si no puedes usar una imagen de Batch, prueba con la última versión de la imagen de Compute Engine que prefieras. Por lo general, las versiones más recientes de las imágenes de Compute Engine tienen más probabilidades de tener la versión más reciente del kernel que las versiones anteriores.
3. Si la versión más reciente de una imagen específica no funciona, es posible que tengas que probar con otro SO o crear una imagen personalizada. Por ejemplo, si la última versión de Debian 11 no funciona, puedes crear una imagen personalizada a partir de una VM de Compute Engine que ejecute Debian 11 y que hayas actualizado para usar la última versión del kernel.

Este problema se debe a que la versión del kernel de la imagen del SO de la VM está obsoleta, lo que provoca que la VM se reinicie. Cuando un trabajo especifica una imagen de SO de VM que no es de Batch o que no se basa en una imagen de Batch, Batch instala los paquetes necesarios en las VMs del trabajo después de que se inicien. Los paquetes necesarios pueden variar en función de los trabajos y cambiar con el tiempo, y es posible que requieran que la imagen del SO de tu máquina virtual tenga la versión más reciente del kernel. Este problema se produce cuando la actualización de la versión del kernel requiere que la VM se reinicie, lo que provoca que la instalación del paquete y el trabajo fallen.

Para obtener más información sobre las imágenes del SO de las VMs, consulta Descripción general del entorno del SO de las VMs de un trabajo.

Es posible que los trabajos que usen GPUs e imágenes de SO de máquinas virtuales con kernels obsoletos solo fallen al instalar controladores automáticamente.

Este problema está estrechamente relacionado con el siguiente: Es posible que los trabajos fallen al especificar imágenes de SO de VMs de Compute Engine (o personalizadas) con kernels obsoletos. En concreto, los trabajos que especifican una imagen de SO de máquina virtual de Compute Engine (o personalizada) sin el kernel más reciente y usan GPUs pueden fallar solo si intentas instalar controladores de GPU automáticamente. En estos casos, también puedes resolver los errores instalando manualmente los controladores de la GPU.

Para obtener más información sobre las GPUs, consulta el artículo Crear y ejecutar un trabajo que use GPUs.