Spanner proporciona tablas integradas que conservan muchas estadísticas de las consultas DML y las declaraciones DML que usaron más CPU, y todas las consultas en conjunto (incluidas las consultas de flujo de cambios).
Disponibilidad
Los datos SPANNER_SYS
solo están disponibles a través de interfaces de SQL; por ejemplo:
La página de Spanner Studio de una base de datos en la consola de Google Cloud
El comando
gcloud spanner databases execute-sql
Paneles de Estadísticas de consultas
La API de
executeQuery
Otros métodos de lectura única que proporciona Spanner no son compatibles.
SPANNER_SYS
Uso de CPU agrupado por consulta
Con las siguientes tablas, se realiza un seguimiento de las consultas con el uso más alto de CPU durante un período específico:
SPANNER_SYS.QUERY_STATS_TOP_MINUTE
: Consultas en intervalos de 1 minutoSPANNER_SYS.QUERY_STATS_TOP_10MINUTE
: Consultas en intervalos de 10 minutosSPANNER_SYS.QUERY_STATS_TOP_HOUR
: Consultas en intervalos de 1 hora
Estas tablas tienen las siguientes propiedades:
Cada tabla contiene datos de intervalos de tiempo no superpuestos de la longitud que se especifica en el nombre de la tabla.
Los intervalos se basan en tiempos de reloj. Los intervalos de 1 minuto finalizan en el minuto, los intervalos de 10 minutos finalizan cada 10 minutos a partir de la hora y los intervalos de 1 hora finalizan en la hora.
Por ejemplo, a las 11:59:30 a.m., los intervalos más recientes disponibles para las consultas de SQL son los siguientes:
- 1 minuto: de 11:58:00 a 11:58:59 a.m.
- 10 minutos: de 11:40:00 a 11:49:59 a.m.
- 1 hora: de 10:00:00 a 10:59:59 a.m.
Spanner agrupa las estadísticas según el texto de la consulta en SQL. Si una consulta utiliza parámetros de consulta, Spanner agrupa todas las ejecuciones de esa consulta en una fila. Si la consulta usa literales de cadena, Spanner solo agrupa las estadísticas si el texto completo de la consulta es idéntico; cuando algún texto difiere, cada consulta aparece como una fila separada. Para el DML por lotes, Spanner normaliza el lote anular la duplicación de declaraciones idénticas consecutivas antes de generar el huella dactilar.
Si hay una etiqueta de solicitud, FPRINT es el hash de la etiqueta de solicitud. De lo contrario, es el hash del valor
TEXT
.Cada fila contiene estadísticas para todas las ejecuciones de una consulta en SQL en particular. para las que Spanner captura estadísticas durante el intervalo especificado.
Si Spanner no puede almacenar todas las consultas ejecutadas durante el intervalo, el prioriza las consultas con el mayor uso de CPU durante durante un intervalo de tiempo determinado.
Las consultas con seguimiento incluyen aquellas que el usuario completó, con errores o que canceló.
Un subconjunto de estadísticas es específico de las consultas que se ejecutaron, pero que no se completaron:
El recuento de ejecución y la latencia media en segundos en todas las consultas que no tuvieron éxito.
Recuento de ejecuciones para las consultas que agotaron el tiempo de espera.
Recuento de ejecuciones de las consultas que el usuario canceló o que fallaron debido a problemas de conectividad de red.
Todas las columnas de las tablas son anulables.
Esquema de la tabla
Nombre de la columna | Tipo | Descripción | |
---|---|---|---|
INTERVAL_END |
TIMESTAMP |
Fin del intervalo en el que se produjeron las ejecuciones de consultas incluidas | |
REQUEST_TAG |
STRING |
La etiqueta de solicitud opcional para esta operación de consulta. Para obtener más información sobre el uso de etiquetas, consulta Solución de problemas con etiquetas de solicitud. | |
QUERY_TYPE |
STRING |
Indica si una consulta es PARTITIONED_QUERY o
QUERY Un PARTITIONED_QUERY
es una consulta con un particionaToken obtenido de la API de PartitionQuery. Todas
las demás consultas y declaraciones DML se indican con QUERY
tipo de consulta.
Estadísticas de consulta de
Los DML particionados son
no es compatible.
|
|
TEXT |
STRING |
Texto de consulta de SQL, truncado a aproximadamente 64 KB
Las estadísticas de varias consultas que tienen la misma string de etiquetas se agrupan en una sola fila con REQUEST_TAG que coincide con esa string. Solo el texto de una de esas consultas se muestra en este campo, truncado a aproximadamente 64 KB.
Para el DML por lotes, el conjunto de instrucciones de SQL se acopla en una sola
de fila, concatenada con un delimitador de punto y coma. SQL idéntico consecutivo
los textos se anulan antes de truncarse.
|
|
TEXT_TRUNCATED |
BOOL |
Indica si el texto de la consulta se truncó o no | |
TEXT_FINGERPRINT |
INT64 |
El hash del valor REQUEST_TAG si está presente. De lo contrario, es el hash del valor TEXT . |
|
EXECUTION_COUNT |
INT64 |
Es la cantidad de veces que Spanner hizo la consulta durante el intervalo. | |
AVG_LATENCY_SECONDS |
FLOAT64 |
Promedio de tiempo, en segundos, para cada ejecución de consulta dentro de la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga. | |
AVG_ROWS |
FLOAT64 |
Promedio de filas que mostró la consulta. | |
AVG_BYTES |
FLOAT64 |
Promedio de bytes de datos que mostró la consulta, sin incluir la sobrecarga de codificación de transmisión. | |
AVG_ROWS_SCANNED |
FLOAT64 |
Promedio de filas que analizó la consulta, sin incluir los valores borrados. | |
AVG_CPU_SECONDS |
FLOAT64 |
Cantidad promedio de segundos de tiempo de CPU que Spanner dedicó todas para ejecutar la consulta. | |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Cantidad de veces que la consulta falló durante el intervalo. | |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Promedio de tiempo, en segundos, para cada ejecución de consulta que falló en la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga. | |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Cantidad de veces que el usuario canceló la consulta o falló debido a una conexión de red interrumpida durante el intervalo. | |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Cantidad de veces que se agotó el tiempo de espera de la consulta durante el intervalo. | |
AVG_BYTES_WRITTEN |
FLOAT64 |
Cantidad promedio de bytes que escribe la declaración. | |
AVG_ROWS_WRITTEN |
FLOAT64 |
Promedio de filas modificadas por la instrucción. | |
STATEMENT_COUNT |
INT64 |
La suma de las declaraciones agregadas a esta entrada. Para normal y DML, esto equivale al recuento de ejecuciones. Para el DML por lotes, Spanner captura la cantidad de declaraciones en el lote. | |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
Es la cantidad de veces que se ejecutó la consulta como parte de una transacción de lectura y escritura. Esta columna te ayuda a determinar si puedes evitar las contenciones de bloqueo la consulta a una transacción de solo lectura. | |
LATENCY_DISTRIBUTION |
ARRAY<STRUCT> |
Un histograma del tiempo de ejecución de la consulta. Los valores son medirse en segundos.
El array contiene un solo elemento y es del siguiente tipo:
Para calcular la latencia
percentil de la distribución,
usa la función Para obtener más información, consulta Percentiles y métricas con valores de distribución. |
|
AVG_MEMORY_PEAK_USAGE_BYTES |
FLOAT64 |
Durante una ejecución de consulta distribuida, el uso máximo promedio de memoria (en bytes). Usa esta estadística para identificar qué son las consultas o el tamaño de los datos de la tabla límites de memoria. |
|
AVG_MEMORY_USAGE_PERCENTAGE |
FLOAT64 |
Durante la ejecución de una consulta distribuida, el uso promedio de memoria requerido (como un porcentaje del límite de memoria permitido para esta consulta). Esta estadística solo hace un seguimiento
de la memoria necesaria para que la consulta
ejecutar. Algunos operadores usan memoria de almacenamiento en búfer adicional para mejorar
rendimiento. La memoria de almacenamiento en búfer adicional utilizada se puede ver en la consulta.
plan, pero no se usa para calcular Usa esta estadística para identificar las consultas que se acercan a la memoria límite de uso y corren el riesgo de fallar si el tamaño de los datos aumenta. Para para mitigar el riesgo de que falle la consulta, consulta Prácticas recomendadas sobre SQL para optimizar estas consultas o dividirlas en partes que lean menos datos. |
|
AVG_QUERY_PLAN_CREATION_TIME_SECS |
FLOAT64 |
Es el tiempo promedio de CPU en segundos dedicado a la compilación de consultas, incluida la creación del entorno de ejecución de consultas. Si el valor de esta columna es alto, usa consultas parametrizadas. |
|
AVG_FILESYSTEM_DELAY_SECS |
FLOAT64 |
El tiempo promedio que dedica la consulta a leer desde el sistema de archivos o a en la entrada/salida (E/S). Usa esta estadística para identificar la posible latencia alta que podría causar el archivo
del sistema de E/S. Para mitigar el impacto, agrega un índice
o agrega una cláusula |
|
AVG_REMOTE_SERVER_CALLS |
FLOAT64 |
La cantidad promedio de llamadas al servidor remoto (RPC) que completó la consulta. Usa esta estadística para identificar si diferentes consultas analizan la misma
de filas tienen un número muy diferente de RPC. La consulta con un
un valor de RPC más alto podría beneficiarse si agregas un índice
o agregar una
Cláusula |
|
AVG_ROWS_SPOOLED |
FLOAT64 |
La cantidad promedio de filas escritas en un disco temporal (no en la memoria) por la instrucción de la consulta. Usa esta estadística para identificar consultas que podrían ser de latencia alta
que son costosas en términos de memoria y no se pueden ejecutar en ella. Para mitigarlo, cambia el orden de |
EXECUTION_COUNT
, AVG_LATENCY_SECONDS
y LATENCY_DISTRIBUTION
por errores
incluyen consultas que fallaron debido a una sintaxis incorrecta o que encontraron un
y se produjo un error transitorio,
pero se intentó reintentar.
Estadísticas agregadas
También hay tablas que realizan un seguimiento de los datos agregados de todas las consultas para las que Spanner capturó estadísticas en un período específico:
SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE
: Consultas en intervalos de 1 minutoSPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE
: Consultas en intervalos de 10 minutosSPANNER_SYS.QUERY_STATS_TOTAL_HOUR
: Consultas en intervalos de 1 hora
Estas tablas tienen las siguientes propiedades:
Cada tabla contiene datos de intervalos de tiempo no superpuestos de la longitud que se especifica en el nombre de la tabla.
Los intervalos se basan en tiempos de reloj. Los intervalos de 1 minuto finalizan en el minuto, los intervalos de 10 minutos finalizan cada 10 minutos a partir de la hora y los intervalos de 1 hora finalizan en la hora.
Por ejemplo, a las 11:59:30 a.m., los intervalos más recientes disponibles para las consultas de SQL son los siguientes:
- 1 minuto: de 11:58:00 a 11:58:59 a.m.
- 10 minutos: de 11:40:00 a 11:49:59 a.m.
- 1 hora: de 10:00:00 a 10:59:59 a.m.
Cada fila contiene estadísticas de todas las consultas que se ejecutaron en la base de datos durante el intervalo especificado, combinadas. Solo hay una fila por intervalo de tiempo y, además, incluye consultas completadas, consultas con errores y consultas que canceló el usuario.
Las estadísticas capturadas en las tablas
TOTAL
pueden incluir consultas que Spanner no capturó en las tablasTOP
.Algunas columnas de estas tablas se exponen como métricas en Cloud Monitoring. Las métricas expuestas son las siguientes:
- Recuento de ejecuciones de consultas
- Errores de consulta
- Latencias de consultas
- Recuento de filas mostradas
- Recuento de filas analizadas
- Recuento de bytes mostrados
- Tiempo de CPU de la consulta
Para obtener más información, consulta Métricas de Spanner.
Esquema de la tabla
Nombre de la columna | Tipo | Descripción |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Fin del intervalo en el que se produjeron las ejecuciones de consultas incluidas |
EXECUTION_COUNT |
INT64 |
Cantidad de veces que Spanner hizo la consulta durante el intervalo de tiempo. |
AVG_LATENCY_SECONDS |
FLOAT64 |
Promedio de tiempo, en segundos, para cada ejecución de consulta dentro de la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga. |
AVG_ROWS |
FLOAT64 |
Promedio de filas que mostró la consulta. |
AVG_BYTES |
FLOAT64 |
Promedio de bytes de datos que mostró la consulta, sin incluir la sobrecarga de codificación de transmisión. |
AVG_ROWS_SCANNED |
FLOAT64 |
Promedio de filas que analizó la consulta, sin incluir los valores borrados. |
AVG_CPU_SECONDS |
FLOAT64 |
Cantidad promedio de segundos de tiempo de CPU que Spanner dedicó todas para ejecutar la consulta. |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Cantidad de veces que la consulta falló durante el intervalo. |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Promedio de tiempo, en segundos, para cada ejecución de consulta que falló en la base de datos. Este promedio excluye la codificación y el tiempo de transmisión del conjunto de resultados, así como la sobrecarga. |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Cantidad de veces que el usuario canceló la consulta o falló debido a una conexión de red interrumpida durante el intervalo. |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Cantidad de veces que se agotó el tiempo de espera de la consulta durante el intervalo. |
AVG_BYTES_WRITTEN |
FLOAT64 |
Cantidad promedio de bytes que escribe la declaración. |
AVG_ROWS_WRITTEN |
FLOAT64 |
Promedio de filas modificadas por la instrucción. |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
Es la cantidad de veces que se ejecutaron consultas como parte de las transacciones de lectura y escritura. Esta columna te ayuda a determinar si puedes evitar las contenciones de bloqueo algunas consultas a transacciones de solo lectura. |
LATENCY_DISTRIBUTION |
ARRAY<STRUCT> |
Un histograma del tiempo de ejecución en todas las consultas. Los valores se miden en segundos.
Especifica el array de la siguiente manera:
Para calcular la latencia del percentil de la distribución, usa la función Para obtener más información, consulta Percentiles y métricas con valores de distribución. |
Retención de datos
Como mínimo, Spanner conserva los datos para cada tabla durante los siguientes períodos:
SPANNER_SYS.QUERY_STATS_TOP_MINUTE
ySPANNER_SYS.QUERY_STATS_TOTAL_MINUTE
: Intervalos que abarcan las 6 horas anteriores.SPANNER_SYS.QUERY_STATS_TOP_10MINUTE
ySPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE
: Intervalos que abarcan los 4 días anteriores.SPANNER_SYS.QUERY_STATS_TOP_HOUR
ySPANNER_SYS.QUERY_STATS_TOTAL_HOUR
: Intervalos que abarcan los 30 días anteriores.
Consultas de ejemplo
En esta sección, se incluyen varias instrucciones de SQL de ejemplo que recuperan estadísticas de consultas. Puedes ejecutar estas instrucciones de SQL con el bibliotecas cliente Google Cloud CLI Consola de Google Cloud.
Enumerar las estadísticas básicas de cada consulta durante un período determinado
La siguiente consulta muestra los datos sin procesar de las consultas principales en el minuto anterior:
SELECT text,
request_tag,
interval_end,
execution_count,
avg_latency_seconds,
avg_rows,
avg_bytes,
avg_rows_scanned,
avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;
Obtén una lista de las consultas con el mayor uso de CPU
La siguiente consulta muestra las consultas con el uso de CPU más alto en la hora anterior:
SELECT text,
request_tag,
execution_count AS count,
avg_latency_seconds AS latency,
avg_cpu_seconds AS cpu,
execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;
Conoce el recuento total de ejecuciones en un período determinado
La siguiente consulta muestra la cantidad total de consultas ejecutadas en el intervalo completo de 1 minuto más reciente:
SELECT interval_end,
execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_minute);
Determinar la latencia promedio de una consulta
La siguiente consulta muestra la información de latencia promedio de una consulta específica:
SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";
Encuentra la latencia del percentil 99 para las consultas
La siguiente consulta muestra el percentil 99 del tiempo de ejecución entre las consultas. se ejecutó en los últimos 10 minutos:
SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;
Comparar la latencia promedio con la latencia del percentil 99 ayuda a identificar posibles consultas anómalas con tiempos de ejecución altos.
Encuentra las consultas que analizan la mayor cantidad de datos
Puedes usar la cantidad de filas analizadas por una consulta como una medida de la cantidad de datos que analizó la consulta. La siguiente consulta muestra el número de filas analizadas por consultas ejecutadas en la hora anterior:
SELECT text,
execution_count,
avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;
Encontrar las sentencias que escribieron la mayor cantidad de datos
Puedes usar la cantidad de filas escritas (o bytes escritos) por DML como una medida de la cantidad de datos que la consulta modificó. La siguiente consulta muestra la cantidad de filas escritas por las instrucciones DML ejecutadas en la hora anterior:
SELECT text,
execution_count,
avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;
Total del uso de CPU en todas las consultas
La siguiente consulta muestra el número de horas de CPU usadas en la hora anterior:
SELECT (avg_cpu_seconds * execution_count / 60 / 60)
AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_total_hour);
Haz una lista de las consultas que fallaron en un período determinado
La siguiente consulta muestra los datos sin procesar, incluido el recuento de ejecución y la latencia promedio de las consultas con errores para las consultas principales durante el minuto anterior:
SELECT text,
request_tag,
interval_end,
execution_count,
all_failed_execution_count,
all_failed_avg_latency_seconds,
avg_latency_seconds,
avg_rows,
avg_bytes,
avg_rows_scanned,
avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
Encontrar el recuento total de errores en un período determinado
La siguiente consulta muestra la cantidad total de consultas que no se ejecutaron en el intervalo completo de 1 minuto más reciente.
SELECT interval_end,
all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;
Muestra las consultas que tienen más tiempo de espera
La siguiente consulta muestra las consultas con el recuento de tiempo de espera más alto en la hora anterior.
SELECT text,
execution_count AS count,
timed_out_execution_count AS timeout_count,
avg_latency_seconds AS latency,
avg_cpu_seconds AS cpu,
execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;
Encontrar la latencia promedio de las ejecuciones correctas y con errores de una consulta
La siguiente consulta muestra la latencia promedio combinada, la latencia promedio de las ejecuciones exitosas y la latencia promedio de las ejecuciones fallidas de una consulta específica.
SELECT avg_latency_seconds AS combined_avg_latency,
all_failed_avg_latency_seconds AS failed_execution_latency,
( avg_latency_seconds * execution_count -
all_failed_avg_latency_seconds * all_failed_execution_count
) / (
execution_count - all_failed_execution_count ) AS success_execution_latency
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "select x from table where x=@foo;";
Soluciona problemas de uso elevado de CPU o latencia de consultas elevada con estadísticas de consultas
Las estadísticas de consulta son útiles cuando necesita investigar el alto uso de la CPU en su cuando se trata de una base de datos de Spanner o formas de consulta pesadas en tu base de datos. Inspeccionar las consultas que usan cantidades significativas de recursos de bases de datos brinda a los usuarios de Spanner una forma potencial de reducir los costos operativos y, quizás, mejorar las latencias generales del sistema.
Puedes usar código SQL o las estadísticas de consultas para investigar consultas problemáticas en tu base de datos. Lo siguiente los temas muestran cómo puedes investigar esas consultas usando código SQL.
Si bien el siguiente ejemplo se centra en el uso de CPU, se pueden seguir pasos similares para solucionar problemas de latencia elevada de consultas y encontrar las consultas con los latencias. Solo selecciona intervalos y consultas por tiempo de latencia en lugar de uso de CPU.
Selecciona un período para investigar
Para comenzar la investigación, busca un momento en el que la aplicación comience a experimentar un uso alto de CPU. Por ejemplo, si el problema comenzó a ocurrir alrededor del 24 de julio de 2020 a las 5:00 p.m. UTC.
Recopila estadísticas de consultas para el período seleccionado
Después de seleccionar un período para comenzar nuestra investigación, veremos las estadísticas recopiladas en la tabla QUERY_STATS_TOTAL_10MINUTE
alrededor de ese momento.
Los resultados de esta consulta pueden indicar cómo cambiaron la CPU y otras estadísticas de la consulta durante ese período.
La siguiente consulta muestra las estadísticas de consultas agregadas de 16:30 a 17:30 UTC inclusive. Usamos ROUND
en nuestra consulta a fin de restringir la cantidad de decimales para fines de visualización.
SELECT interval_end,
execution_count AS count,
ROUND(avg_latency_seconds,2) AS latency,
ROUND(avg_rows,2) AS rows_returned,
ROUND(avg_bytes,2) AS bytes,
ROUND(avg_rows_scanned,2) AS rows_scanned,
ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
interval_end >= "2020-07-24T16:30:00Z"
AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;
La ejecución de la consulta arrojó los siguientes resultados.
interval_end | count | Latencia | Filas mostradas | bytes | Filas analizadas | CPU promedio |
---|---|---|---|---|---|---|
2020-07-24T16:30:00Z | 6 | 0.06 | 5.00 | 536.00 | 16.67 | 0.035 |
2020-07-24T16:40:00Z | 55 | 0.02 | 0.22 | 25.29 | 0.22 | 0.004 |
2020-07-24T16:50:00Z | 102 | 0.02 | 0.30 | 33.35 | 0.30 | 0.004 |
2020-07-24T17:00:00Z |
154 |
1.06 |
4.42 |
486.33 |
7792208.12 |
4.633 |
2020-07-24T17:10:00Z | 94 | 0.02 | 1.68 | 106.84 | 1.68 | 0.006 |
2020-07-24T17:20:00Z | 110 | 0.02 | 0.38 | 34.60 | 0.38 | 0.005 |
2020-07-24T17:30:00Z | 47 | 0.02 | 0.23 | 24.96 | 0.23 | 0.004 |
En la tabla anterior, vemos que el tiempo de CPU promedio, la columna average_cpu en la tabla de resultados, es más alta en los intervalos destacados que terminan en 17:00. También vemos una cantidad mucho mayor de filas analizadas en promedio. Esto indica que las consultas más demandantes se ejecutaron entre las 16:50 y las 17:00. Elige ese intervalo para investigar más en el paso siguiente.
Encontrar las consultas que causan un alto uso de CPU
Con un intervalo de tiempo para investigar seleccionado, ahora consultamos la tabla QUERY_STATS_TOP_10MINUTE
. Los resultados de esta consulta pueden ayudar a indicar qué consultas causan un uso de CPU elevado.
SELECT text_fingerprint AS fingerprint,
execution_count AS count,
ROUND(avg_latency_seconds,2) AS latency,
ROUND(avg_cpu_seconds,3) AS cpu,
ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10MINUTE
WHERE
interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;
Cuando se ejecuta esta consulta, se obtienen los siguientes resultados.
Fingerprint | count | Latencia | cpu | total_cpu |
---|---|---|---|---|
5505124206529314852 |
30 |
3.88 |
17.635 |
529.039 |
1697951036096498470 |
10 |
4.49 |
18.388 |
183.882 |
2295109096748351518 | 1 | 0.33 | 0.048 | 0.048 |
11618299167612903606 | 1 | 0.25 | 0.021 | 0.021 |
10302798842433860499 | 1 | 0.04 | 0.006 | 0.006 |
123771704548746223 | 1 | 0.04 | 0.006 | 0.006 |
4216063638051261350 | 1 | 0.04 | 0.006 | 0.006 |
3654744714919476398 | 1 | 0.04 | 0.006 | 0.006 |
2999453161628434990 | 1 | 0.04 | 0.006 | 0.006 |
823179738756093706 | 1 | 0.02 | 0.005 | 0.0056 |
Las 2 consultas principales, destacadas en la tabla de resultados, son valores atípicos en términos de CPU y latencia promedio, así como la cantidad de ejecuciones y la CPU total. Investiga la primera consulta que aparece en estos resultados.
Compara las ejecuciones de consultas a lo largo del tiempo
Después de limitar la investigación, podemos enfocarnos en la tabla QUERY_STATS_TOP_MINUTE
. Cuando comparamos las ejecuciones en el tiempo de una consulta en particular, podemos buscar correlaciones entre la cantidad de filas o bytes que se muestran, o la cantidad de filas analizadas y la latencia o CPU elevada. Una desviación puede indicar que no hay uniformidad en los datos. La cantidad constante de filas analizadas puede indicar la falta de índices adecuados o un orden de unión subóptimo.
Investiga la consulta que muestra el mayor uso de CPU promedio y los de latencia ejecutando la siguiente sentencia que filtra en text_fingerprint de esa consulta.
SELECT interval_end,
ROUND(avg_latency_seconds,2) AS latency,
avg_rows AS rows_returned,
avg_bytes AS bytes_returned,
avg_rows_scanned AS rows_scanned,
ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;
Cuando se ejecuta esta consulta, se muestran los siguientes resultados.
interval_end | Latencia | Filas mostradas | bytes_devueltos | Filas analizadas | cpu |
---|---|---|---|---|---|
2020-07-24T17:00:00Z | 4.55 | 21 | 2365 | 30000000 | 19.255 |
2020-07-24T16:00:00Z | 3.62 | 21 | 2365 | 30000000 | 17.255 |
2020-07-24T15:00:00Z | 4.37 | 21 | 2365 | 30000000 | 18.350 |
2020-07-24T14:00:00Z | 4.02 | 21 | 2365 | 30000000 | 17.748 |
2020-07-24T13:00:00Z | 3.12 | 21 | 2365 | 30000000 | 16.380 |
2020-07-24T12:00:00Z | 3.45 | 21 | 2365 | 30000000 | 15.476 |
2020-07-24T11:00:00Z | 4.94 | 21 | 2365 | 30000000 | 22.611 |
2020-07-24T10:00:00Z | 6.48 | 21 | 2365 | 30000000 | 21.265 |
2020-07-24T09:00:00Z | 0.23 | 21 | 2365 | 5 | 0.040 |
2020-07-24T08:00:00Z | 0.04 | 21 | 2365 | 5 | 0.021 |
2020-07-24T07:00:00Z | 0.09 | 21 | 2365 | 5 | 0.030 |
Si examinamos los resultados anteriores, vemos que la cantidad de filas analizadas, la CPU usada y la latencia cambiaron de manera significativa a las 9:00 a.m. Para comprender por qué estos números aumentaron de forma considerable, examinaremos el texto de la consulta y veremos si algún cambio en el esquema puede haber afectado la consulta.
Usa la siguiente consulta para recuperar el texto de la consulta que estamos investigando.
SELECT text,
text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;
Esta acción devuelve el siguiente resultado.
text | text_truncated |
---|---|
selecciona * en los pedidos en los que o_custkey = 36901; | falso |
Cuando examinamos el texto de la consulta que se muestra, nos dimos cuenta de que la consulta filtra en un campo llamado o_custkey
. Esta es una columna sin clave en la tabla orders
. Como suele suceder, hubo un índice en esa columna que se descartó cerca de las 9 a.m. Esto explica el cambio en el costo de esta consulta. Podemos volver a agregar el índice o, si la consulta se ejecuta con poca frecuencia, decidir no incluir el índice y aceptar el costo de lectura más alto.
Nuestra investigación se enfocó hasta el momento en las consultas que se completaron de forma correcta y descubrimos un motivo por el cual la base de datos experimentaba cierta degradación del rendimiento. En el siguiente paso, nos enfocaremos en las consultas fallidas o canceladas, y mostraremos cómo examinar esos datos para obtener más estadísticas.
Investiga las consultas con errores
Las consultas que no se completan de forma correcta consumen recursos antes de que se agote el tiempo de espera, se cancelen o fallen. Spanner realiza un seguimiento de ejecuciones y los recursos consumidos por las consultas con errores junto con las consultas y los recursos, especialmente aquellos sensibles.
Para verificar si las consultas con errores son un factor importante del uso del sistema, primero podemos verificar cuántas consultas fallaron en el intervalo de interés.
SELECT interval_end,
all_failed_execution_count AS failed_count,
all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
interval_end >= "2020-07-24T16:50:00Z"
AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;
interval_end | Cantidad de consultas fallidas | Latencia |
---|---|---|
2020-07-24T16:52:00Z | 1 | 15.211391 |
2020-07-24T16:53:00Z | 3 | 58.312232 |
Si seguimos investigando, podemos buscar consultas que tengan más probabilidades de fallar mediante el uso de la siguiente consulta.
SELECT interval_end,
text_fingerprint,
execution_count,
avg_latency_seconds AS avg_latency,
all_failed_execution_count AS failed_count,
all_failed_avg_latency_seconds AS failed_latency,
cancelled_or_disconnected_execution_count AS cancel_count,
timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
interval_end | text_fingerprint | execution_count | Cantidad de consultas fallidas | cancelar_recuento | para_recuento |
---|---|---|---|---|---|
2020-07-24T16:52:00Z | 5505124206529314852 | 3 | 1 | 1 | 0 |
2020-07-24T16:53:00Z | 1697951036096498470 | 2 | 1 | 1 | 0 |
2020-07-24T16:53:00Z | 5505124206529314852 | 5 | 2 | 1 | 1 |
Como se muestra en la tabla anterior, la consulta con la huella digital 5505124206529314852
falló varias veces durante diferentes intervalos de tiempo. Dado un patrón de fallas como este, es interesante comparar la latencia de las ejecuciones correctas con las fallidas.
SELECT interval_end,
avg_latency_seconds AS combined_avg_latency,
all_failed_avg_latency_seconds AS failed_execution_latency,
( avg_latency_seconds * execution_count -
all_failed_avg_latency_seconds * all_failed_execution_count
) / (
execution_count - all_failed_execution_count ) AS success_execution_latency
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852;
interval_end | latencia_promedio_combinada | latencia_ejecución_fallida | latencia_ejecución_exitosa |
---|---|---|---|
2020-07-24T17:00:00Z | 3.880420 | 13.830709 | 2.774832 |
Aplica las prácticas recomendadas
Después de identificar una consulta que puede optimizarse, podemos observar el perfil de consulta y tratar de optimizar mediante las prácticas recomendadas de SQL.
¿Qué sigue?
Usa las consultas activas más antiguas para determinar las consultas activas más largas.
Obtén más información sobre Investigación del uso alto de CPU.
Obtén más información sobre otras herramientas de introspección.
Obtén más información sobre otros datos que Spanner almacena para cada base de datos en la tablas de esquema de información de la base de datos.
Obtén más información sobre las prácticas recomendadas de SQL para Spanner