Soluciona errores de exceso de plazos de Cloud Spanner

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En esta página, se proporciona una descripción general de los errores de plazos excedidos de Cloud Spanner: qué son, por qué ocurren y cómo solucionarlos y resolverlos.

Cuando se accede a las API de Spanner, las solicitudes pueden fallar debido a errores DEADLINE_EXCEEDED. Este error indica que no se recibió una respuesta dentro del tiempo de espera configurado.

Un error de fecha límite excedida puede ocurrir por muchos motivos diferentes, como instancias de Spanner sobrecargadas, esquemas no optimizados o consultas no optimizadas. En esta página, se describen situaciones comunes en las que se produce un error por superar el plazo límite y se proporciona una guía sobre cómo investigar y resolver estos problemas.

Filosofía de plazo y reintento de Cloud Spanner

La fecha límite y la filosofía de prueba de Spanner difieren de muchos otros sistemas. En Spanner, debes especificar un plazo de tiempo de espera como la cantidad máxima de tiempo en la que una respuesta es útil. No se recomienda establecer un plazo artificialmente corto para reintentar de inmediato la misma operación, ya que esto generará situaciones en las que las operaciones nunca se completen. En este contexto, no se recomiendan las siguientes estrategias y operaciones, ya que son contraproducentes y derrotan el comportamiento de reintentos interno de Spanner:

  • Establecer un plazo demasiado corto Esto significa que la operación no es resistente a los aumentos ocasionales de latencia final y no se puede completar antes de que se agote el tiempo de espera. En su lugar, establece una fecha límite que sea la cantidad máxima de tiempo que resulta útil una respuesta.

  • Establecer un plazo demasiado extenso y cancelar la operación antes de que se cumpla el plazo Esto genera reintentos y desperdicio de trabajo en cada intento. En conjunto, esto puede crear una carga adicional significativa en tu instancia.

¿Qué es un error que excede el plazo?

Cuando usas una de las bibliotecas cliente de Spanner, la capa de gRPC subyacente se encarga de la comunicación, el ordenamiento, el desordenamiento y la aplicación de la fecha límite. Los plazos permiten que la aplicación especifique el tiempo que está dispuesto a esperar a que se complete una solicitud antes de que esta finalice con el error de fecha límite excedida.

En la guía de configuración de tiempo de espera, se muestra cómo especificar plazos (o tiempos de espera) en cada una de las bibliotecas cliente de Spanner compatibles. Las bibliotecas cliente de Spanner usan el tiempo de espera predeterminado y la configuración de la política de reintentos que se definen en los siguientes archivos de configuración:

Para obtener más información sobre los plazos de gRPC, consulta gRPC y plazos.

Cómo investigar y resolver los errores comunes de exceso de plazos

Problemas con la API de acceso a los datos

Una instancia de Spanner debe estar configurada de forma adecuada para tus cargas de trabajo específicas a fin de evitar problemas de acceso a los datos a la API. En las siguientes secciones, se describe cómo investigar y resolver diferentes problemas de la API de acceso a los datos.

Verifica la carga de la CPU de la instancia de Spanner

La latencia de las solicitudes puede aumentar significativamente a medida que el uso de CPU supera el umbral de buen estado recomendado. Puedes verificar el uso de CPU de Spanner en la consola de supervisión que se proporciona en Google Cloud Console. También puedes crear alertas basadas en el uso de CPU de la instancia.

Solución

Si deseas conocer los pasos para reducir el uso de CPU de la instancia, consulta Reduce el uso de CPU.

Revisa el desglose de latencia de extremo a extremo de la solicitud

A medida que una solicitud viaja del cliente a los servidores de Spanner y viceversa, se deben realizar varios saltos de red: desde la biblioteca cliente hasta el frontend de Google (GFE); desde el frontend de la API de Spanner hasta la API de Spanner y, por último, desde el frontend de la API de Spanner hasta la base de datos de Spanner. Si hay problemas de red en alguna de estas etapas, es posible que veas errores de plazo límite.

Es posible capturar la latencia en cada etapa (consulta la guía de latencia). Para obtener más información sobre cómo usar la guía de diagnóstico, consulta cómo diagnosticar problemas de latencia.

Solución

Una vez que obtengas el desglose de latencia y diagnostiques el problema de latencia, puedes usar esta guía de solución de problemas de latencia para identificar el origen de la latencia y comprender por qué está ocurriendo.

Problemas con la API de datos

Ciertos patrones de uso no óptimos de la API de datos de Spanner pueden causar errores que superen el plazo. En esta sección, se proporcionan lineamientos sobre cómo verificar estos patrones de uso no óptimos.

Consulta las consultas costosas

Intentar ejecutar consultas costosas que no se ejecutan dentro del plazo de tiempo de espera configurado en las bibliotecas cliente puede generar un error de plazo límite excedido. Algunos ejemplos de consultas costosas incluyen, entre otros, análisis completos de una tabla grande, uniones cruzadas en varias tablas grandes o una ejecución de consulta con un predicado en una columna sin clave (también un análisis de tabla completo).

Puedes inspeccionar consultas costosas con la tabla de estadísticas de consultas y la tabla de estadísticas de transacciones. En estas tablas, se muestra información sobre consultas y transacciones de ejecución lenta, como la cantidad promedio de filas leídas, la cantidad promedio de bytes leídos, la cantidad promedio de filas analizadas y mucho más. Además, puedes generar planes de ejecución de consultas para inspeccionar aún más cómo se ejecutan tus consultas.

Solución

A fin de optimizar tus consultas, usa la guía de recomendaciones para consultas de SQL. También puedes usar los datos obtenidos a través de las tablas de estadísticas y los planes de ejecución antes mencionados para optimizar tus consultas y realizar cambios de esquema en tus bases de datos. Estas prácticas recomendadas pueden ayudar a reducir el tiempo de ejecución de las declaraciones, lo que podría ayudar a deshacerse de los errores de plazo excedido.

Verificar contención de bloqueo

Las transacciones de Spanner deben adquirir bloqueos para confirmar. Las aplicaciones que se ejecutan con una capacidad de procesamiento alta pueden hacer que las transacciones compitan por los mismos recursos, lo que aumenta la espera para obtener los bloqueos y afecta el rendimiento general. Esto podría generar plazos excedidos para cualquier solicitud de lectura o escritura.

Puedes encontrar la causa raíz de las transacciones de lectura y escritura de alta latencia en la tabla de estadísticas de bloqueo y consulta la siguiente entrada de blog. En la tabla de estadísticas de bloqueo, puedes encontrar las claves de fila con los tiempos de espera de bloqueo más altos.

En esta guía de solución de problemas de bloqueo, se explica cómo encontrar las transacciones que acceden a las columnas involucradas en el conflicto de bloqueo. También puedes descubrir qué transacciones están involucradas en un conflicto de bloqueo mediante la guía de solución de problemas con etiquetas de transacción.

Solución

Aplica estas prácticas recomendadas para reducir las contenciones de bloqueo. Además, usa transacciones de solo lectura para casos prácticos de lectura sin formato a fin de evitar conflictos de bloqueo con las escrituras. El uso de transacciones de lectura y escritura debe reservarse para escrituras o flujos de trabajo mixtos de lectura y escritura. Seguir estos pasos debería mejorar la latencia general del tiempo de ejecución de la transacción y reducir los errores de plazo excedido.

Verifica si hay esquemas no optimizados

Antes de diseñar un esquema óptimo para tu base de datos de Spanner, debes considerar los tipos de consultas que se ejecutarán en ella. Los esquemas subóptimos pueden causar problemas de rendimiento cuando se ejecutan algunas consultas. Estos problemas de rendimiento pueden impedir que las solicitudes se completen dentro del plazo configurado.

Solución

El diseño de esquema óptimo dependerá de las operaciones de lectura y escritura que se realicen a tu base de datos. Se deben seguir las guías de prácticas recomendadas para el diseño de esquemas y SQL, sin importar las especificaciones del esquema. Si sigues estas guías, evitarás los problemas de diseño de esquemas más comunes. Otras causas principales del rendimiento deficiente se atribuyen a la elección de claves primarias, el diseño de la tabla (consulta Usa tablas intercaladas para un acceso más rápido), el diseño del esquema (consulta Optimiza el esquema para el rendimiento) y el rendimiento del nodo configurado en tu instancia de Spanner (consulta Límites regionales o Límites multirregionales).

Verifica si hay hotspots

Debido a que Spanner es una base de datos distribuida, el diseño del esquema debe tener en cuenta la prevención de hotspots. Por ejemplo, crear columnas que aumentan de forma monótona limitará la cantidad de divisiones con las que Spanner puede trabajar para distribuir la carga de trabajo de manera uniforme. Estos cuellos de botella pueden provocar tiempos de espera. Además, puedes aprovechar Key Visualizer para solucionar los problemas de rendimiento causados por los hotspots.

Solución

Consulta las resoluciones identificadas en la sección anterior Verifica esquemas no optimizados como primer paso para resolver este problema. Vuelve a diseñar tu esquema de base de datos y usa índices intercalados para evitar la generación de hotspots. Si los siguientes pasos no mitigan el problema, consulta la guía para elegir una clave primaria a fin de evitar hotspots. Por último, evita patrones de tráfico subóptimos, como lecturas de rango grande, que podrían evitar la división basada en la carga.

Verifica si hay tiempos de espera mal configurados

Las bibliotecas cliente proporcionan valores predeterminados de tiempo de espera razonables para todas las solicitudes en Spanner. Sin embargo, es posible que debas ajustar esta configuración predeterminada para tu carga de trabajo específica. Vale la pena observar el costo de tus consultas y ajustar los plazos para que se adapten a tu caso práctico específico.

Solución

La configuración predeterminada de los tiempos de espera es adecuada para la mayoría de los casos de uso. Los usuarios pueden anular estas configuraciones (consulta la guía de tiempo de espera personalizado y reintento), pero no se recomienda usar tiempos de espera más agresivos que los predeterminados. Si decides cambiar el tiempo de espera, configúralo en la cantidad de tiempo real que la aplicación está dispuesta a esperar el resultado. Puedes experimentar con tiempos de espera configurados más largos, pero nunca establecer un tiempo de espera más corto que el tiempo real que la aplicación está dispuesto a esperar, ya que esto provocaría que la operación se vuelva a intentar con más frecuencia.

Problemas con la API de Administrador

Las solicitudes a la API de Administrador son operaciones costosas en comparación con las solicitudes a la API de datos. Las solicitudes de administrador, como CreateInstance, CreateDatabase o CreateBackups, pueden tardar varios segundos en mostrar una respuesta. Las bibliotecas cliente de Spanner establecen plazos de 60 minutos para las solicitudes de administrador de instancias y bases de datos. Esto es para garantizar que el servidor tenga la oportunidad de completar la solicitud antes de que el cliente vuelva a intentarlo o falle.

Solución

Si usas la biblioteca cliente de Spanner de Google para acceder a la API de Administrador, asegúrate de que la biblioteca cliente esté actualizada y use la versión más reciente. Si accedes a la API de Spanner directamente a través de la biblioteca cliente que creaste, asegúrate de no tener una configuración de plazos más agresiva que la configuración predeterminada (60 minutos) para tus solicitudes de administrador de instancias y bases de datos.

Problemas con la consola de Google Cloud

Las consultas emitidas desde la página de consultas de Google Cloud Console no pueden superar los cinco minutos. Si creas una consulta costosa que tarda más de cinco minutos en ejecutarse, verás el siguiente mensaje de error:

Captura de pantalla del mensaje de error de fecha límite excedida de Cloud Console

El backend cancelará la consulta con errores y la transacción puede revertirse si es necesario.

Solución

Puedes volver a escribir la consulta con la guía de recomendaciones para consultas de SQL.

Problemas de Dataflow

En Apache Beam, la configuración predeterminada del tiempo de espera es de dos horas para las operaciones de lectura y de 15 segundos para las operaciones de confirmación. Estas configuraciones permiten operaciones más largas en comparación con los tiempos de espera de la biblioteca cliente independiente. Sin embargo, aún es posible recibir un error de tiempo de espera y de exceso de plazo cuando los elementos de trabajo son demasiado grandes. Actualmente, solo es posible personalizar la configuración del tiempo de espera de confirmación de Apache Beam si es necesario.

Solución

Si se produce un error de fecha límite excedida en los pasos ReadFromSpanner / Execute query / Read from Cloud Spanner / Read from Partitions, revisa la tabla de estadísticas de consultas para descubrir qué consulta analizó una gran cantidad de filas. Luego, modifica esas consultas para intentar reducir el tiempo de ejecución.

Otro ejemplo de un error de plazo límite de Dataflow se muestra en el siguiente mensaje de excepción:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Este tiempo de espera se debe a que los elementos de trabajo son demasiado grandes. En el caso anterior, las dos recomendaciones siguientes pueden ayudarte. Primero, puedes intentar habilitar el servicio Shuffle si aún no está habilitado. En segundo lugar, puedes intentar ajustar la configuración en la lectura de tu base de datos, como maxPartitions y partitionSizeBytes. Para obtener más información, consulta PartitionOptions a fin de intentar reducir el tamaño del elemento de trabajo. En esta plantilla de Dataflow, puedes encontrar un ejemplo de cómo hacerlo.

La fecha límite adicional superó los recursos de solución de problemas

Si aún ves un error por exceder el plazo límite una vez que se realizaron los pasos anteriores para solucionar problemas, usa el siguiente desglose a fin de determinar si necesitas abrir un caso de ayuda (consulta la lista completa de casos de ayuda en la tabla de solución de problemas de latencia). En resumen, abra un ticket de asistencia si experimenta los siguientes casos:

  • Una latencia alta de Google Front End, pero una latencia baja de la solicitud a la API de Spanner
  • Una latencia de solicitud de la API de Spanner alta, pero una latencia de consulta baja

También puedes consultar los siguientes recursos para solucionar problemas: