Cómo solucionar problemas

Encontrar la causa de los errores que surgen cuando entrenas tu modelo o cuando obtienes predicciones en la nube puede ser un desafío. En esta página, se describe cómo encontrar y depurar problemas.

Herramienta de línea de comandos

ERROR: (gcloud) Opción no válida: 'ml-engine'.

Este error significa que debes actualizar gcloud. Para actualizar gcloud, ejecuta el siguiente comando:

gcloud components update

Cómo usar registros de trabajos

Un buen primer lugar para comenzar a solucionar problemas son los registros de trabajo capturados por Stackdriver Logging.

Logging para diferentes tipos de operación

Tu experiencia de registro varía según el tipo de operación, como se muestra en las secciones a continuación.

Registros de entrenamiento

Todos tus trabajos de entrenamiento se registran. Los registros incluyen eventos del servicio de entrenamiento y de tu aplicación de entrenamiento. Puedes colocar los eventos de registro en tu aplicación con bibliotecas de Python estándar (logging, por ejemplo). Cloud ML Engine captura todos los mensajes de registro desde tu aplicación. Todos los mensajes enviados a stderr se capturan automáticamente en tu entrada de trabajo en Stackdriver Logging.

Registros de predicción por lotes

Se registran todos tus trabajos de predicción por lotes.

Registros de predicción en línea

Tus solicitudes de predicción en línea no generan registros de manera predeterminada. Puedes habilitar Stackdriver Logging cuando creas tu recurso de modelo:

gcloud

Incluye la marca --enable-logging cuando ejecutas gcloud ml-engine models create.

Python

Configura onlinePredictionLogging en True en el recurso Model que usas para tu llamada a projects.models.create.

Cómo buscar los registros

Tus registros de trabajos contienen todos los eventos para tu operación, incluidos los eventos de todos los procesos en tu clúster cuando estás usando el entrenamiento distribuido. Si ejecutas un trabajo de entrenamiento distribuido, tus registros a nivel del trabajo se informan para el proceso de trabajador principal. El primer paso para solucionar problemas de un error es, generalmente, examinar los registros para ese proceso y filtrar los eventos registrados para otros procesos en tu clúster. Los ejemplos en esta sección muestran ese filtro.

Puedes filtrar los registros desde la línea de comandos o en la sección de Stackdriver Logging de tu Google Cloud Platform Console. En cualquier caso, usa estos valores de metadatos en tu filtro según sea necesario:

Elemento de metadatos Filtro para mostrar elementos donde es…
resource.type Igual a "cloud_ml_job".
resource.labels.job_id Igual a tu nombre de trabajo.
resource.labels.task_name Igual a "master-replica-0" para leer solo las entradas del registro para tu trabajador principal.
gravedad Mayor o igual que ERROR para leer solo las entradas de registro que corresponden a las condiciones de error.

Línea de comandos

Usa la lectura de registros Beta de gcloud para construir una consulta que satisfaga tus necesidades. A continuación, se incluyen algunos ejemplos:

Cada ejemplo se basa en estas variables de entorno:

PROJECT="my-project-name"
JOB="my_job_name"

Si lo prefieres, puedes ingresar la string literal en su lugar.

Para imprimir tus registros de trabajos en la pantalla:
gcloud ml-engine jobs stream-logs $JOB

Consulta todas las opciones para gcloud ml-engine jobs stream-logs.

Para imprimir tu registro para tu trabajador principal en la pantalla:
gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\""
Para imprimir solo errores registrados para tu trabajador principal en la pantalla:
gcloud beta logging read --project=${PROJECT} "resource.type=\"ml_job\" and resource.labels.job_id=${JOB} and resource.labels.task_name=\"master-replica-0\" and severity>=ERROR"

Los ejemplos anteriores representan los casos más comunes de filtrado para los registros de tu trabajo de entrenamiento de Cloud ML Engine. Stackdriver Logging ofrece muchas opciones poderosas para el filtrado que puedes usar si necesitas definir mejor tu búsqueda. La documentación de filtrado avanzado describe esas opciones en detalle.

Console

  1. Abre la página Jobs (Trabajos) de Cloud ML Engine en GCP Console.

    Abrir trabajos en GCP Console

  2. Selecciona el trabajo que falló de la lista en la página Jobs (Trabajos) para ver los detalles.

La lista de trabajos de Cloud ML Engine que muestra un trabajo con errores

  1. Haz clic en View logs (Ver registros) para abrir Stackdriver Logging.

La páginas de detalles de trabajo para un trabajo con errores

También puedes ir directamente a Stackdriver Logging, pero tienes el paso adicional de buscar tu trabajo:

  1. Expande el selector de recursos.
  2. Expande job de Cloud ML Engine (trabajo de Cloud ML Engine) en la lista de recursos.
  3. Busca el nombre de tu trabajo en la lista job_id (puedes ingresar las primeras letras del nombre del trabajo en el cuadro de búsqueda para reducir los trabajos que se muestran).
  4. Expande la entrada de trabajo y selecciona master-replica-0 de la lista de tareas.

Los selectores de filtro de registro expandidos completamente

Cómo obtener información de los registros

Luego de que hayas encontrado el registro correcto y lo hayas filtrado a master-replica-0, puedes examinar los eventos registrados para buscar el origen del problema. Esto implica un procedimiento estándar de depuración de Python, pero vale la pena recordar lo siguiente:

  • Los eventos tienen varios niveles de gravedad. Puedes filtrar para ver solo los eventos de un nivel en particular, como errores, o errores y advertencias.
  • Un problema que causa que tu entrenador salga con una condición de error irrecuperable (código de retorno > 0) se registra como una excepción precedida por un seguimiento de pila:

Una entrada de registro sin secciones expandidas

  • Puedes obtener más información si expandes los objetos en el mensaje JSON registrado (se indica por una flecha orientada hacia la derecha y los contenidos se enumeran como {…}). Por ejemplo, puedes expandir jsonPayload para ver el seguimiento de pila de una forma más legible de la que se muestra en la descripción principal del error:

Una entrada de registro con su sección de carga útil JSON expandida

  • Algunos errores muestran instancias de errores que se pueden intentar nuevamente. Por regla general, estos no incluyen una pila de seguimiento y puede ser más difícil diagnosticarlos.

Cómo aprovechar el registro al máximo

El servicio de entrenamiento de Cloud ML Engine registra automáticamente estos eventos:

  • Información de estado interna al servicio
  • Mensajes que tu aplicación de entrenador envía a stderr
  • Texto de salida que tu aplicación de entrenador envía a stdout

Puedes hacer que los errores de la solución de problemas en tu aplicación de entrenador sean más fáciles si sigues las prácticas recomendadas de programación:

  • Envía mensajes significativos a stderr (con logging, por ejemplo).
  • Plantea la excepción más lógica y descriptiva cuando algo sale mal.
  • Agrega strings descriptivas a tus objetos de excepción.

La documentación de Python proporciona más información sobre las excepciones.

Cómo solucionar problemas de entrenamiento

En esta sección, se describen conceptos y condiciones de error que aplican a los trabajos de entrenamiento.

Cómo entender los códigos de retorno de la aplicación de entrenamiento

Tu trabajo de entrenamiento en la nube está controlado por el programa principal que se ejecuta en el proceso de trabajador principal de tu clúster de entrenamiento:

  • Si estás entrenando en un solo proceso (no distribuido), solo tienes un único trabajador, que es el principal.
  • Tu programa principal es la función __main__ de tu aplicación de entrenamiento de TensorFlow.
  • El servicio de entrenamiento de Cloud ML Engine ejecuta tu aplicación de entrenador hasta que se completa con éxito o encuentra un error irrecuperable. Esto significa que puede reiniciar los procesos si surgen errores que se pueden intentar nuevamente.

El servicio de entrenamiento administra tus procesos. Controla una salida del programa según el código de retorno de tu proceso de trabajador principal:

Código de retorno Significado Respuesta de Cloud ML Engine
0 Realización exitosa Cierra y libera los recursos de trabajos.
1 - 128 Error irrecuperable Finaliza el trabajo y registra el error.

No necesitas hacer nada en particular con respecto al código de retorno de tu función __main__. Python muestra automáticamente cero en una realización exitosa y muestra un código positivo cuando encuentra una excepción no controlada. Si estás acostumbrado a configurar códigos de retorno específicos para tus objetos de excepción (una práctica válida, pero poco común), no interferirá con tu trabajo de Cloud ML Engine, siempre que sigas el patrón en la tabla anterior. Aun así, el código de cliente normalmente no indica errores que se pueden intentar nuevamente, sino que provienen del entorno operativo.

Cómo controlar condiciones de error específicas

En esta sección, se proporciona orientación sobre algunas condiciones de error que se sabe afectan a algunos usuarios.

Se agotó el recurso

La demanda es alta para GPU y los recursos de procesamiento en la región us-central1. Es posible que obtengas un mensaje de error en tus registros de trabajo que diga: Resources are insufficient in region: <region>. Please try a different region.

Para resolver esto, prueba usar una región diferente o vuelve a intentar más tarde.

El entrenador se ejecuta constantemente sin lograr ningún progreso

Algunas situaciones pueden provocar que tu aplicación de entrenador se ejecute continuamente mientras no se logra ningún progreso en la tarea de entrenamiento. Esto puede deberse a una llamada de bloqueo que espera por un recurso que nunca está disponible. Puedes mitigar este problema si configuras un intervalo de tiempo de espera en tu entrenador.

Configura un intervalo de tiempo de espera para tu entrenador

Puedes configurar un tiempo de espera, en milisegundos, cuando creas tu sesión o cuando ejecutas un paso de tu grafo:

  • Configura el intervalo de tiempo de espera deseado mediante el uso del parámetro config cuando creas tu objeto de Sesión:

    sess = tf.Session(config=tf.ConfigProto(operation_timeout_in_ms=500))
    
  • Configura el intervalo de tiempo de espera deseado para una llamada a Session.run mediante el uso del parámetro opciones:

    v = session.run(fetches, options=tf.RunOptions(timeout_in_ms=500))
    

Consulta la documentación de Sesión de TensorFlow para obtener más información.

El programa sale con un código de -9

Si obtienes el código de salida -9 continuamente, tu aplicación de entrenador podría estar usando más memoria de la que está asignada para su proceso. Soluciona este error reduciendo el uso de memoria, con los tipos de máquinas con más memoria, o ambos.

  • Revisa tu aplicación de entrenador y grafo para las operaciones que usan más memoria de lo que se había previsto. El uso de memoria se ve afectado por la complejidad de tus datos y la de las operaciones en tu grafo de cómputo.
  • El aumento de la memoria asignada a tu trabajo puede necesitar cierta delicadeza:
    • Si usas un nivel de escala definido, no puedes aumentar tu asignación de memoria por máquina sin agregar más máquinas a la combinación. Tendrás que cambiar al nivel CUSTOM y definir los tipos de máquina en el clúster tú mismo.
    • La configuración precisa de cada tipo de máquina definido está sujeta a cambios, pero puedes hacer algunas comparaciones aproximadas. Encontrarás una tabla comparativa de los tipos de máquina en la página de conceptos de entrenamiento.
    • Cuando pruebas los tipos de máquina para la asignación de memoria adecuada, es posible que quieras usar una sola máquina, o un clúster de tamaño reducido, para minimizar los cargos producidos.

El programa sale con un código de -15

Normalmente, un código de salida de -15 indica el mantenimiento por parte del sistema. Es un error que se puede intentar nuevamente, por lo que tu proceso debe reiniciarse automáticamente.

Trabajo en cola durante mucho tiempo

Si el Estado de un trabajo de entrenamiento es QUEUED por un período prolongado, es posible que hayas excedido tu cuota de solicitudes de trabajo.

Cloud ML Engine inicia los trabajos de entrenamiento en función de la hora de creación del trabajo, mediante el uso de la regla primero en entrar, primero en salir. Si tu trabajo está en cola, generalmente quiere decir que toda la cuota del proyecto es consumida por otros trabajos que se enviaron antes de que tu trabajo o el primer trabajo en la cola solicitó más unidades del AA/GPU que la cuota disponible.

La razón por la que un trabajo ha sido puesto en cola se registra en los registros de entrenamiento. Busca en el registro mensajes similares a:

This job is number 2 in the queue and requires
4.000000 ML units and 0 GPUs. The project is using 4.000000 ML units out of 4
allowed and 0 GPUs out of 10 allowed.

El mensaje explica la posición actual de tu trabajo en la cola y la cuota, y el uso actual del proyecto.

Ten en cuenta que la razón será registrada solo para los primeros diez trabajos en cola ordenados por la hora de creación del trabajo.

Si regularmente necesitas más que el número asignado de solicitudes, puedes solicitar un aumento de la cuota. Comunícate con el equipo de asistencia si tienes un paquete de asistencia premium. De lo contrario, puedes enviar tu solicitud por correo electrónico a los comentarios de Cloud ML Engine.

Se superó la cuota

Si recibes un error con un mensaje como "Fallo de cuota para project_number…", es posible que hayas excedido una de tus cuotas de recursos. Puedes supervisar tu consumo de recursos y solicitar un aumento en la página de cuotas de Cloud ML Engine en el Administrador de API de tu consola.

Ruta de guardado no válida

Si tu trabajo finaliza con un mensaje de error que incluye "Restablecer con una ruta de guardado no válida gs://…", es posible que estés usando un depósito de Google Cloud Storage configurado de manera incorrecta.

  1. Abre la página del Navegador de Google Cloud Storage en GCP Console.

    Abrir el Navegador en GCP Console

  2. Marca la clase de almacenamiento predeterminado para el depósito que usas:

Dos depósitos de Google Cloud Platform, uno asignado a una multirregión no compatible y el otro asignado a una región

  • Debe ser Regional. Si lo es, entonces algo más salió mal. Vuelve a ejecutar tu trabajo.
  • Si es Multi-Regional (Multirregional), necesitas cambiarlo a Regional, o mover tus materiales de entrenamiento a un depósito diferente. Para lo primero, encontrarás instrucciones para cambiar la clase de almacenamiento de un depósito en la documentación de Cloud Storage.

El entrenador sale con AbortedError

Este error puede ocurrir si ejecutas un entrenador que usa TensorFlow Supervisor para administrar los trabajos distribuidos. TensorFlow a veces lanza excepciones AbortedError en situaciones en las que no debes detener todo el trabajo. Puedes detectar esa excepción en tu entrenador y responder en consecuencia. Ten en cuenta que TensorFlow Supervisor no es compatible con los entrenadores que ejecutas con Cloud ML Engine.

Cómo solucionar problemas de predicción

Esta sección reúne algunos problemas comunes que se encuentran cuando se obtienen predicciones.

Cómo controlar condiciones específicas para la predicción en línea

En esta sección, se proporciona orientación sobre algunas condiciones de error de la predicción en línea que se sabe afectan a algunos usuarios.

Predicciones que tardan demasiado en completarse (30-180 segundos)

La causa más común de una predicción en línea lenta es escalar los nodos de procesamiento desde cero. Si tu modelo tiene solicitudes de predicción regulares hechas contra él, el sistema mantiene uno o más nodos listos para entregar predicciones. Si tu modelo no ha entregado ninguna predicción en mucho tiempo, el servicio "reduce" a cero los nodos listos. La próxima solicitud de predicción luego de esta reducción llevará mucho más tiempo en mostrarse de lo habitual porque el servicio tiene que aprovisionar nodos para controlarla.

Códigos de estado de HTTP

Cuando ocurre un error con una solicitud de predicción en línea, generalmente obtienes un código de estado HTTP del servicio. Estos son algunos códigos que se encuentran comúnmente y su significado en el contexto de la predicción en línea:

429 - No hay memoria suficiente

El nodo de procesamiento se quedó sin memoria mientras ejecutaba tu modelo. No hay manera de aumentar la memoria asignada a los nodos de predicción en este momento. Puedes probar esto para que tu modelo se ejecute:

  • Puedes reducir el tamaño de tu modelo si:
    • Usas menos variables precisas.
    • Cuantizas tus datos continuos.
    • Reduces el tamaño de otros atributos de entrada (por ejemplo, mediante el uso de tamaños de vocabulario más pequeños).
    • Envías nuevamente la solicitud con un lote de instancias más pequeño.
429 - Demasiadas solicitudes pendientes

Tu modelo está recibiendo más solicitudes de las que puede controlar. Si usas el ajuste de escala automático, está recibiendo solicitudes más rápido de lo que el sistema puede escalar.

Con el ajuste de escala automático, puedes tratar de volver a enviar solicitudes con un retirada exponencial. Si lo hace, le puede dar al sistema tiempo para ajustarse.

429 - Cuota

Tu proyecto de Google Cloud Platform está limitado a 10,000 solicitudes cada 100 segundos (aproximadamente 100 por segundo). Si recibes este error en picos temporales, a menudo puedes intentar nuevamente con la retirada exponencial para procesar todas tus solicitudes a tiempo. Si obtienes este código sistemáticamente, puedes solicitar un aumento de cuota. Consulta la página de cuotas para obtener más detalles.

503 - Nuestros sistemas han detectado tráfico inusual de tu red de computadoras

La tasa de solicitudes que recibió tu modelo de una sola IP es tan alta que el sistema sospecha un ataque de denegación del servicio. Deja de enviar solicitudes por un minuto y luego vuelve a enviarlas a una tasa más baja.

500 - No se pudo cargar el modelo

El sistema tuvo problemas para cargar tu modelo. Sigue estos pasos:

  • Asegúrate de que tu entrenador esté exportando el modelo correcto.
  • Prueba una predicción de prueba con el comando gcloud ml-engine local predict.
  • Exporta tu modelo nuevamente y vuelve a intentar.

Formato de errores para solicitudes de predicción

Todos estos mensajes tienen que ver con tu entrada de predicción.

"JSON vacío o con formato incorrecto/no válido en el cuerpo de la solicitud"
Este servicio no pudo analizar el JSON en tu solicitud o tu solicitud está vacía. Revisa tu mensaje para ver si hay omisiones o errores que invaliden JSON.
"Campo de 'instancias' faltantes en el cuerpo de la solicitud"
El cuerpo de tu solicitud no sigue el formato correcto. Debe ser un objeto JSON con una clave única llamada "instances" que contiene una lista con todas tus instancias de entrada.
Error de codificación JSON cuando se crea una solicitud

Tu solicitud incluye datos codificados en base64, pero no en el formato JSON adecuado. Cada string codificada en base64 debe estar representada por un objeto con una clave única llamada "b64". Por ejemplo:

  {"b64": "an_encoded_string"}

Ocurre otro error de base64 cuando tienes datos binarios que no están codificados en base64. Codifica tus datos y formatéalos de la siguiente manera:

  {"b64": base64.b64encode(binary_data)}

Consulta más información sobre el formato y la codificación de datos binarios.

La predicción en la nube lleva más tiempo que en la computadora de escritorio

La predicción en línea está diseñada para ser un servicio escalable que entrega rápidamente una tasa alta de solicitudes de predicción. El servicio está optimizado para un rendimiento agregado en todas las solicitudes de servicio. El énfasis en la escalabilidad da lugar a características de rendimiento diferentes que generar un número pequeño de predicciones en tu máquina local.

Pasos siguientes

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Cloud ML Engine para TensorFlow