pg_test_timing — mide la sobrecarga de tiempo (timing overhead)
pg_test_timing [option...]
El propósito de pg_test_timing es medir la sobrecarga de tiempo
en tu sistema y confirmar que el tiempo del sistema nunca retrocede.
Los sistemas que son lentos para recopilar datos de temporización pueden dar resultados de
EXPLAIN ANALYZE menos precisos.
pg_test_timing acepta las siguientes opciones de línea de comandos:
-d duration--duration=durationEspecifica la duración de la prueba, en segundos. Las duraciones más largas ofrecen una precisión ligeramente mejor y es más probable que descubran problemas con el reloj del sistema retrocediendo. La duración predeterminada de la prueba es de 3 segundos.
-V--versionMuestra la versión de pg_test_timing y termina.
-?--helpMuestra la ayuda sobre los argumentos de línea de comandos de pg_test_timing y termina.
Los buenos resultados mostrarán que la mayoría (>90%) de las llamadas de temporización individuales toman menos de un microsegundo. La sobrecarga promedio por ciclo será aún menor, por debajo de 100 nanosegundos. Este ejemplo de un sistema Intel i7-860 que utiliza una fuente de reloj TSC muestra un rendimiento excelente:
Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 ns
Histogram of timing durations:
< us % of total count
1 96.40465 80435604
2 3.59518 2999652
4 0.00015 126
8 0.00002 13
16 0.00000 2
Ten en cuenta que se utilizan unidades diferentes para el tiempo por ciclo que para el histograma. El ciclo puede tener una resolución de unos pocos nanosegundos (ns), mientras que las llamadas de temporización individuales solo se pueden resolver hasta un microsegundo (us).
Cuando el ejecutor de consultas está ejecutando una sentencia mediante
EXPLAIN ANALYZE, las operaciones individuales se temporizan además
de mostrar un resumen. La sobrecarga de tu sistema se puede comprobar
contando filas con el programa psql:
CREATE TABLE t AS SELECT * FROM generate_series(1,100000); \timing SELECT COUNT(*) FROM t; EXPLAIN ANALYZE SELECT COUNT(*) FROM t;
El sistema i7-860 medido ejecuta la consulta de conteo en 9.8 ms mientras
que la versión de EXPLAIN ANALYZE toma 16.6 ms, procesando cada una
un poco más de 100,000 filas. Esa diferencia de 6.8 ms significa que la sobrecarga de
temporización por fila es de 68 ns, aproximadamente el doble de lo que estimó pg_test_timing.
Incluso esa cantidad relativamente pequeña de sobrecarga hace que la sentencia de conteo completamente
temporizada tome casi un 70% más de tiempo. En consultas más sustanciales,
la sobrecarga de temporización sería menos problemática.
En algunos sistemas Linux más nuevos, es posible cambiar la fuente de reloj utilizada para recopilar datos de temporización en cualquier momento. Un segundo ejemplo muestra la desaceleración posible al cambiar a la fuente de tiempo acpi_pm más lenta, en el mismo sistema utilizado para los resultados rápidos anteriores:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Per loop time including overhead: 722.92 ns
Histogram of timing durations:
< us % of total count
1 27.84870 1155682
2 72.05956 2990371
4 0.07810 3241
8 0.01357 563
16 0.00007 3
En esta configuración, la consulta EXPLAIN ANALYZE de muestra anterior
toma 115.9 ms. Eso representa 1061 ns de sobrecarga de temporización, de nuevo un pequeño múltiplo
de lo medido directamente por esta utilidad. Semejante sobrecarga de temporización
significa que la consulta real en sí misma solo toma una pequeña fracción del
tiempo contabilizado, la mayor parte se consume en la sobrecarga. En
esta configuración, cualquier total de EXPLAIN ANALYZE que involucre
muchas operaciones temporizadas se vería inflado significativamente por la sobrecarga de temporización.
FreeBSD también permite cambiar la fuente de tiempo sobre la marcha y registra información sobre el temporizador seleccionado durante el arranque:
# dmesg | grep "Timecounter" Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounters tick every 10.000 msec Timecounter "TSC" frequency 2531787134 Hz quality 800 # sysctl kern.timecounter.hardware=TSC kern.timecounter.hardware: ACPI-fast -> TSC
Otros sistemas pueden permitir configurar la fuente de tiempo únicamente durante el arranque. En sistemas Linux más antiguos, el ajuste de kernel «clock» es la única forma de realizar este tipo de cambio. E incluso en algunos más recientes, la única opción que verás para una fuente de reloj es «jiffies». Jiffies es la implementación antigua de reloj por software de Linux, que puede tener una buena resolución cuando está respaldada por hardware de temporización suficientemente rápido, como en este ejemplo:
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
$ dmesg | grep time.c
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.153 MHz processor.
$ pg_test_timing
Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 97.75 ns
Histogram of timing durations:
< us % of total count
1 90.23734 27694571
2 9.75277 2993204
4 0.00981 3010
8 0.00007 22
16 0.00000 1
32 0.00000 1
La recopilación de información de temporización precisa se realiza normalmente en computadoras que utilizan relojes de hardware con diversos niveles de precisión. Con algún hardware, los sistemas operativos pueden pasar la hora del reloj del sistema casi directamente a los programas. El reloj del sistema también se puede derivar de un chip que simplemente proporciona interrupciones de temporización, tics periódicos a algún intervalo de tiempo conocido. En cualquier caso, los kernels de los sistemas operativos proporcionan una fuente de reloj que oculta estos detalles. Pero la precisión de esa fuente de reloj y la rapidez con la que puede devolver resultados varían en función del hardware subyacente.
Un mantenimiento del tiempo inexacto puede provocar inestabilidad en el sistema. Prueba cualquier cambio en la fuente de reloj con mucho cuidado. Las opciones predeterminadas de los sistemas operativos a veces se eligen para favorecer la confiabilidad en lugar de la mejor precisión. And si estás utilizando una máquina virtual, investiga las fuentes de tiempo recomendadas compatibles con ella. El hardware virtual se enfrenta a dificultades adicionales al emular temporizadores, y los proveedores suelen sugerir configuraciones específicas para cada sistema operativo.
La fuente de reloj Time Stamp Counter (TSC) es la más precisa disponible en las CPU de la generación actual. Es la forma preferida de rastrear el tiempo del sistema cuando el sistema operativo la admite y el reloj TSC es confiable. Hay varias formas en las que el TSC puede fallar al proporcionar una fuente de temporización precisa, lo que lo hace poco confiable. Los sistemas más antiguos pueden tener un reloj TSC que varía según la temperatura de la CPU, lo que lo hace inutilizable para la temporización. Intentar usar TSC en algunas CPU multinúcleo más antiguas puede dar un tiempo reportado que es inconsistente entre los múltiples núcleos. Esto puede dar lugar a que el tiempo retroceda, un problema que este programa verifica. E incluso los sistemas más nuevos pueden fallar al proporcionar una temporización TSC precisa con configuraciones de ahorro de energía muy agresivas.
Los sistemas operativos más nuevos pueden comprobar los problemas conocidos de TSC y cambiar a una fuente de reloj más lenta y estable cuando se detectan. Si tu sistema admite el tiempo TSC pero no lo tiene de forma predeterminada, es posible que esté desactivado por una buena razón. Y es posible que algunos sistemas operativos no detecten todos los problemas posibles correctamente, o permitan usar TSC incluso en situaciones en las que se sabe que es inexacto.
El High Precision Event Timer (HPET) es el temporizador preferido en los sistemas donde está disponible y el TSC no es preciso. El chip temporizador en sí es programable para permitir una resolución de hasta 100 nanosegundos, pero es posible que no veas tanta precisión en el reloj del sistema.
Advanced Configuration and Power Interface (ACPI) proporciona un temporizador de administración de energía (PM Timer), al que Linux se refiere como acpi_pm. El reloj derivado de acpi_pm proporcionará en el mejor de los casos una resolución de 300 nanosegundos.
Los temporizadores utilizados en el hardware de PC más antiguo incluyen el temporizador de intervalo programable 8254 (PIT), el reloj de tiempo real (RTC), el controlador avanzado programable de interrupciones (APIC) y el temporizador Cyclone. Estos temporizadores apuntan a una resolución de milisegundos.