Administrar bases de datos no es una tarea fácil y puede ser fácilmente frustrante sin saber lo que sucede debajo de las sábanas. Ya sea tratando de averiguar si los nuevos índices son útiles, el recuento de transacciones en una base de datos en un momento determinado o quién está conectado a la base de datos en un momento dado, los datos que permiten a los administradores saber realmente cómo funcionan sus bases de datos son los reyes. Afortunadamente, con PostgreSQL, los datos de todo esto están disponibles en el catálogo del sistema de PostgreSQL.
El catálogo del sistema PostgreSQL es un esquema con tablas y vistas que contienen metadatos sobre todos los demás objetos dentro de la base de datos y más. Con él, podemos descubrir cuándo ocurren varias operaciones, cómo se accede a tablas o índices, e incluso si el sistema de base de datos está leyendo información de la memoria o necesita obtener datos del disco.
Aquí repasaremos una descripción general del catálogo del sistema y destacaremos cómo leerlo y cómo extraer información útil de él. Algunos de los metadatos son sencillos, y otras piezas requieren un poco de digestión para generar información realmente útil. De cualquier manera, PostgreSQL nos brinda una excelente plataforma para generar cualquier información que necesitemos sobre la base de datos en sí.
El catálogo de PostgreSQL
PostgreSQL almacena la información de metadatos sobre la base de datos y el clúster en el esquema 'pg_catalog'. PostgreSQL utiliza parcialmente esta información para realizar un seguimiento de las cosas, pero también se presenta para que las personas/procesos externos también puedan comprender el interior de las bases de datos.
El catálogo de PostgreSQL tiene una regla bastante sólida:mira, no toques. Si bien PostgreSQL almacena toda esta información en tablas como lo haría cualquier otra aplicación, los datos en las tablas están completamente administrados por el propio PostgreSQL y no deben modificarse a menos que sea una emergencia absoluta, e incluso entonces es probable que se requiera una reconstrucción posterior.
Repasaremos algunas tablas de catálogo útiles, cómo leer los datos y cosas inteligentes que podemos hacer con los datos mismos. Hay bastantes tablas en el catálogo que no revisaremos, pero toda la información de estas diversas tablas se puede encontrar en la documentación oficial de PostgreSQL.
Metadatos de todo el sistema
Una buena parte de las tablas que podemos consultar en el catálogo son tablas de "todo el sistema", donde no importa a qué base de datos estemos conectados, los datos representan todo el clúster, no una base de datos singular.
Información de la base de datos
La información general de la base de datos se almacena en pg_database y las estadísticas se almacenan en pg_stat_database.
pg_base de datos:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |La tabla pg_database contiene una fila para cada base de datos del clúster, incluidas las tres que vienen de fábrica (postgres, template0 y template1). Esta fila contiene información para la codificación, el límite de conexión y otros metadatos básicos.
Columnas de interés:
oid:el identificador del objeto, que no aparece en la salida de una consulta a menos que se haga referencia directamente. Este número coincidirá con un directorio en el directorio de datos de clústeres
datname:el nombre de la base de datos.
datdba:el propietario de la base de datos, oid hace referencia a pg_authid .oid.
codificación:la codificación de caracteres para esta base de datos, pg_encoding_to_char() se convertirá en un nombre legible.
datconnlimit:el número máximo de conexiones simultáneas permitidas en la base de datos.
dattablespace:el tablespace predeterminado para esta base de datos, hace referencia a pg_tablespace.oid.
pg_stat_base de datos:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Esta tabla de estadísticas es donde obtenemos datos interesantes y útiles. Cada fila de esta tabla contiene datos en vivo para cada base de datos y se puede exportar periódicamente para realizar un seguimiento a lo largo del tiempo si desea monitorear los cambios.
Transacciones
La información de la transacción se puede encontrar en las columnas xact_commit y xact_rollback, que contienen la cantidad de transacciones que la base de datos ha confirmado y revertido, respectivamente. Esto ayudará a mostrar qué tan activa es una base de datos, así como a detectar posibles fallas con programas que pueden estar fallando o retrocediendo a un ritmo alarmante.
Acceso a disco y memoria
La información sobre si los datos se recuperan o no del disco o de la memoria se almacena en las columnas blks_read y blks_hit. Blks_read muestra la cantidad de bloques que esta base de datos leyó del disco, mientras que blks_hit muestra la cantidad de bloques que se encontraron en el caché del búfer de PostgreSQL (representado por el parámetro shared_buffers). Dado que la RAM es mucho más rápida que el disco, idealmente veríamos blks_hit consistentemente más altos que blks_read y, si no, podemos volver a evaluar nuestra memoria disponible.
Tuplas
Las siguientes columnas tratan de tuplas. Tup_returned es el número de filas devueltas en la base de datos, que es el número de filas leídas por escaneos secuenciales si provienen de una tabla, o el número de entradas de índice devueltas cuando provienen de un índice”. Tup_fetched es el número de filas obtenidas en la base de datos, lo que significa que fueron el resultado de escaneos de mapas de bits, que es el número de filas de tablas obtenidas mediante escaneos de mapas de bits si se trata de una tabla, o filas de tablas obtenidas mediante escaneos de índices simples si se usa un índice.
También tenemos tup_inserted, tup_updated y tup_deleted, que representan el número de tuplas insertadas, actualizadas y eliminadas en esta base de datos, respectivamente. Esto ayudará a comprender cómo entran, cambian y salen los datos de la base de datos. Dado que las tuplas actualizadas y eliminadas dan como resultado filas muertas, los valores altos en estas columnas sugerirían que las operaciones de vacío automático se ajusten para satisfacer las necesidades de la actividad de la base de datos.
Conflictos
Si la base de datos en cuestión es un servidor en espera, la columna de conflictos es útil como una forma de rastrear cuántas consultas se cancelaron debido a conflictos con el modo en espera en "modo de recuperación". Si no es un clúster en espera, esta columna se puede ignorar.
Archivos / datos temporales
A veces, las consultas deberán escribirse en archivos temporales. Esto puede suceder cuando la cantidad de work_mem asignada a la conexión se ha agotado y necesita continuar una operación de clasificación en el disco en lugar de en la memoria. La columna temp_files rastrea el número de estos archivos que se crearon y temp_bytes rastrea el tamaño total de todos los archivos temporales utilizados. Estos datos pueden ayudar a informar el ajuste de work_mem, o incluso encontrar consultas que podrían necesitar reescritura si el tamaño del archivo temporal es demasiado grande.
Interbloqueos
La columna interbloqueos rastrea cuántas veces ocurre un interbloqueo. Dado que un interbloqueo puede causar errores en consultas que de otro modo no generarían errores, es bueno realizar un seguimiento de esto y asegurarse de que las aplicaciones no se pisoteen entre sí.
Tiempos de lectura y escritura
Las columnas blk_read_time y blk_write_time rastrean el número total de milisegundos que los backends de la base de datos dedican a leer y escribir datos, lo que puede ser útil si se intenta comparar/mejorar la velocidad de lectura/escritura del disco
Restablecimiento de estadísticas
Esta columna, stats_reset, simplemente muestra una marca de tiempo (con zona horaria) de la última vez que se restablecieron las estadísticas mencionadas en esta fila. Un valor nulo significa que no se han restablecido desde el inicio, o incluso posiblemente un bloqueo de la base de datos que puede haber eliminado estas estadísticas.
Puntos de control y el escritor de fondo
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00El clúster de PostgtreSQL administra la escritura de datos en el disco de varias maneras diferentes. En términos de "búferes sucios" (datos en la memoria que se han cambiado desde que se leyeron del disco, pero aún no se ha escrito ese cambio en el disco), esto lo hace un punto de control o el escritor de fondo. Dado que un búfer sucio debe escribirse en el disco antes de que pueda liberarse o reasignarse, asegurarse de que estos procesos estén bien ajustados es crucial, y esta tabla ayuda a arrojar luz sobre cómo funciona todo.
Puntos de control
Un punto de control ocurre según lo programado (representado por el parámetro checkpoint_timeout) o cuando se ha utilizado la cantidad máxima de archivos WAL desde el último punto de control y es necesario forzar un punto de control. De cualquier manera, un punto de control escribe búferes sucios en el disco y hay cuatro columnas que lo rastrean.
Las columnas checkpoints_timed y checkpoints_req muestran el número de puntos de control programados que ocurren (cronometrados) y el número de puntos de control solicitados (también conocidos como forzados). Un alto valor de escalada de checkpoint_req podría sugerir un valor de max_wal_size insuficiente.
Las columnas checkpoint_write_time y checkpoint_sync_time registran la cantidad total de tiempo (en milisegundos) que el proceso del punto de control ha pasado escribiendo y sincronizando en el disco.
Finalmente, buffers_checkpoint es el número total de búferes escritos en el disco por los puntos de control.
Escritor de fondo
El escritor de fondo es un proceso separado que escribe búferes sucios en el disco, lo que idealmente reduce la cantidad de trabajo que debe hacer el punto de control.
La columna buffers_clean representa el número de búferes escritos en el disco por el proceso en segundo plano. Cuando se compara con buffers_checkpoint, muestra qué parte de la carga de trabajo maneja cada proceso (con el conocimiento adicional de que el escritor en segundo plano tiene la posibilidad de escribir búferes varias veces si cambian con frecuencia, en comparación con menos frecuencia con un punto de control cronometrado).
Maxwrite_clean representa la cantidad de veces que el editor de fondo alcanzó la cantidad máxima de páginas para vaciar cada vez que se ejecuta (controlado con el parámetro bgwriter_lru_maxpages).
Tampones en general
Las columnas restantes nos muestran la información general del búfer, siendo buffers_backend la cantidad de búferes que un backend tuvo que escribir por sí mismo, en lugar de escritor en segundo plano o punto de control, buffers_backend_fsync es un conteo de cuántas veces un backend tuvo que ejecutar su propia llamada fsync, y buffers_alloc muestra el número de búferes que se han asignado en general.
Actividad y bloqueos de la base de datos
Hay dos vistas que muestran la actividad actual del usuario, pg_stat_activity y pg_locks. Cuando se consultan, muestran información sobre las conexiones actuales a las bases de datos y qué tipo de bloqueos tienen sobre qué relaciones.
pg_stat_actividad
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendInformación general
La vista pg_stat_activity muestra una fila para cada conexión a la base de datos y alguna información básica al respecto. La columna datname representa la base de datos a la que está conectada la conexión, pid es el ID de proceso de la conexión en el host de la base de datos y usesysid y usename representan el usuario de la base de datos conectado.
Para la fuente del cliente, client_addr es la dirección IP del host del que proviene la conexión, nulo significa que es una conexión de socket Unix local.
Marcas de tiempo
Hay cuatro columnas de marca de tiempo que muestran cuándo comenzaron ciertas cosas:backend_start es cuando se estableció realmente la conexión, xact_start es cuando comenzó la transacción actual (nulo si el cliente no tiene una transacción abierta), query_start es cuando comenzó la consulta actual o más reciente, y state_change es el momento en que el estado de la conexión cambió por última vez.
Estado de conexión
Los bits finales de pg_stat_activity cubren el estado real de la conexión. Si la consulta está esperando que otra libere los bloqueos, wait_event_type contiene información sobre qué tipo de evento de espera es, y la columna wait_event mostrará el nombre del evento de espera. Es una lista larga, pero se encuentra más información en la documentación de PostgreSQL.
Finalmente, la columna 'estado' muestra en qué estado se encuentra la conexión actual, como activa, inactiva, inactiva en transacción, y la columna de consulta mostrará la consulta real que se está ejecutando o la más reciente.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tLa tabla pg_locks funciona de la mano con pg_stat_activity si se analiza la actividad de las consultas. Cada vez que se realiza un bloqueo a una relación, esa información se almacena en pg_locks. Usando el pid de pg_stat_activity, podemos consultar pg_locks para ver en qué relaciones puede tener bloqueos una conexión, qué tipos de bloqueos son y si los bloqueos se han otorgado o no.
Las columnas más importantes son 'pid', que coincide con el pid de pg_stat_activity, 'relation' que coincide con el OID de pg_class, 'mode' que muestra el nombre del modo de bloqueo retenido y 'concedido' que indica si el bloqueo está activado o no. la pregunta ha sido concedida.
Información de replicación
Dado que PostgreSQL ha incorporado funciones de replicación, hay algunas vistas que arrojan luz sobre el rendimiento y el estado de la replicación en sí.
Ver pg_stat_replication: contiene una fila para cada proceso de remitente WAL, que contiene información sobre su estado, la ubicación de los archivos WAL en los que está trabajando y la información de conexión del host en espera que recibe los datos WAL para la replicación.
Ver pg_stat_wal_receiver: Si el clúster está en espera, contendrá una sola fila que muestra estadísticas sobre el proceso receptor del host.
Ver pg_stat_subscription: Si envía datos WAL a un nodo en espera, cada fila aquí representará esa suscripción y contendrá información sobre el estado de las suscripciones.
Ver pg_replication_slots: Contiene una lista de todas las ranuras de replicación que existen en el clúster y su estado actual.
Metadatos específicos de la base de datos
Dentro de cada base de datos hay una colección de tablas de catálogo que tienen información específica de la base de datos que se está consultando. Si estamos buscando datos específicos de estas tablas, debemos asegurarnos de estar conectados a la base de datos correcta cuando emitimos las consultas.
Aquí es donde puede entrar el corazón del análisis de datos, donde podemos ver cómo se accede a los datos de nuestros usuarios. Desde tablas, índices, secuencias, las consultas que ingresan a la base de datos y obtienen o modifican datos, sus acciones e impacto se almacenarán en estas tablas, y podemos ver esa información para tomar decisiones informadas sobre cómo administrar la base de datos en el futuro. carretera.
Metadatos de tabla
Los metadatos sobre nuestras tablas de usuarios se almacenan en las siguientes dos tablas y cada una tiene una fila para cada tabla de usuarios creada en el sistema. La tabla pg_stat_user_tables contiene estadísticas sobre el acceso de los usuarios a la tabla, mientras que pg_statio_user_tables contiene estadísticas de E/S para cada tabla.
NOTA:Los datos aquí no siempre son 100 % perfectos y se basan en análisis frecuentes de las tablas para ser correctos. Autoanalyze cubre esto, pero ajusta bien el proceso de autoanalyze para que pueda mantener buenas estadísticas sobre cada tabla. Si las estadísticas parecen estar desactivadas, ejecutar un ANALIZAR manualmente en la tabla las actualizará.
Tabla pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0Para las estadísticas de nuestra tabla de usuarios, tenemos bastantes datos.
Métodos de acceso a tablas
Cuando los clientes acceden a los datos de la tabla, lo hacen directamente oa través de índices. La columna 'seq_scan' cuenta el número de escaneos secuenciales que recibió la tabla, y 'seq_tup_read' cuenta el número de tuplas leídas a través de ese proceso. La columna 'idx_scan' cuenta cuántas veces se usó un índice en la tabla para obtener datos.
Actividad de tupla de tabla
Ahora tenemos un puñado de columnas que cuentan diferentes actividades en la tabla.
‘n_tup_ins’ rastrea el número de tuplas insertadas
'n_tup_upd' rastrea el número de tuplas actualizadas
‘n_tup_del’ rastrea el número de tuplas eliminadas
Estado de tupla de tabla
Debido a las actualizaciones y eliminaciones, podría haber tuplas inactivas que ya no sean datos activos, y el proceso de vacío eventualmente las liberará. Las columnas 'n_tup_ins' y 'n_tup_ins' rastrean el número de tuplas que están vivas y muertas, respectivamente. Cuando las tuplas muertas alcanzan un punto determinado, se iniciará un vacío automático, según la configuración de vacío automático.
Actividad de vacío de mesa
El mantenimiento de la tabla se realiza mediante VACUUM o AUTOVACUUM, y las estadísticas se recopilan mediante ANALYZE o AUTOANALYZE. Las siguientes cuatro columnas contienen las fechas en las que se ejecutó por última vez cada una de estas operaciones:'last_vacuum', 'last_autovacuum', 'last_analyze', 'last_autoanalyze'.
También tenemos cuatro columnas más convenientes que simplemente cuentan cuántas veces ocurren las acciones anteriores. Usando estos, podemos ver qué tablas obtienen la mayor actividad:'vacuum_count', 'autovacuum_count', 'analyze_count' y 'autoanalyze_count'.
Tabla pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0La salida de E/S es útil para ayudar a comprender cómo se accede a los datos de forma oculta. La columna 'heap_blks_read' representa la cantidad de bloques de disco leídos para esta tabla, y 'heap_blks_hit' representa los bloques de búfer leídos de la memoria en esta tabla. Esto es útil para saber si las consultas que acceden a la tabla constantemente tienen que ir al disco o recuperar los datos de la memoria.
Las estadísticas del índice en la tabla muestran la misma información con las columnas 'idx_blks_read' y 'idx_blks_hit'.
Por último, si la tabla tiene tablas TOAST, las columnas 'toast_blks_hit' y 'toast_blks_read' rastrean las tablas brindis, mientras que 'tdix_blks_read' y 'tdix_blks_read' rastrean los índices en esas tablas brindis.
Metadatos del índice
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Al igual que las contrapartes de la tabla, esta tabla contiene información sobre los índices específicamente. Una fila por índice, esta tabla muestra cuántas veces se escaneó el índice con la columna 'idx_scan', cuántas tuplas se leyeron con 'idx_tup_read' y cuántas filas en vivo se recuperaron realmente con 'idx_tup_fetch'.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380Para pg_statio_user_indexes, las dos columnas disponibles para datos son 'idx_blks_read' e 'idx_blks_hit', que representan la cantidad de bloques leídos del disco y de la memoria.
Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico¿Qué podemos hacer con estos datos?
¡Se creativo! Si las consultas a una tabla específica parecen ser extremadamente lentas, realice un seguimiento de su actividad a lo largo del tiempo, observe cuántos escaneos secuenciales obtiene en comparación con los escaneos de índice, observe si va al disco o a la memoria para los datos.
Si una tabla grande se sigue vaciando automáticamente con frecuencia, realice un seguimiento de las tuplas vivas a inactivas con el tiempo, tal vez necesite específicamente que se ajuste el vacío automático para que pueda completarse más rápido, o incluso tal vez la tabla sea candidata para la partición.
Dado que podemos ver cuándo los datos provienen del disco o de la memoria, podemos crear una proporción de memoria a disco a lo largo del tiempo, señalando si en algún momento la proporción cae durante el día.
La cantidad de tablas que cubrimos fue sobre los grandes bateadores, los datos principales que es útil saber sobre el funcionamiento interno de las bases de datos. Sin embargo, hay muchas más tablas en el catálogo del sistema que contienen datos útiles según la situación. Leer otras tablas como antes ayudará a proporcionar información sobre el estado de la base de datos en general.
Para obtener más información sobre tablas o vistas en el catálogo de PostgreSQL, visite la documentación oficial aquí, así como información sobre el recopilador de estadísticas aquí.
