La utilidad de creación de perfiles perf que se envía con el kernel de Linux es extremadamente útil para examinar el comportamiento de múltiples procesos y de todo el sistema, pero hace mucho más que el perfilado de la CPU para el que se suele utilizar. Probablemente hayas mirado perf top -az o perf top -u postgres salida, pero eso es solo un poquito de lo que puede hacer. (Si desea la versión TL/DR, salte a "Sondas dinámicas de espacio de usuario").
Una de las grandes ventajas de perf es que no es intrusivo. No tiene que adjuntar un depurador e interrumpir la ejecución. No tiene que ejecutar comandos directamente bajo un generador de perfiles en un entorno especial. No es necesario reiniciar el servidor para depurar una carga de trabajo problemática y, a menudo, no es necesario volver a compilar con las opciones de depuración. Esto es extremadamente útil cuando intenta rastrear problemas de rendimiento en un sistema en vivo, ya que le permite probar teorías sobre lo que podría estar sucediendo rápidamente y con un impacto mínimo.
perfeccionar no es solo un generador de perfiles, también tiene soporte de rastreo. La creación de perfiles se basa en el muestreo del estado del sistema cuando se activa mediante contadores de rendimiento de hardware o software; da una muestra estadística de los puntos donde el sistema pasa la mayor parte del tiempo. En cambio, el rastreo toma muestras cada vez que ocurre un evento de rastreo en particular, por lo que es mucho más útil para eventos poco frecuentes pero importantes.
Cuando se trabaja con PostgreSQL, una de las características más emocionantes de perf es la capacidad de rastrear procesos en el espacio del usuario . ¿Quiere saber con qué frecuencia su PostgreSQL intercambia segmentos WAL, con qué frecuencia realiza búsquedas de claves externas, etc.? ¿Para un backend de PostgreSQL o en todo el clúster? perfeccionar puede ayudar con eso.
Los puntos de rastreo del espacio del usuario y del kernel se pueden combinar y se pueden usar al mismo tiempo como perfiles de contador de rendimiento para ayudarlo a obtener una buena imagen del sistema. perfeccionar puede capturar rastros de pila tanto del kernel como del espacio del usuario, y también puede realizar visualizaciones estadísticas. Los puntos de seguimiento del espacio de usuario se crean con sondas dinámicas; los del espacio del núcleo pueden estar predefinidos o pueden ser sondas dinámicas.
Entonces, ¿cómo usas algunas de estas funciones?
Instalar las herramientas
Primero, asegúrese de estar usando un perf actual . Este artículo fue escrito en Fedora 19 con perf 3.11.6 en x86_64, y algunas de las funciones son relativamente nuevas.
Si desea resultados de la pila de espacio de usuario, querrá que el código que está viendo se cree con -Og -ggdb -fno-omit-frame-pointer . Si está utilizando un perf construido con libunwind no necesita punteros de cuadro; vea esta publicación de Stack Overflow y RH Bugzilla #1025603. Nada de esto es necesario si solo está interesado en los datos del lado del kernel. Si está utilizando paquetes de distribución, es posible que deba instalar -debuginfo paquetes también.
Todas las siguientes pruebas se ejecutaron con paquetes PGDG PostgreSQL 9.2 de stock de http://yum.postgresql.org/ usando un perf reconstruido con libunwind apoyo de acuerdo con las instrucciones anteriores.
Puntos de seguimiento y sondeos del kernel
perfeccionar puede capturar datos de puntos de seguimiento del kernel predefinidos, algunos de los cuales son informativos cuando se analizan problemas con la fragmentación de la memoria, E/S de disco, etc. Puede obtener una lista de puntos de seguimiento con sudo perf list . Se pueden especificar listas de puntos de seguimiento y se admiten comodines. Por ejemplo, si queremos obtener estadísticas de escritura y vaciado de disco en una instancia de PostgreSQL en ejecución, podríamos ejecutar:
sudo perf record -g dwarf -e block:block_rq_issue,syscalls:sys_enter_fsync -u postgres sleep 10
para capturar los datos. En lugar de dormir, puede usar ningún comando y presionar control-C cuando haya terminado de capturar, o puede usar algún otro comando como psql -c para activar la carga de trabajo que desea medir.
-u postgres perfila todos los procesos que se ejecutan como usuario postgres . En su lugar, puede usar -a para la creación de perfiles de todo el sistema en todas las CPU. También es posible rastrear solo un backend. Iniciar psql , ejecute select pg_backend_pid() , ejecute perf con -p $el_pid , luego inicie la carga de trabajo en el mismo psql sesión.
Cuando trabaja con PostgreSQL, el proceso de destino predeterminado, que es el comando, se ejecuta bajo el control de perf , no suele ser muy útil porque el backend hace la mayor parte del trabajo, no psql . Todavía es útil usar el subcomando para controlar la carga de trabajo y el tiempo de la prueba.
Una vez que haya capturado los datos, puede usar el informe de rendimiento para examinarlo. Hay demasiadas opciones para discutir aquí:para controlar la agregación y simplificación de resultados, la visualización de seguimiento de pila, curses interactivos frente a la salida de informes de texto y más.
Tome esta sesión como ejemplo, donde hay una sesión de shell (terminal "T2") y una sesión de postgres conectada a la base de datos "regreso" (terminal "T1"):
T1| regresión=> seleccionar pg_backend_pid();T1| pg_backend_pidT1| ----------------T1| 4495T1|(1 fila)
T2| $ sudo perf record -g dwarf -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -p 4495
T1| regress=> crear tabla x como seleccionar a FROM generar_series(1,1000000) a;T1| regresión=>
T2| $ ^CT2| [registro de rendimiento:se despertó 332 veces para escribir datos] T2 | [ registro de rendimiento:capturó y escribió 86,404 MB de datos de rendimiento (~3775041 muestras) ]T2|T2| $ informe de rendimiento sudo -g
Puede usar informe de rendimiento 's curses gui para profundizar en la traza, o puede usar el perf report --stdio opción para hacer que transmita datos a stdout. Por ejemplo, si desea realizar seguimientos de la pila, puede ejecutar:
$ sudo perf report -g --stdio... blah blah ...# Ejemplos:1 de evento 'syscalls:sys_enter_fsync'# Recuento de eventos (aprox.):1## Símbolo de objeto compartido de comando superior# .. ...... ........ ............. .....................# 100.00 % postgres libc-2.17.so [.] __GI___libc_fsync | --- __GI___libc_fsync mdimmedsync heap_sync intorel_shutdown standard_ExecutorRun ExecCreateTableAs PortalRunUtility PortalRunMulti PortalRun PostgresMain ServerLoop PostmasterMain main __libc_start_main _start (nil)... bla, bla...
mostrando eso para el evento syscalls:sys_enter_fsync hubo un evento con la pila anterior, un fsync invocado a través de ExecCreateTableAs .
(Por alguna razón, aún no he podido precisar el fsync() final no parece ser capturado por perf cuando psql se ejecuta directamente bajo el control de perf . Esto no es un problema con perf stat , solo registro de rendimiento . Es por eso que estoy saltando a través de aros para preseleccionar el backend por pid arriba).
Sondas dinámicas de espacio de usuario
A veces, está más interesado en que algo suceda dentro de PostgreSQL en sí mismo que en los eventos dentro del kernel que PostgreSQL desencadena. Versiones más recientes de perf puede ayudar con esto mediante la inserción de puntos de seguimiento dinámicos que se activan en llamadas en programas de espacio de usuario.
Supongamos que está interesado en ver la actividad de WAL y quiere ver cuándo XLogFlush , XLogFileInit o XLogFileOpen son llamados. Puede insertar puntos de seguimiento dinámicos para estas llamadas con perf :
sudo perf probe -x `cuál postgres` XLogFileInitsudo perf probe -x `cuál postgres` XLogFileOpensudo perf probe -x `cuál postgres` XLogFlush
Solo puede sondear símbolos externos (no estáticos, no ocultos por indicadores -fvisibility) a menos que haya creado con -ggdb . perfeccionar se quejará no se encontraron símbolos si intenta utilizar un símbolo que no existe. Al momento de escribir perf no admite el uso de información de depuración externa para buscar símbolos para sondas, aunque puede usarse para análisis de pila. En general, si es un externo en src/include puedes usarlo con perf .
Cada punto de rastreo imprimirá el nombre del punto de rastreo creado y puede usar perf probe -l para enumerarlos todos de todos modos:
$ sudo perf probe -l probe_postgres:XLogFileInit (en 0x000000000009a360) probe_postgres:XLogFileOpen (en 0x000000000009a860) probe_postgres:XLogFlush (en 0x00000000000a0670)
Estas sondas ahora se pueden usar como eventos de rendimiento. Echemos un vistazo a la actividad de xlog durante una carga de trabajo de muestra, monitoreando todo el clúster mientras ejecuto pgbench:
sudo perf record -g dwarf -u postgres -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlush
Pruébelo usted mismo con perf report -g . Así es como se ven los resultados. Puede usar opciones como -g fractal,0 para controlar el detalle. Podrá ver el porcentaje de aciertos de un contador dado que provienen de una u otra rama de la pila, el pid y el proceso, etc. El --sort Las opciones le brindan más control sobre la agregación y la agrupación.
Pero espera, hay más
También debería consultar la estadística de rendimiento y parte superior perforada comandos Pueden tomar las mismas listas de eventos que perf record , aunque por alguna extraña razón su soporte de filtro de proceso es diferente.
Este es un ejemplo que ejecuta una carga de trabajo ficticia y analiza los puntos de seguimiento del kernel de E/S durante la ejecución:
$ sudo perf stat -e block:block_rq_*,syscalls:sys_enter_write,syscalls:sys_enter_fsync -a -r 5 -- psql -q -U postgres craig -c "soltar tabla si existe x; crear tabla x como seleccionar a DESDE generar_series(1,1000000) a;"; Estadísticas de contador de rendimiento para 'psql -U postgres craig -c drop table si existe x; crear la tabla x como seleccionar un DE generar_series(1,1000000) a;' (5 ejecuciones):0 block:block_rq_abort [100.00%] 0 block:block_rq_requeue [100.00%] 97 block:block_rq_complete ( +- 14.82% ) [100.00%] 96 block:block_rq_insert ( +- 14.97% ) [100.00%] 98 block:block_rq_issue ( +- 14.67% ) [100.00%] 0 block:block_rq_remap [100.00%]10,607 syscalls:sys_enter_write ( +- 0.17% ) [100.00%] 1 syscalls:sys_enter_fsync 0.908835058 segundos de tiempo transcurrido ( +- 18.31% ) /pre>Puede ver que está haciendo un promedio de alrededor de 100 solicitudes de E/S de capa de bloque sobre 10k write() y haciendo un solo fsync(). Parte de eso es ruido de fondo del sistema, ya que estamos haciendo todos los perfiles del sistema (-a ), pero dado que el sistema está bastante inactivo, no es mucho y se promedia en cinco ejecuciones.
De manera similar, usando las sondas dinámicas que agregamos anteriormente, vigile la actividad de xlog durante una ejecución de pgbench:
$ sudo perf stat -e probe_postgres:XLogFileInit,probe_postgres:XLogFileOpen,probe_postgres:XLogFlush -a -- /usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000vacío inicial...fin. tipo de transacción:TPC-B (más o menos) factor de escala:100 modo de consulta:simple número de clientes:2 número de subprocesos:1 número de transacciones por cliente:10000 número de transacciones realmente procesadas:20000/20000 tps =715,854663 (incluido el establecimiento de conexiones) tps =716,092133 ( excluyendo el establecimiento de conexiones) Estadísticas de contador de rendimiento para '/usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000':64 probe_postgres:XLogFileInit [100.00%] 0 probe_postgres:XLogFileOpen [100.00%] 55,440 probe_postgres:XLogFlush 27,987364469 segundos transcurridosHay mucho más que puede hacer, incluida la captura del estado de las variables locales con perf probe . Escribiré algunos ejemplos útiles de eso más adelante. Mientras tanto, juega, explora y diviértete con una nueva herramienta de diagnóstico.
Actualizar: Michael Paquier escribió recientemente un artículo relacionado sobre el seguimiento de PostgreSQL con systemtap que puede ser de interés para los lectores de este. Tienes que recompilar Pg para usar ese enfoque, pero la sintaxis es mejor y ofrece algunas otras ventajas.
