Problemas 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 ejecutable

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

A fin de solucionar este problema, configura diferentes valores de tiempo de espera para las tareas y los ejecutables. Luego, puedes identificar si se produjo una falla porque se superó el tiempo de espera de la tarea relevante o si se puede ejecutar mediante el siguiente procedimiento:

Identifica la tarea, que es ejecutable y el tiempo de una falla de tiempo de espera excedido.
1. Visualiza los registros del trabajo.
2. Busca un registro que mencione el código de salida del tiempo de espera excedido, 50005. Este registro tiene un textPayload que es similar al siguiente mensaje:
```
Task task/JOB_UID-group0-TASK_INDEX/0/0 runnable RUNNABLE_INDEX...exitCode 50005
```
  Desde ese registro, registra TASK_INDEX como la tarea con errores, RUNNABLE_INDEX como el ejecutable con errores y el valor timestamp del registro como la hora de la falla de tiempo de espera excedido.
Identifica la hora de inicio de la tarea con errores.
1. Consulta los eventos de estado de la tarea con errores.
2. Busca el evento de estado que menciona el siguiente mensaje:
```
Task state is updated from ASSIGNED to RUNNING
```
  A partir de ese evento de estado, registra el campo eventTime como la hora de inicio de la tarea con errores.
Calcula el tiempo total de ejecución de la tarea con errores, \({failedTaskRunTime}\), con la siguiente fórmula:

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

Reemplaza los siguientes valores:
- \({failureTime}\): la hora de la falla del tiempo de espera excedido.
- \({failedTaskStartTime}\): la hora de inicio de la tarea con errores.
Identifica el tiempo de espera excedido:
- Si \({failedTaskRunTime}\) coincide con el tiempo de espera que configuraste para la tarea con errores, se superó el tiempo de espera de esa tarea con errores y esta provocó la falla.
- De lo contrario, se superó el tiempo de espera que configuraste para el ejecutable con errores y se generó la falla.

Los trabajos que consumen reservas se pueden retrasar o evitar

Cuando intentas crear y ejecutar un trabajo que consume reservas de Compute Engine, es posible que Batch lo retrase o impida que el trabajo se ejecute. Específicamente, Batch requiere que los proyectos tengan suficientes cuotas de recursos de Compute Engine, incluso cuando las reservas no consumidas usan esas cuotas.

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.

Por ejemplo, para evitar o resolver este problema en un trabajo básico de secuencia de comandos que puede consumir reservas, crea y ejecuta un trabajo con la siguiente configuración de 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 VM que coinciden con la reserva que deseas que consuma el trabajo.

Para obtener más instrucciones, consulta Crea y ejecuta un trabajo que pueda consumir VM reservadas y Define 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 evita cualquier trabajo que especifique esos recursos.

Por ejemplo, supongamos que tu proyecto tiene las siguientes características:
- Una cuota máxima para las GPU H100 de 16.
- Una reserva de un solo proyecto no consumida para 2 VMs a3-highgpu-8g, que reserva 16 GPU H100 en total.
En esta situación, este problema evita que tu proyecto programe y ejecute cualquier trabajo que esté configurado de forma correcta para consumir cualquiera de las GPU H100 reservadas.
Si tu proyecto reserva algunos de los recursos para los que tiene cuota, este problema podría impedir o retrasar trabajos que especifiquen esos recursos.

Por ejemplo, supongamos que tu proyecto tiene las siguientes características:
- Una cuota máxima para las GPU H100 de 16.
- Una reserva de un solo proyecto no consumida para 1 VM a3-highgpu-8g, que reserva 8 GPU H100 en total.
- Una VM a3-highgpu-8g que está configurada para no consumir ninguna reserva y, en ocasiones, se borra y, luego, se vuelve a crear. (Esta VM usa 8 GPU 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 de forma correcta para consumir cualquiera de las GPU H100 reservadas cuando la VM a3-highgpu-8g no existe.

Es posible que los trabajos fallen cuando se especifican imágenes de SO de VM de Compute Engine (o personalizadas) con kernels desactualizados.

Un trabajo puede fallar si especifica una imagen de SO de VM de Compute Engine que no tiene la última versión de kernel. Este problema también afecta a todas las imágenes personalizadas basadas en imágenes de SO de VM de Compute Engine. Las imágenes públicas de Compute Engine que causan este problema no se identifican con facilidad y están sujetas a cambios en ningún momento.

Este problema no se indica con un mensaje de error específico. En cambio, considera este problema si tienes un trabajo que falla de forma inesperada y especifica una imagen de SO de VM de Compute Engine o una imagen personalizada similar.

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

Siempre que sea posible, usa imágenes por lotes o imágenes personalizadas basadas en imágenes por lotes, que no se ven afectadas por este problema.
Si no puedes usar una imagen de Batch, prueba la versión más reciente de tu imagen preferida de Compute Engine. En general, es más probable que las versiones más nuevas de las imágenes de Compute Engine tengan la versión de kernel más reciente que las versiones anteriores.
Si la versión más reciente de una imagen específica no funciona, es posible que debas probar con otro SO 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 desde una VM de Compute Engine que ejecute Debian 11 y que hayas actualizado para usar la última versión de kernel.

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

Si deseas obtener más información sobre las imágenes de SO de VM, consulta la Descripción general del entorno del SO para las VMs de un trabajo.

Los trabajos que usan imágenes de SO de VM y GPU con kernels desactualizados pueden fallar solo cuando se instalan controladores automáticamente.

Este problema está estrechamente relacionado con Los trabajos pueden fallar cuando se especifican imágenes de 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 último kernel y usan GPU pueden fallar solo si intentas instalar los controladores de GPU de forma automática. Para estos trabajos, también puedes resolver las fallas si instalas los controladores de GPU de forma manual.

Para obtener más información sobre las GPU, consulta Crea y ejecuta un trabajo que use GPU.