Errores conocidos

En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas Batch.

Si necesitas más ayuda para usar Batch, consulta la documentación de Solución de problemas o Obtén asistencia.

Los registros de tiempos de espera no indican si se superó el tiempo de espera de la tarea o del elemento ejecutable.

Cuando una tarea falla debido a que se superó un tiempo de espera, los registros asociados con la tarea no indican si el error se debió al tiempo de espera de la tarea relevante o al tiempo de espera del elemento ejecutable relevante.

Para solucionar este problema, establece diferentes valores de tiempo de espera para las tareas y los elementos ejecutables. Luego, puedes identificar si una falla se debió a que se superó el tiempo de espera de la tarea o el elemento ejecutable relevantes mediante el siguiente procedimiento:

1. Identifica la tarea, el elemento ejecutable y el tiempo de una falla de tiempo de espera superior.

   1. Consulta los registros del trabajo.

   2. Busca un registro que mencione el código de salida de tiempo de espera excedido, 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, registra TASK_INDEX como la tarea que falló, RUNNABLE_INDEX como el elemento ejecutable que falló y el valor timestamp del registro como la hora de la falla por tiempo de espera excedido.

2. Identifica la hora de inicio de la tarea que falló.

   1. Consulta los eventos de estado de la tarea que falló.

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

      Task state is updated from ASSIGNED to RUNNING
      

      Desde ese evento de estado, registra el campo eventTime como la hora de inicio de la tarea que falló.

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

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

   Reemplaza los siguientes valores:

   • \({failureTime}\): Es la hora de la falla de tiempo de espera excedido.
   • \({failedTaskStartTime}\): Es la hora de inicio de la tarea que falló.

4. Identifica el tiempo de espera excedido:

   • Si \({failedTaskRunTime}\) coincide con el tiempo de espera que configuraste para la tarea que falló, significa que se superó el tiempo de espera de esa tarea y se produjo el error.

   • De lo contrario, se superó el tiempo de espera que configuraste para el elemento ejecutable que falló y causó el error.

Es posible que se retrasen o se eviten las tareas que consumen reservas.

Cuando intentas crear y ejecutar un trabajo que consume reservas de Compute Engine, es posible que el procesamiento por lotes retrase o impida incorrectamente que se ejecute el trabajo. Específicamente, Batch requiere que los proyectos tengan cuotas de recursos de Compute Engine suficientes, incluso cuando esas cuotas de recursos estén siendo utilizadas por reservas no consumidas.

Soluciona el problema

Para solucionar este problema en un trabajo, agrega una etiqueta con el nombre goog-batch-skip-quota-check y el valor true al campo labels a nivel del 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 para las tareas que no pueden consumir ninguna reserva en tu proyecto. Por ejemplo, evita esta solución alternativa cuando tu proyecto no tenga ninguna reserva de Compute Engine o cuando una tarea requiera VMs que no sean compatibles con esas reservas. De lo contrario, si las tareas omiten innecesariamente las verificaciones de cuota, es posible que veas errores de cuota insuficiente innecesarios.

Por ejemplo, para evitar o resolver este problema en un trabajo de secuencia de comandos básico que puede 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"
  }
}

Reemplaza VM_RESOURCES por los recursos de la VM que coinciden con la reserva que deseas que consuma la tarea.

Para obtener más instrucciones, consulta Cómo crear y ejecutar un trabajo que pueda consumir VMs reservadas y Cómo definir etiquetas personalizadas para el trabajo.

Identifica el problema

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

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

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

  • Una cuota máxima de 16 para las GPUs H100
  • Una reserva de un solo proyecto no consumida para 2 VMs a3-highgpu-8g, que reserva 16 GPUs H100 en total.

  En esta situación, 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 podría impedir o retrasar las tareas que especifiquen esos recursos.

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

  • Una cuota máxima de 16 para las GPUs H100
  • Una reserva de un solo proyecto no consumida para 1 VM a3-highgpu-8g, que reserva 8 GPUs H100 en total.
  • Una VM de a3-highgpu-8g que está configurada para no consumir ninguna reserva y que, ocasionalmente, se borra y se vuelve a crear. (Esta VM usa 8 GPUs H100 no reservadas cuando existe).

  En esta situación, este problema solo permite que tu proyecto programe y comience a ejecutar cualquier trabajo que esté configurado correctamente para consumir cualquiera de las GPUs H100 reservadas cuando no exista la VM de a3-highgpu-8g.

Es posible que las tareas fallen cuando se especifiquen imágenes del SO de VM de Compute Engine (o personalizadas) con kernels desactualizados.

Es posible que una tarea falle si especifica una imagen de SO de VM de Compute Engine que no tiene la versión más reciente del kernel. Este problema también afecta a las imágenes personalizadas que se basan en imágenes del SO de las VMs de Compute Engine. Las imágenes públicas de Compute Engine que causan este problema no se identifican 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, considera este problema si tienes un trabajo que falla de forma inesperada y especifica una imagen del SO de VM de Compute Engine o una imagen personalizada similar.

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

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

1. Siempre que sea posible, usa imágenes de lotes o imágenes personalizadas basadas en imágenes de lotes, que no se ven afectadas por este problema.
2. Si no puedes usar una imagen de Batch, prueba la versión más reciente de tu imagen preferida de Compute Engine. Por lo general, es más probable que las versiones más recientes de las imágenes de Compute Engine tengan 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 debas probar un SO diferente o crear una imagen personalizada. Por ejemplo, si la versión más reciente de Debian 11 no funciona, puedes intentar crear una imagen personalizada a partir de una VM de Compute Engine que ejecute Debian 11 y que hayas actualizado para usar la versión más reciente del kernel.

Este problema se debe a una versión de kernel desactualizada en la imagen del SO de la VM que hace que esta se reinicie. Cuando un trabajo especifica cualquier imagen del SO de VM que no sea de Batch o que se base en una imagen de Batch, Batch instala los paquetes necesarios en las VMs del trabajo después de que se inician. Los paquetes necesarios pueden variar según los trabajos y cambiar con el tiempo, y es posible que requieran que la imagen del SO de la VM tenga la versión más reciente del kernel. Este problema aparece cuando la actualización de la versión del kernel requiere que se reinicie la VM, lo que hace que falle la instalación del paquete y la tarea.

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 usan GPUs y las imágenes del SO de VM con kernels desactualizados fallen solo cuando se instalan controladores automáticamente.

Este problema está estrechamente relacionado con el problema Las tareas pueden fallar cuando se especifican imágenes del SO de VM de Compute Engine (o personalizadas) con kernels desactualizados. Específicamente, los trabajos que especifican una imagen de SO de VM 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. Para estas tareas, también puedes resolver las fallas con solo instalar los controladores de GPU de forma manual.

Para obtener más información sobre las GPUs, consulta Cómo crear y ejecutar una tarea que use GPUs.