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.

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

Es posible que Pub/Sub no envíe notificaciones para todos los estados intermedios cuando un trabajo o una tarea cambian muy rápido. Por ejemplo, supongamos que una tarea cambia rápidamente de estado de ASSIGNED a RUNNING y, luego, a FAILED. En ese caso, es posible que no recibas una notificación de que la tarea alcanzó el estado RUNNING.

Para mitigar este problema, te recomendamos que, cuando quieras ver el historial de estado 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 Cómo supervisar el estado del trabajo con las notificaciones de Pub/Sub y BigQuery.

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

Cuando un trabajo falla por exceder un tiempo de espera, los registros asociados al trabajo no indican si la falla se debió al tiempo de espera de la tarea pertinente o al tiempo de espera del ejecutable pertinente.

Para solucionar este problema, establece diferentes valores de tiempo de espera para las tareas y los objetos ejecutables. Luego, puedes identificar si una falla se produjo por exceder el tiempo de espera de la tarea o el ejecutable relevantes con el siguiente procedimiento:

1. Identifica la tarea, el ejecutable y la hora de una falla por tiempo de espera excedido.

   1. Visualiza 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, se registra TASK_INDEX como la tarea con errores, RUNNABLE_INDEX como el ejecutable con errores y el valor timestamp del registro como la hora del error por tiempo de espera excedido.

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 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.

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

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

   Reemplaza los siguientes valores:

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

4. Identifica el tiempo de espera excedido:

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

   • De lo contrario, se excedió el tiempo de espera que configuraste para el ejecutable fallido, lo que provocó la falla.

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

Cuando intentas crear y ejecutar un trabajo que consume reservas de Compute Engine, es posible que Batch retrase o impida incorrectamente la ejecución del trabajo. Específicamente, Batch requiere que los proyectos tengan suficientes cuotas de recursos de Compute Engine, incluso cuando esas cuotas de recursos se usen en reservas no consumidas.

Obtén más información sobre este problema de la siguiente manera:

1. Si quieres obtener más información sobre cómo y cuándo este problema afecta los trabajos, consulta Cómo identificar y comprender este problema.
2. Para obtener información sobre cómo prevenir o resolver este problema, consulta Cómo solucionar este problema.

Identifica y comprende este 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 cualquier trabajo que especifique esos recursos.

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

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

  En esta situación, el 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, es posible que este problema impida o retrase los trabajos que especifican esos recursos.

  Por ejemplo, supongamos que tu proyecto tiene lo siguiente:

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

  En esta situación, el 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 existe la VM a3-highgpu-8g.

Soluciona este 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 los trabajos 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 un trabajo requiera VMs que no sean compatibles con esas reservas. De lo contrario, si los trabajos 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 VM que coincidan con la reserva que deseas que consuma el trabajo.

Para obtener más instrucciones, consulta Crea y ejecuta un trabajo que pueda consumir VMs reservadas y Define etiquetas personalizadas para el trabajo.

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 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). Ten en cuenta 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. Si bien este problema puede ocurrir con cualquier imagen de Compute Engine (incluso con la versión más reciente) en cualquier momento, observamos que prevalece principalmente en las imágenes de Debian de Compute Engine.

Obtén más información sobre este problema de la siguiente manera:

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

1. Si quieres obtener más información sobre cómo y cuándo este problema afecta los trabajos, consulta Cómo identificar y comprender este problema.
2. Para obtener información sobre cómo prevenir o resolver este problema, consulta Cómo solucionar este problema.

Identifica y comprende este problema

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

Este problema puede ocurrir en cualquier momento, incluso si usas la versión más reciente de una imagen de Compute Engine. Si un SO se actualizó recientemente, en especial para actualizaciones impredecibles, como correcciones urgentes (actualizaciones urgentes para vulnerabilidades o problemas críticos), es posible que las imágenes de SO de las VMs de Compute Engine aún no hayan podido reaccionar a los cambios. Por ejemplo, observamos que, en el SO Debian, los paquetes con prefijos linux-headers- pueden quitarse del kernel de forma impredecible con correcciones.

Para identificar este problema, te recomendamos que consultes los registros del trabajo y verifiques si hay errores de instalación relacionados con la imagen de SO de tu VM. Por ejemplo, si tu trabajo usa una imagen de Compute Engine de Debian o una imagen personalizada similar, te recomendamos que verifiques si hay errores relacionados con la instalación de paquetes linux-headers- especificando la siguiente consulta:

labels.job_uid="JOB_UID" AND severity="ERROR" AND textPayload:("failed" "apt" "install" "linux-headers-")

Reemplaza JOB_UID por el ID único (UID) del trabajo. Para obtener el UID de un trabajo, describe el trabajo. Si esta consulta devuelve algún resultado, es posible que este problema afecte tu trabajo.

Soluciona este problema

Para evitar o resolver este problema, te recomendamos que hagas lo siguiente:

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. Prueba la versión más reciente de tu imagen de Compute Engine preferida. En general, es más probable que las versiones más recientes de las imágenes de Compute Engine tengan la versión del kernel más reciente que las versiones anteriores.

3. Elige una de las siguientes opciones:

   • Prueba con otro SO o crea una imagen personalizada. Por ejemplo, si la versión más reciente de Debian 12 no funciona, puedes intentar crear una imagen personalizada a partir de una VM de Compute Engine que ejecute Debian 12 y que hayas actualizado para usar la versión más reciente del kernel.

   • Si tu trabajo falla debido a errores relacionados con la instalación de paquetes de linux-headers-, puedes intentar usar la imagen de SO de la VM con paquetes de linux-headers- desactualizados. Para permitir paquetes linux-headers- desactualizados, agrega una etiqueta con el nombre goog-batch-allow-insecure-linux-headers-installation y el valor true al campo labels a nivel del trabajo.

     Precaución: Habilita la etiqueta goog-batch-allow-insecure-linux-headers-installation bajo tu propia responsabilidad. Esta etiqueta permite que tu trabajo intente instalar y usar paquetes linux-headers- archivados. Debido a que los paquetes están desactualizados, es posible que no sean seguros y que expongan tu trabajo a vulnerabilidades o que no tengan actualizaciones críticas.

     Por ejemplo, para permitir paquetes linux-headers- desactualizados para un trabajo de secuencia de comandos básico que especifica una imagen de SO de la VM, crea y ejecuta un trabajo con la siguiente configuración en formato JSON:

     {
       "taskGroups": [
         {
           "taskSpec": {
             "runnables": [
               {
                 "script": {
                   "text": "echo Hello world from task ${BATCH_TASK_INDEX}"
                 }
               }
             ]
           },
           "taskCount": 3
         }
       ],
       "allocationPolicy": {
         "instances": [
           {
             "policy": {
               "bootDisk": {
                 "image": "VM_OS_IMAGE_URI"
               }
             }
           }
         ]
       },
       "labels": {
         "goog-batch-allow-insecure-linux-headers-installation": "true"
       },
       "logsPolicy": {
         "destination": "CLOUD_LOGGING"
       }
     }
     

     Reemplaza VM_OS_IMAGE_URI por el URI de la imagen de SO de la VM que deseas usar.

     Para obtener más instrucciones, consulta Cómo definir etiquetas personalizadas para el trabajo y Cómo especificar la imagen de SO de la VM para un trabajo.

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

Es posible que los trabajos que usan GPU y las imágenes de SO de VM con kernels desactualizados fallen solo cuando se instalan controladores automáticamente

Este problema está estrechamente relacionado con el anterior, Es posible que los trabajos fallen 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 kernel más reciente y que usan GPUs podrían fallar solo si intentas instalar los controladores de GPU automáticamente. Para estos trabajos, también puedes resolver las fallas instalando los controladores de GPU de forma manual.

Para obtener más información sobre este problema y cómo resolverlo, consulta Es posible que los trabajos fallen cuando se especifican imágenes de SO de VM de Compute Engine (o personalizadas) con kernels desactualizados. Para obtener más información sobre las GPUs, consulta Crea y ejecuta un trabajo que use GPUs.