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

Errores conocidos

En esta página, se describen algunos problemas conocidos con los que puedes encontrarte al usar por lotes.

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 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 ejecutables. Luego, puedes identificar si una falla se debió a que se superó el tiempo de espera de la tarea o el elemento ejecutable relevante mediante el siguiente procedimiento:

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 excedido el tiempo de espera, 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
```
  En ese registro, registra TASK_INDEX como el tarea con errores, RUNNABLE_INDEX como el se puede ejecutar con errores, y el valor timestamp del registro como la hora de la falla por 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
```
  Desde ese evento de estado, registra el campo eventTime como la hora de inicio de la tarea que falló.
Calcula el tiempo total de ejecución de la tarea con errores, \({failedTaskRunTime}\), mediante la siguiente fórmula:

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

Reemplaza los siguientes valores:
- \({failureTime}\): Es la hora de la falla del tiempo de espera excedido.
- \({failedTaskStartTime}\): Es 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 se superó el tiempo de espera de la tarea con errores y causó de la falla.
- De lo contrario, el tiempo de espera que configuraste para el ejecutable con errores se superó y causó el error.

Es posible que se retrasen o se eviten los trabajos que consumen reservas

Cuando intentas crear y ejecutar un trabajo que consuma reservas de Compute Engine Batch podría retrasar o evitar de forma incorrecta que el trabajo en ejecución. Específicamente, Batch requiere que los proyectos tener 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 de una que puede consumir reservas, crear y ejecutar un trabajo con el 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 coincida con la reserva que quieres que el trabajo consuma.

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 evita cualquier trabajo que especifique esos recursos.

Por ejemplo, supongamos que tu proyecto tiene lo siguiente:
- Una cuota máxima de 16 para las GPUs H100
- Una reserva no consumida de un solo proyecto para 2 VMs a3-highgpu-8g, que reserva 16 GPU H100 en total.
En este caso, este problema impide que tu proyecto programar y ejecutar cualquier trabajo que esté configurado correctamente para consumir cualquiera de las GPU H100 reservadas.
Si tu proyecto reserva algunos de los recursos para los que tiene cuota, puede evitar o retrasar 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 no consumida de un solo proyecto 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 borran y se vuelven a crear. (Esta VM usa 8 GPU H100 sin reservar cuando existe).
En este escenario, este problema solo permite que tu proyecto programe y empezar a ejecutar cualquier trabajo que esté configurado de forma correcta para consumir ninguna de las GPU H100 reservadas cuando la VM a3-highgpu-8g no existen.

Los trabajos pueden fallar cuando se especifican imágenes de 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 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 fácilmente identificables y sujetos a cambios en cualquier 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 un Imagen de SO de la 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 de lotes o imágenes personalizadas que se basen en imágenes de 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 de Compute Engine preferida. 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.
Si la versión más reciente de una imagen específica no funciona, es posible que debas para probar un SO diferente o crear una imagen personalizada. Por ejemplo, si la última versión de Debian 11 no funciona, puedes puede intentar crear una imagen personalizada a partir de una Una VM de Compute Engine que ejecuta Debian 11 y que ya actualizaste para usar la última versión de kernel.

Este problema se debe a una versión de kernel desactualizada en el Imagen de SO de la VM que hace que esta se reinicie. Cuando un trabajo especifica Una imagen de SO de VM que no sea de Batch o que se base en un Imagen por lotes, instalaciones por lotes los paquetes requeridos en las VMs del trabajo después de que se inician. Los paquetes requeridos pueden variar para los distintos trabajos y cambiar con el tiempo, y pueden requerir la imagen de SO de tu VM para tener la versión de kernel más reciente. Aparece este problema cuando la actualización de la versión de kernel requiere que la VM se reinicie, lo que causa la instalación del paquete y el trabajo a fallar.

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

Es posible que las tareas 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 Los trabajos pueden fallar cuando se especifican imágenes de SO de VM de Compute Engine (o personalizadas) con kernels desactualizados. En concreto, los trabajos que especifican un Imagen de SO de VM de Compute Engine (o personalizada) sin el kernel más reciente y usar GPU puede fallar solo si intentas instalar controladores de GPU automáticamente. Para estos trabajos, también puedes resolver las fallas con solo instalando 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.