Solucionar errores de tiempo de espera agotado de Spanner

En esta página se ofrece una descripción general de los errores de tiempo de espera agotado de Spanner: qué son, por qué se producen y cómo solucionarlos.

Al acceder a las APIs de Spanner, es posible que las solicitudes fallen debido a errores DEADLINE_EXCEEDED. Este error indica que no se ha recibido una respuesta en el periodo de tiempo de espera configurado.

Este error puede deberse a muchos motivos, como instancias de Spanner sobrecargadas, esquemas no optimizados o consultas no optimizadas. En esta página se describen situaciones habituales en las que se produce un error de tiempo de espera superado y se ofrece una guía sobre cómo investigar y resolver estos problemas.

Filosofía de reintentos y plazos de Spanner

La filosofía de plazos y reintentos de Spanner es diferente a la de muchos otros sistemas. En Spanner, debes especificar un plazo de tiempo de espera como el tiempo máximo en el que una respuesta es útil. No se recomienda fijar un plazo artificialmente corto solo para volver a intentar la misma operación inmediatamente, ya que esto provocará que las operaciones no se completen nunca. En este contexto, no se recomiendan las siguientes estrategias y operaciones, ya que son contraproducentes y anulan el comportamiento interno de reintento de Spanner:

  • Fijar una fecha límite demasiado cercana. Esto significa que la operación no es resistente a los aumentos ocasionales de la latencia de cola y no se puede completar antes de que se agote el tiempo de espera. En su lugar, define una fecha límite que sea el tiempo máximo en el que una respuesta es útil.

  • Definir un plazo demasiado largo y cancelar la operación antes de que se supere. Esto provoca reintentos y trabajo desperdiciado en cada intento. En conjunto, esto puede crear una carga adicional significativa en tu instancia.

¿Qué es un error de plazo superado?

Cuando usas una de las bibliotecas de cliente de Spanner, la capa de gRPC subyacente se encarga de la comunicación, la serialización, la deserialización y el cumplimiento de los 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 termine con el error de plazo superado.

La guía de configuración de tiempo de espera muestra cómo puedes especificar plazos (o tiempos de espera) en cada una de las bibliotecas de cliente de Spanner compatibles. Las bibliotecas de cliente de Spanner usan ajustes predeterminados de tiempo de espera y de 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 errores habituales de superación del plazo

Puede que se produzcan errores de DEADLINE_EXCEEDED en los siguientes tipos de problemas:

Problemas con la API de acceso a datos

Una instancia de Spanner debe configurarse correctamente para tus cargas de trabajo específicas con el fin de evitar problemas con la API de acceso a datos. En las siguientes secciones se describe cómo investigar y resolver diferentes problemas de la API Data Access.

Comprobar la carga de CPU de la instancia de Spanner

La latencia de las solicitudes puede aumentar significativamente si la utilización de la CPU supera el umbral recomendado. Puedes consultar la utilización de la CPU de Spanner en la consola de monitorización proporcionada en la Google Cloud consola. También puede crear alertas basadas en el uso de CPU de la instancia.

Resolución

Para ver los pasos que debes seguir para reducir el uso de la CPU de la instancia, consulta el artículo sobre cómo reducir el uso de la CPU.

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

Cuando una solicitud viaja del cliente a los servidores de Spanner y viceversa, se realizan varios saltos de red: de la biblioteca de 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 alguna de estas fases, es posible que veas errores de tiempo de espera agotado.

Es posible registrar la latencia en cada fase. Para obtener más información, consulta Puntos de latencia en una solicitud de Spanner. Para saber dónde se produce la latencia en Spanner, consulta Identificar dónde se produce la latencia en Spanner.

Resolución

Una vez que obtenga el desglose de la latencia, podrá usar métricas para diagnosticar la latencia, comprender por qué se produce y encontrar soluciones.

Problemas con las APIs Data

Algunos patrones de uso no óptimos de la API Data de Spanner pueden provocar errores de tiempo de espera agotado. En esta sección se proporcionan directrices sobre cómo comprobar estos patrones de uso no óptimos.

Buscar consultas caras

Si intentas ejecutar consultas costosas que no se ejecutan en el plazo de tiempo de espera configurado en las bibliotecas de cliente, es posible que se produzca un error de tiempo de espera agotado. Algunos ejemplos de consultas costosas son, entre otros, los análisis completos de una tabla grande, las combinaciones cruzadas de varias tablas grandes o la ejecución de una consulta con un predicado en una columna que no es clave (también un análisis completo de la tabla).

Puede inspeccionar las consultas costosas mediante la tabla de estadísticas de consultas y la tabla de estadísticas de transacciones. Estas tablas muestran información sobre las consultas y transacciones lentas, como el número medio de filas leídas, el número medio de bytes leídos, el número medio de filas analizadas y más. Además, puede generar planes de ejecución de consultas para inspeccionar cómo se ejecutan sus consultas.

Resolución

Para optimizar las consultas, consulta la guía de prácticas recomendadas para consultas de SQL. También puede usar los datos obtenidos a través de las tablas de estadísticas mencionadas anteriormente y los planes de ejecución para optimizar sus consultas y hacer cambios en el esquema de sus bases de datos. Estas prácticas recomendadas pueden ayudar a reducir el tiempo de ejecución de las instrucciones, lo que puede ayudar a evitar los errores de tiempo de espera agotado.

Comprobar la contención de bloqueos

Las transacciones de Spanner deben adquirir bloqueos para confirmarse. Las aplicaciones que se ejecutan con un alto rendimiento pueden provocar que las transacciones compitan por los mismos recursos, lo que aumenta el tiempo de espera para obtener los bloqueos y afecta al rendimiento general. Esto podría provocar que se superen los plazos de cualquier solicitud de lectura o escritura.

Para identificar la causa principal de las transacciones de lectura y escritura con latencia alta, puedes usar la tabla de estadísticas de bloqueos y consultar la siguiente entrada de blog. En la tabla de estadísticas de los bloqueos, puedes encontrar las claves de fila con los tiempos de espera de bloqueo más altos.

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

Resolución

Aplica estas prácticas recomendadas para reducir las disputas de bloqueo. Además, usa transacciones de solo lectura en los casos prácticos de lecturas simples para evitar conflictos de bloqueo con las escrituras. Las transacciones de lectura y escritura deben reservarse para las escrituras o los flujos de trabajo mixtos de lectura y escritura. Si sigues estos pasos, deberías mejorar la latencia general del tiempo de ejecución de tus transacciones y reducir los errores de tiempo de espera agotado.

Comprobar si hay esquemas no optimizados

Antes de diseñar un esquema de base de datos óptimo para tu base de datos de Spanner, debes tener en cuenta los tipos de consultas que se van a ejecutar en ella. Los esquemas no óptimos pueden provocar problemas de rendimiento al ejecutar algunas consultas. Estos problemas de rendimiento pueden impedir que las solicitudes se completen en el plazo configurado.

Resolución

El diseño de esquema más óptimo dependerá de las lecturas y escrituras que se realicen en tu base de datos. Las guías de prácticas recomendadas para el diseño de esquemas y prácticas recomendadas de SQL se deben seguir independientemente de las características específicas del esquema. Si sigues estas guías, evitarás los problemas de diseño de esquemas más habituales. Otras causas principales del bajo rendimiento se atribuyen a la elección de claves principales, el diseño de la tabla (consulta Usar tablas intercaladas para acceder más rápido), el diseño del esquema (consulta Optimizar el esquema para mejorar el rendimiento) y el rendimiento del nodo configurado en tu instancia de Spanner (consulta Descripción general del rendimiento de Spanner).

Buscar puntos de acceso

Como Spanner es una base de datos distribuida, el diseño del esquema debe tener en cuenta cómo evitar los puntos de acceso. Por ejemplo, si creas columnas que aumentan de forma monótona, se limitará el número de divisiones con las que puede trabajar Spanner para distribuir la carga de trabajo de forma uniforme. Estos cuellos de botella pueden provocar que se agote el tiempo de espera. También puedes usar Key Visualizer para solucionar problemas de rendimiento causados por puntos de acceso.

Resolución

Consulte las soluciones identificadas en la sección anterior Comprobar si hay esquemas no optimizados como primer paso para resolver este problema. Rediseña el esquema de tu base de datos y usa índices intercalados para evitar los índices que puedan provocar un exceso de actividad. Si el problema no se soluciona siguiendo estos pasos, consulta la guía para elegir una clave principal que evite los puntos de acceso. Por último, evita patrones de tráfico subóptimos, como las lecturas de gran intervalo, que pueden impedir la división basada en la carga.

Comprobar si hay tiempos de espera mal configurados

Las bibliotecas de cliente proporcionan tiempos de espera predeterminados razonables para todas las solicitudes de Spanner. Sin embargo, es posible que tengas que ajustar estas configuraciones predeterminadas para tu carga de trabajo específica. Merece la pena observar el coste de tus consultas y ajustar los plazos para que se adapten a tu caso práctico específico.

Resolución

Los ajustes predeterminados de los tiempos de espera son adecuados para la mayoría de los casos prácticos. Los usuarios pueden anular estas configuraciones (consulta la guía de tiempo de espera y reintentos personalizados), pero no se recomienda usar tiempos de espera más agresivos que los predeterminados. Si decide cambiar el tiempo de espera, defínalo como el tiempo real que la aplicación puede esperar para obtener el resultado. Puedes probar con tiempos de espera configurados más largos, pero nunca definas un tiempo de espera inferior al tiempo real que la aplicación está dispuesta a esperar, ya que esto provocaría que la operación se volviera a intentar con más frecuencia.

Problemas con la API Admin

Las solicitudes a la API Admin son operaciones costosas en comparación con las solicitudes a la API Data. Las solicitudes de administrador, como CreateInstance, CreateDatabase o CreateBackups, pueden tardar varios segundos en devolver una respuesta. Las bibliotecas de cliente de Spanner definen plazos de 60 minutos para las solicitudes de administrador de instancias y bases de datos. De esta forma, el servidor tiene la oportunidad de completar la solicitud antes de que el cliente vuelva a intentarlo o falle.

Resolución

Si usas la biblioteca de cliente de Spanner de Google para acceder a la API de administrador, asegúrate de que la biblioteca de cliente esté actualizada y use la versión más reciente. Si accedes a la API Spanner directamente a través de una biblioteca de cliente que has creado, asegúrate de que no tienes ajustes de tiempo de espera más agresivos que los predeterminados (60 minutos) para las solicitudes de administrador de tu instancia y base de datos.

Google Cloud problemas con la consola

Las consultas realizadas desde la página Google Cloud Spanner Studio de la consola 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 tiempo de espera agotado de la consola Google Cloud

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

Resolución

Puedes volver a escribir la consulta siguiendo las prácticas recomendadas 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 las bibliotecas de cliente independientes. Sin embargo, sigue siendo posible recibir un error de tiempo de espera y de tiempo límite superado cuando los elementos de trabajo son demasiado grandes. Si es necesario, puede personalizar la configuración del tiempo de espera de confirmación de Apache Beam.

Resolución

Si se produce un error de tiempo de espera agotado en los pasos ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, consulta la tabla de estadísticas de consultas para saber qué consulta ha analizado un gran número de filas. Después, modifica esas consultas para intentar reducir el tiempo de ejecución.

En el siguiente mensaje de excepción se muestra otro ejemplo de error de tiempo de espera agotado de Dataflow:

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 ha producido porque los elementos de trabajo son demasiado grandes. En el ejemplo anterior, las dos recomendaciones siguientes pueden ser útiles. En primer lugar, puedes probar a habilitar el servicio de aleatorio si aún no lo has hecho. En segundo lugar, puedes probar a modificar las configuraciones de 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 ver un ejemplo de cómo hacerlo en esta plantilla de Dataflow.

Recursos adicionales para solucionar problemas relacionados con el incumplimiento de plazos

Si sigues viendo el error DEADLINE_EXCEEDED después de completar los pasos para solucionar el problema, abre un caso de asistencia si se dan las siguientes situaciones:

  • Una latencia alta de Google Front End, pero una latencia baja de las solicitudes de la API Spanner
  • Una latencia alta de las solicitudes de la API Spanner, pero una latencia baja de las consultas

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