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 solucionar problemas y resolverlos.
Cuando se accede a las APIs de Spanner, las solicitudes pueden fallar debido a
errores DEADLINE_EXCEEDED. Este error indica que no se recibió una respuesta
dentro del período de tiempo de espera configurado.
Un error de plazo 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 plazo excedido y se proporciona una guía para investigar y resolver estos problemas.
Filosofía de reintentos y plazos de Spanner
La filosofía de plazo y reintento de Spanner difiere de la 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 solo para volver a intentar la misma operación de inmediato, 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 anulan el comportamiento de reintento interno de Spanner:
Establecer un plazo demasiado corto. 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, establece una fecha límite que sea la cantidad máxima de tiempo en la que una respuesta sea útil.
Establecer un plazo demasiado largo y cancelar la operación antes de que se supere el plazo. 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 plazo excedido?
Cuando usas una de las bibliotecas cliente de Spanner, la capa de gRPC subyacente se encarga de la comunicación, la serialización, la deserialización y la aplicación de plazos. Los plazos permiten que tu aplicación especifique cuánto tiempo está dispuesta a esperar para que se complete una solicitud antes de que se finalice con el error de plazo excedido.
En la guía de configuración de tiempo de espera, se muestra cómo puedes especificar plazos (o tiempos de espera) en cada una de las bibliotecas cliente de Spanner admitidas. Las bibliotecas cliente de Spanner usan la configuración predeterminada de la política de tiempo de espera y reintentos, que se define en los siguientes archivos de configuración:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
Para obtener más información sobre los plazos de gRPC, consulta gRPC y plazos.
Cómo investigar y resolver errores comunes de plazo excedido
Es posible que encuentres errores DEADLINE_EXCEEDED para los siguientes tipos de problemas:
- Problemas con la API de acceso a los datos
- Problemas con la API de datos
- Problemas con la API de Admin
- Problemas de consola deGoogle Cloud
- Problemas de Dataflow
Problemas con la API de acceso a los datos
Una instancia de Spanner debe configurarse de forma adecuada para tus cargas de trabajo específicas para evitar problemas con la API de acceso a los datos. 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 CPU de la instancia de Spanner
La latencia de las solicitudes puede aumentar de forma significativa a medida que el uso de CPU cruza el umbral saludable recomendado. Puedes verificar el uso de CPU de Spanner en la consola de supervisión que se proporciona en la consola de Google Cloud . También puedes crear alertas en función del uso de CPU de la instancia.
Solución
Para conocer los pasos que permiten reducir el uso de CPU de la instancia, consulta Reduce el uso de CPU.
Verifica el desglose de la latencia de extremo a extremo de la solicitud
A medida que una solicitud viaja del cliente a los servidores de Spanner y de regreso, se deben realizar varios saltos de red: de la biblioteca cliente a Google Front End (GFE), de 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 estas 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 encontrar dónde se produce la latencia en Spanner, consulta Identifica dónde se produce la latencia en Spanner.
Solución
Una vez que obtengas el desglose de la latencia, podrás usar métricas para diagnosticarla, comprender por qué se produce y encontrar soluciones.
Problemas con la API de datos
Ciertos patrones de uso no óptimos de la API de datos de Spanner pueden provocar errores de plazo excedido. En esta sección, se proporcionan lineamientos para verificar estos patrones de uso no óptimos.
Verifica si hay 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 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 que no es clave (también un análisis completo de la tabla).
Puedes inspeccionar las 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 promedio 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
Para optimizar tus consultas, usa la guía de prácticas recomendadas para consultas en 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 en el esquema de 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 eliminar los errores de plazo excedido.
Verifica la contención de bloqueo
Las transacciones de Spanner deben adquirir bloqueos para confirmarse. Las aplicaciones que se ejecutan con una alta capacidad de procesamiento 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 provocar que se excedan los plazos de las solicitudes de lectura o escritura.
Puedes encontrar la causa raíz de las transacciones de lectura y escritura de alta latencia con la tabla de estadísticas de bloqueo y consultando 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 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 conflicto de bloqueo con la guía para solucionar problemas con etiquetas de transacciones.
Solución
Aplica 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 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 tu transacción y reducir los errores de plazo excedido.
Verifica si hay esquemas no optimizados
Antes de diseñar un esquema de base de datos óptimo para tu base de datos de Spanner, debes considerar los tipos de consultas que se ejecutarán en tu base de datos. Los esquemas que no son ó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 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 las prácticas recomendadas de SQL se deben seguir independientemente de los detalles del esquema. Si sigues estas guías, evitarás los problemas de diseño de esquemas más comunes. Otras causas raíz del rendimiento deficiente se atribuyen a tu 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 mejorar el rendimiento) y el rendimiento del nodo configurado dentro de tu instancia de Spanner (consulta la Descripción general del rendimiento de Spanner).
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 aumenten 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 usar Key Visualizer para solucionar problemas de rendimiento causados por hotspots.
Solución
Consulta las resoluciones identificadas en la sección anterior Verifica si hay esquemas no optimizados como primer paso para resolver este problema. Rediseña el esquema de la base de datos y usa índices intercalados para evitar índices que puedan causar hotspots. Si seguir estos pasos no mitiga el problema, consulta la guía para elegir una clave primaria para evitar hotspots. Por último, evita los patrones de tráfico subóptimos, como las lecturas de rango grande, que podrían impedir la división basada en la carga.
Verifica si hay tiempos de espera mal configurados
Las bibliotecas cliente proporcionan tiempos de espera predeterminados razonables para todas las solicitudes en Spanner. Sin embargo, es posible que debas ajustar estos parámetros de configuración predeterminados 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 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 estos parámetros de configuración (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 decides cambiar el tiempo de espera, configúralo en la cantidad real de tiempo que la aplicación está dispuesta a esperar el resultado. Puedes experimentar con tiempos de espera configurados más largos, pero nunca establezcas un tiempo de espera más corto que el tiempo real que la aplicación está dispuesta a esperar, ya que esto haría que la operación se reintentara con más frecuencia.
Problemas con la API de Admin
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 muchos segundos antes de devolver una respuesta. Las bibliotecas cliente de Spanner establecen plazos de 60 minutos para las solicitudes de administrador de instancia y base de datos. Esto garantiza 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 una biblioteca cliente que creaste, asegúrate de no tener una configuración de plazo límite más agresiva que la predeterminada (60 minutos) para tus solicitudes de administrador de instancia y base de datos.
Problemas de consola deGoogle Cloud
Las consultas emitidas desde la página de Spanner Studio de la consola de Google Cloud no pueden exceder los cinco minutos. Si creas una consulta costosa que tarda más de cinco minutos en ejecutarse, verás el siguiente mensaje de error:
El backend cancelará la consulta con errores y, si es necesario, se revertirá la transacción.
Solución
Puedes volver a escribir la consulta con la guía de prácticas recomendadas para las consultas en SQL.
Problemas de Dataflow
En Apache Beam, la configuración de tiempo de espera predeterminada es de dos horas para las operaciones de lectura y de 15 segundos para las operaciones de confirmación. Estas opciones de configuración permiten operaciones más largas en comparación con los tiempos de espera de la biblioteca cliente independiente. Sin embargo, es posible que recibas un error de tiempo de espera y de plazo excedido cuando los elementos de trabajo sean demasiado grandes. Si es necesario, puedes personalizar la configuración del tiempo de espera de confirmación de Apache Beam.
Solución
Si se produce un error de plazo excedido en los pasos ReadFromSpanner / Execute
query / Read from Spanner / Read from Partitions, consulta la
tabla de estadísticas de consultas
para averiguar qué consulta analizó una gran cantidad de filas. Luego, modifica esas
consultas para intentar reducir el tiempo de ejecución.
En el siguiente mensaje de excepción, se muestra otro ejemplo de un error de plazo excedido 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 produjo porque los elementos de trabajo son demasiado grandes. En el ejemplo anterior,
las siguientes dos recomendaciones podrían ayudar. En primer lugar, puedes intentar habilitar
el servicio de Shuffle si aún no está habilitado. En segundo lugar, puedes intentar ajustar las
parámetros de configuración en 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 adicionales para solucionar problemas de plazo excedido
Si sigues viendo un error DEADLINE_EXCEEDED después de completar los
pasos para solucionar problemas, abre un caso de asistencia si
se producen las siguientes situaciones:
- Una latencia alta de Google Front End, pero una latencia baja de solicitud a la API de Spanner
- Una latencia alta de la solicitud a la API de Spanner, pero una latencia baja de la consulta
También puedes consultar los siguientes recursos para solucionar problemas: