Soluciona problemas de errores de vencimiento de Spanner

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

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

Un error de vencimiento excedido 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 de vencimiento y se proporciona una guía para investigar y resolver estos problemas.

Filosofía de la fecha límite y el reintento de Spanner

La filosofía de plazos y reintentos de Spanner difiere de muchas otras y sistemas. En Spanner, debes especificar una fecha límite de tiempo de espera como el el tiempo máximo en el que una respuesta es útil. Configurando una política con un plazo breve para reintentar inmediatamente la misma operación otra vez Se recomienda, ya que esto generará situaciones en las que las operaciones nunca se completen. En En este contexto, no se recomiendan las siguientes estrategias ni operaciones: no son contraproductivos y derrotan el reintento interno de Spanner comportamiento:

  • Establecer una fecha límite demasiado corta Esto significa que la operación no resilientes a aumentos ocasionales de la latencia final y no pueden completarse antes se agota el tiempo de espera. En cambio, establece una fecha límite que sea la cantidad máxima de tiempo en la que una respuesta es útil.

  • Establecer un plazo demasiado largo y cancelar la operación antes de la la fecha límite supere la fecha límite. Esto genera reintentos y trabajo desperdiciado en cada intento. En conjunto, esto puede crear una carga adicional significativa en tu instancia.

¿Qué es un error de fecha límite excedida?

Cuando usas una de las bibliotecas cliente de Spanner, la capa de gRPC subyacente se encarga de la comunicación, el ordenamiento, la desalineación, y la aplicación de plazos. Los plazos permiten que tu aplicación especifique cuánto tiempo está dispuesta a esperar a que se complete una solicitud antes de que se cancele con el error de que se superó el plazo.

La guía de configuración de tiempo de espera demuestra cómo especificar plazos (o tiempos de espera) en cada uno de los servicios bibliotecas cliente. Las bibliotecas cliente de Spanner usan el tiempo de espera predeterminado y la configuración de la política de reintentos, que se define 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 errores comunes de vencimientos

Es posible que encuentres errores DEADLINE_EXCEEDED para los siguientes tipos de problemas:

Problemas con la API de acceso a los datos

Una instancia de Spanner debe estar configurada de forma adecuada para tu cargas de trabajo específicas para evitar problemas de API de acceso a los datos. Las siguientes secciones describen cómo investigar y resolver diferentes problemas de la API de acceso a los datos.

Verifica la carga de CPU de la instancia de Spanner

La latencia de las solicitudes puede aumentar significativamente a medida que el uso de CPU cruza el umbral de buen estado recomendado. Puedes consultar el uso de CPU de Spanner en la consola de supervisión que se proporcionan en la consola de Google Cloud. También puedes crear alertas según 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.

Verifica 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: de la biblioteca cliente a Google Front End (GFE), del GFE al frontend de la API de Spanner y, por último, del frontend de la API de Spanner a la base de datos de Spanner. Si hay problemas de red en cualquiera de estos etapas, es posible que veas errores de plazo excedido.

Es posible capturar la latencia en cada etapa. Para obtener más información, consulta Puntos de latencia en una solicitud de Spanner. Para descubrir dónde ocurre la latencia en Spanner, consulta Identificar dónde ocurre la latencia en Spanner.

Solución

Una vez que obtengas el desglose de la latencia, puedes usar métricas para diagnosticar la latencia, comprender por qué ocurre y encontrar soluciones.

Problemas con la API de datos

Ciertos patrones de uso no óptimos de la API de datos de Spanner podrían causa errores de plazo excedido. En esta sección, se brindan lineamientos sobre cómo para buscar patrones de uso no óptimos.

Cómo verificar si hay consultas costosas

Si intentas ejecutar consultas costosas que no se ejecutan dentro del tiempo de espera configurado en las bibliotecas cliente, es posible que se genere un error de vencimiento 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 sobre una columna que no es clave (también un análisis completo de la tabla).

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 las consultas y transacciones de ejecución lenta, como la cantidad promedio de filas leídas, los bytes leídos promedio, la cantidad promedio de filas analizadas y mucho más. Además, puedes generar planes de ejecución de consultas para inspeccionar mejor cómo se ejecutan tus consultas.

Solución

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

Cómo comprobar la contención de bloqueo

Las transacciones de Spanner deben adquirir bloqueos para confirmarse. Las aplicaciones que se ejecutan a una alta capacidad de procesamiento pueden provocar que las transacciones compitan por los mismos recursos, lo que genera un mayor tiempo de espera para obtener los bloqueos y lo que afecta el rendimiento general. Esto podría provocar que se excedan los plazos de las solicitudes de lectura o escritura.

Para encontrar la causa raíz de las transacciones de lectura y escritura de alta latencia, puedes usar la tabla de estadísticas de bloqueo y consultar la siguiente entrada de blog. En la tabla de estadísticas de bloqueo, puedes encontrar las claves de fila con las los tiempos de espera de bloqueo.

Esta guía para solucionar problemas de conflictos 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 en la guía para solucionar problemas con etiquetas de transacción.

Solución

Aplique estas prácticas recomendadas. para reducir las contenciones de bloqueo. Además, usa transacciones de solo lectura para los casos de uso de lecturas simples para evitar conflictos de bloqueo con las operaciones de escritura. Usando Las transacciones de lectura y escritura deben reservarse para escrituras o flujos de trabajo mixtos de lectura y escritura. Seguir estos pasos debería mejorar la latencia general de la transacción el tiempo de ejecución y reducir los errores excedidos en el plazo.

Verifica si hay esquemas no optimizados

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

Solución

El mejor diseño de esquema dependerá de las operaciones de lectura y escritura que se realicen tu base de datos. Se deben seguir las guías de prácticas recomendadas de diseño de esquemas y prácticas recomendadas de SQL, independientemente de los detalles del esquema. Si sigues estas guías, evitarás los problemas de diseño de esquemas más comunes. Algunas otras causas raíz del rendimiento bajo se atribuyen a la elección de claves primarias, el diseño de tablas (consulta Cómo usar tablas intercaladas para un acceso más rápido), el diseño del esquema (consulta Cómo optimizar el esquema para mejorar el rendimiento) y el rendimiento del nodo configurado en tu instancia de Spanner (consulta la descripción general del rendimiento de Spanner).

Comprueba 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 forma uniforme. Estos cuellos de botella pueden provocar en tiempos de espera. Además, puedes usar Key Visualizer para solucionar problemas de rendimiento causados por hotspots.

Solución

Consulta las resoluciones identificadas en la sección anterior Cómo comprobar si hay soluciones optimizadas esquemas como primer paso para resolver el problema. Vuelve a diseñar tu esquema de base de datos y usa índices intercalados para evitar los índices que puedan causar hotspots. Si sigues estos pasos para mitigar el problema, consulta la guía Elige una clave primaria para evitar hotspots. Por último, evita patrones de tráfico subóptimos, como lecturas de gran alcance, que podrían y evita 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 estos parámetros de configuración predeterminados según 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 de uso 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 reintentos y tiempos de espera personalizados) pero no se recomienda usar tiempos de espera más agresivos que los predeterminados. Si decides cambiar el tiempo de espera, debes establecerlo en el tiempo real en el cual la aplicación estará lista para esperar el resultado. Puedes experimentar con más tiempos de espera configurados, pero nunca establecer un tiempo de espera menor que el tiempo tiempo que la aplicación está dispuesta a esperar, ya que esto provocaría que la operación se ejecute se vuelve a intentar con más frecuencia.

Problemas con la API de Administrador

Las solicitudes a la API de Admin 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 antes de mostrar una respuesta. Cliente de Spanner Las bibliotecas establecen plazos de 60 minutos para ambas instancias y base de datos de Google Cloud. Esto se hace 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 un que creaste, asegúrate de no tener una fecha límite más agresiva que la predeterminada (60 minutos) de tu instancia y base de datos de Google Cloud.

Problemas con la consola de Google Cloud

Las consultas emitidas desde la página Spanner Studio de la consola de Google Cloud 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 excedido el plazo de la consola de Google Cloud

El backend cancelará la consulta fallida, y la transacción podría revertirse si es necesario.

Solución

Puedes volver a escribir la consulta con la guía de prácticas recomendadas para consultas de SQL.

Problemas de Dataflow

En Apache Beam, la configuración predeterminada del tiempo de espera es two hours para operaciones de lectura y 15 segundos para las operaciones de confirmación. Estas configuraciones permiten operaciones más largas en comparación con los tiempos de espera de los plazos de la biblioteca cliente independiente. Sin embargo, es es posible que recibas un error de tiempo de espera y plazo excedido cuando los elementos son demasiado grandes. Si es necesario, puedes personalizar la confirmación de Apache Beam del tiempo de espera.

Solución

Si se produce un error en los pasos ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions que indica que se superó el plazo, verifica lo siguiente: 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 tiempo excedido 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 produjo porque los elementos de trabajo son demasiado grandes. En el ejemplo anterior, las siguientes dos recomendaciones podrían ser útiles. En primer lugar, puedes intentar habilitar el servicio de reproducción aleatoria si aún no está habilitado. En segundo lugar, puedes intentar ajustar la configuración de la lectura de tu base de datos, como maxPartitions y partitionSizeBytes. Para obtener más información, consulta PartitionOptions. para intentar reducir el tamaño del elemento de trabajo. Puedes encontrar un ejemplo de cómo hacerlo en esta plantilla de Dataflow.

Recursos de solución de problemas adicionales para el vencimiento adicional

Si todavía ves un error DEADLINE_EXCEEDED después de completar el pasos para solucionar problemas, abre un caso de asistencia si experimentas las siguientes situaciones:

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

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