Cosas clave para monitorear en PostgreSQL:análisis de su carga de trabajo

Cosas clave para monitorear en PostgreSQL:análisis de su carga de trabajo

En los sistemas informáticos, el monitoreo es el proceso de recopilar métricas, analizar, computar estadísticas y generar resúmenes y gráficos sobre el rendimiento o la capacidad de un sistema, así como generar alertas en caso de problemas inesperados o fallas que requieren atención o acción inmediata. Por lo tanto, el monitoreo tiene dos usos:uno para el análisis y la presentación de datos históricos que nos ayudan a identificar tendencias a mediano y largo plazo dentro de nuestro sistema y, por lo tanto, nos ayudan a planificar las actualizaciones, y otro para la acción inmediata en caso de problemas.

El monitoreo nos ayuda a identificar problemas y reaccionar ante esos problemas relacionados con una amplia gama de campos, tales como:

• Infraestructura/Hardware (físico o virtual)
• Red
• Almacenamiento
• Software del sistema
• Software de aplicación
• Seguridad

El monitoreo es una parte importante del trabajo de un DBA. PostgreSQL, tradicionalmente, ha sido conocido por ser de "bajo mantenimiento" gracias a su diseño sofisticado y esto significa que el sistema puede vivir con poca asistencia en comparación con otras alternativas. Sin embargo, para instalaciones serias donde la alta disponibilidad y el rendimiento son de importancia clave, el sistema de base de datos debe monitorearse regularmente.

El rol del DBA de PostgreSQL puede ascender a niveles más altos dentro de la jerarquía de la empresa además de los estrictamente técnicos:además del monitoreo básico y el análisis de rendimiento, debe ser capaz de detectar cambios en los patrones de uso, identificar las posibles causas, verificar las suposiciones y finalmente traducir el hallazgos en términos comerciales. Por ejemplo, el DBA debe ser capaz de identificar algún cambio repentino en una determinada actividad que podría estar relacionado con una posible amenaza a la seguridad. Por lo tanto, el rol del DBA de PostgreSQL es un rol clave dentro de la empresa y debe trabajar en estrecha colaboración con otros jefes de departamento para identificar y resolver los problemas que surjan. El monitoreo es una gran parte de esta responsabilidad.

PostgreSQL proporciona muchas herramientas listas para usar para ayudarnos a recopilar y analizar datos. Además, debido a su extensibilidad, proporciona los medios para desarrollar nuevos módulos en el sistema central.

PostgreSQL depende en gran medida del sistema (hardware y software) en el que se ejecuta. No podemos esperar que un servidor PostgreSQL funcione bien si hay problemas en cualquiera de los componentes vitales del resto del sistema. Entonces, el rol del DBA de PostgreSQL se superpone con el rol del administrador del sistema. A continuación, mientras examinamos qué observar en el monitoreo de PostgreSQL, encontraremos métricas y variables dependientes del sistema, así como cifras específicas de PostgreSQL.

El monitoreo no es gratis. La empresa/organización debe realizar una buena inversión con el compromiso de gestionar y mantener todo el proceso de seguimiento. También agrega una ligera carga en el servidor PostgreSQL. Esto es poco de qué preocuparse si todo está configurado correctamente, pero debemos tener en cuenta que esta puede ser otra forma de hacer un mal uso del sistema.

Conceptos básicos de monitoreo del sistema

Las variables importantes en el monitoreo del sistema son:

• Uso de CPU
• Uso de la red
• Espacio en disco/Utilización del disco
• Uso de RAM
• IOPS de disco
• Intercambiar uso de espacio
• Errores de red

Aquí hay un ejemplo de ClusterControl que muestra gráficos para algunas variables críticas de PostgreSQL provenientes de pg_stat_database y pg_stat_bgwriter (que cubriremos en los siguientes párrafos) mientras ejecuta pgbench -c 64 -t 1000 pgbench dos veces:

Notamos que tenemos un pico en lectura de bloques en la primera ejecución, pero nos acercamos a cero durante la segunda ejecución ya que todos los bloques se encuentran en shared_buffers.

Otras variables de interés son la actividad de paginación, interrupciones, cambios de contexto, entre otras. Hay una plétora de herramientas para usar en Linux/BSD y sistemas unix o similares a unix. Algunos de ellos son:

• pd:para obtener una lista de los procesos en ejecución

• top/htop/systat:para el monitoreo de la utilización del sistema (CPU/memoria)

• vmstat:para la supervisión general de la actividad del sistema (incluida la memoria virtual)

• iostat/iotop/top -mio:para monitoreo IO

• ntop:para monitoreo de red

Aquí hay un ejemplo de vmstat en un cuadro de FreeBSD durante una consulta que requiere algunas lecturas de disco y también algunos cálculos:

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

Repitiendo la consulta, no notaríamos ninguna nueva ráfaga en la actividad del disco, ya que esos bloques de disco ya estarían en la memoria caché del sistema operativo. Aunque el DBA de PostgreSQL debe ser capaz de comprender completamente lo que sucede en la infraestructura subyacente donde se ejecuta la base de datos, el monitoreo de sistemas más complejos suele ser un trabajo para el administrador del sistema, ya que este es un tema amplio en sí mismo.

En Linux, un atajo muy útil para la superior La utilidad está presionando "C", que alterna mostrando la línea de comando de los procesos. PostgreSQL por defecto reescribe la línea de comando de los backends con la actividad SQL real que están ejecutando en ese momento y también el usuario.

Conceptos básicos de supervisión de PostgreSQL

Las variables importantes en el monitoreo de PostgreSQL son:

• Rendimiento de caché de búfer (aciertos de caché frente a lecturas de disco)
• Número de confirmaciones
• Número de conexiones
• Número de sesiones
• Puntos de control y estadísticas de bgwriter
• Aspiradoras
• Cerraduras
• Replicación
• Y por último, pero definitivamente no menos importante, consultas

En general, hay dos formas en una configuración de monitoreo para realizar la recopilación de datos:

• Para adquirir datos a través de un Registro
• Para adquirir datos consultando el sistema PostgreSQL

La adquisición de datos basada en archivos de registro depende del registro de PostgreSQL (configurado correctamente). Podemos utilizar este tipo de registro para el procesamiento "fuera de línea" de los datos. El monitoreo basado en archivos de registro es más adecuado cuando se requiere una sobrecarga mínima para el servidor PostgreSQL y cuando no nos importan los datos en vivo o recibir alertas en vivo (aunque el monitoreo en vivo usando datos de archivos de registro puede ser posible, por ejemplo, dirigiendo el registro de postgresql a syslog y luego transmitir syslog a otro servidor dedicado para el procesamiento de registros).

Recopilador de estadísticas de PostgreSQL

PostgreSQL proporciona un amplio conjunto de vistas y funciones fácilmente disponibles a través del subsistema Recopilador de estadísticas. De nuevo, esos datos se dividen en dos categorías:

• Información dinámica sobre lo que está haciendo el sistema en este momento.
• Estadísticas acumuladas desde que se restableció por última vez el subsistema del recopilador de estadísticas.

Vistas de estadísticas dinámicas proporcionar información sobre la actividad actual por proceso (pg_stat_activity), el estado de la replicación física (pg_stat_replication), el estado de espera física (pg_stat_wal_receiver) o lógica (pg_stat_subscription), ssl (pg_stat_ssl) y vacío (pg_stat_progress_vacuum).

Vistas de estadísticas recopiladas proporciona información sobre procesos en segundo plano importantes, como wal archiver, bgwriter y objetos de la base de datos:tablas de usuario o del sistema, índices, secuencias y funciones, así como las propias bases de datos.

A estas alturas, debería ser bastante obvio que existen múltiples formas de categorizar los datos relacionados con el monitoreo:

• Por fuente:
  • Herramientas del sistema (ps, top, iotop, etc.)
  • Archivo de registro de PgSQL
  • Base de datos
    • Dinámico
    • Recopilados
• Por operación de base de datos específica:
  • Caché de búfer
  • Compromisos
  • Consultas
  • Sesiones
  • Puntos de control
  • Etc.

Después de leer este artículo y experimentar con las nociones, conceptos y términos presentados, debería poder hacer una matriz 2D con todas las combinaciones posibles. Como ejemplo, la actividad específica de PostgreSQL (comando SQL) se puede encontrar usando:ps o top (utilidades del sistema), los archivos de registro de PostgreSQL, pg_stat_activity (vista dinámica), pero también usando pg_stat_statements, una extensión que se encuentra en contrib (vista de estadísticas recopiladas) . Asimismo, la información sobre bloqueos se puede encontrar en los archivos de registro de PostgreSQL, pg_locks y pg_stat_actividad (presentado justo debajo) usando wait_event y wait_event_type . Debido a esto, es difícil cubrir la vasta área de monitoreo de manera lineal unidimensional, y el autor corre el riesgo de crear confusión al lector debido a esto. Para evitar esto, cubriremos el monitoreo aproximadamente siguiendo el curso de la documentación oficial y agregando información relacionada según sea necesario.

Vistas de estadísticas dinámicas

Usando pg_stat_actividad podemos ver cuál es la actividad actual de los diversos procesos de back-end. Por ejemplo, si ejecutamos la siguiente consulta en las partes de la tabla con alrededor de 3 millones de filas:

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

Y ejecutemos la siguiente consulta, que necesita unos segundos para completarse:

testdb=# select avg(age(date_added)) FROM parts;

Al abrir una nueva terminal y ejecutar la siguiente consulta, mientras la anterior aún se está ejecutando, obtenemos:

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

La vista pg_stat_activity nos brinda información sobre el proceso de back-end, el usuario, el cliente, la transacción, la consulta, el estado, así como información completa sobre el estado de espera de la consulta.

Pero, ¿por qué 3 filas? En las versiones>=9.6, si una consulta se puede ejecutar en paralelo, o partes de ella se pueden ejecutar en paralelo, y el optimizador cree que la ejecución en paralelo es la estrategia más rápida, entonces crea una Recopilación o Reunir Fusionar nodo, y luego solicita como máximo max_parallel_workers_per_gather procesos de trabajo en segundo plano, que por defecto son 2, de ahí las 3 filas que vemos en el resultado anterior. Podemos diferenciar el proceso de back-end del cliente del trabajador en segundo plano usando el backend_type columna. Para que la vista pg_stat_activity esté habilitada, deberá asegurarse de que el parámetro de configuración del sistema track_activities Está encendido. pg_stat_activity proporciona información valiosa para determinar las consultas bloqueadas mediante el uso de las columnas wait_event_type y wait_event.

Una forma más refinada de monitorear declaraciones es a través de pg_stat_statements extensión contrib, mencionada anteriormente. En un sistema Linux reciente (Ubuntu 17.10, PostgreSQL 9.6), esto se puede instalar con bastante facilidad:

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Vamos a crear una tabla con 100000 filas y luego restablecer pg_stat_statements, reiniciar el servidor PostgreSQL, realizar una selección en esta tabla en el sistema (todavía frío) y luego ver el contenido de pg_stat_statements para la selección:

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Ahora realicemos la selección * una vez más y luego busquemos nuevamente en el contenido de pg_stat_statements para esta consulta:

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Entonces, la segunda vez que la declaración de selección encuentra todos los bloques requeridos en los búferes compartidos de PostgreSQL, y pg_stat_statements informa esto a través de shared_blks_hit . pg_stat_statements proporciona información sobre el número total de llamadas de una declaración, total_time, min_time, max_time y mean_time, que pueden ser extremadamente útiles cuando se trata de analizar la carga de trabajo de su sistema. Una consulta lenta que se ejecuta con mucha frecuencia debe requerir atención inmediata. Del mismo modo, las tasas de aciertos constantemente bajas pueden significar la necesidad de revisar los shared_buffers ajuste.

pg_stat_replication proporciona información sobre el estado actual de la replicación para cada wal_sender. Supongamos que hemos configurado una topología de replicación simple con nuestro principal y un modo de espera activo, luego podemos consultar pg_stat_replication en el principal (hacer lo mismo en el modo de espera no arrojará resultados a menos que hayamos configurado la replicación en cascada y este modo de espera específico sirva como un upstream a otros recursos de reserva aguas abajo) para ver el estado actual de la replicación:

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

Las 4 columnas sent_lsn , escribir_lsn , flush_lsn , replay_lsn díganos la posición WAL exacta en cada etapa del proceso de replicación en el modo de espera remoto. Luego creamos mucho tráfico en el primario con un comando como:

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

Y mira de nuevo pg_stat_replication:

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Ahora vemos que tenemos un retraso entre el primario y el standby representado en el sent_lsn , escribir_lsn , flush_lsn , replay_lsn valores. Desde PgSQL 10.0, pg_stat_replication también muestra el retraso entre un WAL vaciado localmente recientemente y el tiempo que se tardó en escribirlo, vaciarlo y reproducirlo de forma remota, respectivamente. Ver nulos en esas 3 columnas significa que el principal y el de reserva están sincronizados.

El equivalente de pg_stat_replication en el lado de espera se llama:pg_stat_wal_receiver:

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Cuando no hay actividad y el modo de espera ha reproducido todo, latest_end_lsn debe ser igual a sent_lsn en el primario (y todos los números de secuencia de registro intermedios).

De manera similar a la replicación física, en el caso de la replicación lógica, donde el editor asume la función principal y el suscriptor asume la función de reserva, naturalmente, la función de pg_stat_wal_receiver es tomado por pg_stat_subscription . Podemos consultar pg_stat_subscription de la siguiente manera:

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

Tenga en cuenta que en el lado del editor, la vista correspondiente es la misma que en el caso de la replicación física:pg_stat_replication .

Vistas de estadísticas recopiladas

pg_stat_archiver view tiene una fila que brinda información sobre el archivador wal. Mantener una instantánea de esta fila a intervalos regulares le permite calcular el tamaño del tráfico WAL entre esos intervalos. También brinda información sobre fallas al archivar archivos WAL.

pg_stat_bgwriter view da información muy importante sobre el comportamiento de:

• El punto de control
• El escritor de fondo
• Los backends (servicio al cliente)

Dado que esta vista brinda datos acumulativos desde el último restablecimiento, es muy útil crear otra tabla con marca de tiempo con instantáneas periódicas de pg_stat_bgwriter , para que sea fácil obtener una perspectiva incremental entre dos instantáneas. El ajuste es una ciencia (o magia), y requiere un amplio registro y monitoreo, así como una comprensión clara de los conceptos subyacentes y las partes internas de PostgreSQL para obtener buenos resultados, y esta vista es por dónde comenzar, buscando cosas como:

• ¿Están los puntos de control cronometrados la gran mayoría del total de los puntos de control? De lo contrario, se deben tomar medidas, medir los resultados e iterar todo el proceso hasta que no se encuentren mejoras.
• ¿Son los buffers_checkpoint una buena mayoría sobre los otros dos tipos (buffers_clean pero lo más importante buffers_backend ) ? Si los buffers_backend son altos, nuevamente, se deben cambiar ciertos parámetros de configuración, se deben tomar y reevaluar nuevas mediciones.

Pg_stat_[usuario|sys|todas]_tablas

El uso más básico de esas vistas es verificar que nuestra estrategia de vacío funcione como se esperaba. Los valores grandes de tuplas inactivas en relación con las tuplas activas significan un vaciado ineficiente. Esas vistas también brindan información sobre escaneos y recuperaciones de secuencias frente a índices, información sobre el número de filas insertadas, actualizadas, eliminadas y actualizaciones HOT. Debe intentar mantener el número de actualizaciones HOT lo más alto posible para mejorar el rendimiento.

Pg_stat_[usuario|sys|todos]_índices

Aquí el sistema almacena y muestra información sobre el uso de índices individuales. Una cosa a tener en cuenta es que idx_tup_read es más preciso que idx_tup_fetch. Índices no PK/ no únicos con bajo idx_scan se debe considerar su eliminación, ya que solo dificultan las actualizaciones HOT. Como se mencionó en el blog anterior, se debe evitar la indexación excesiva, la indexación tiene un costo.

Pg_statio_[usuario|sys|todas]_tablas

En esas vistas, podemos encontrar información sobre el rendimiento de la memoria caché con respecto a las lecturas del montón de tablas, las lecturas de índice y las lecturas TOAST. Una consulta simple para contar el porcentaje de aciertos y la distribución de los aciertos en las tablas sería:

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Esto nos dice que al menos el 50 % de las mesas tienen tasas de aciertos superiores al 96,93 % y el 83,5 % de las mesas tienen una tasa de aciertos superior al 59,4 %

Pg_statio_[usuario|sys|todos]_indexes

Esta vista contiene información de bloque de lectura/acierto para índices.

Pg_stat_base de datos

Esta vista contiene una fila por base de datos. Muestra parte de la información de las vistas anteriores agregada a toda la base de datos (bloques leídos, bloques golpeados, información sobre tups), alguna información relevante para toda la base de datos (xactions totales, archivos temporales, conflictos, tiempos muertos, tiempo de lectura/escritura) y finalmente el número de backends actuales.

Lo que debe buscar aquí es la proporción de blks_hit/(blks_hit + blks_read) :cuanto mayor sea el valor, mejor para las E/S del sistema. Sin embargo, los fallos no necesariamente deben tenerse en cuenta para las lecturas de disco, ya que es posible que la memoria caché del sistema de archivos del sistema operativo los haya atendido muy bien.

De manera similar a otras vistas de estadísticas recopiladas mencionadas anteriormente, se debe crear una versión con marca de tiempo de la pg_stat_database ver y tener una vista de las diferencias entre dos instantáneas consecutivas:

• ¿Está aumentando el número de reversiones?
• ¿O el número de xactions comprometidas?
• ¿Estamos teniendo muchos más conflictos que ayer (esto se aplica a los recursos en espera)?
• ¿Tenemos un número anormalmente alto de interbloqueos?

Todos esos son datos muy importantes. Los dos primeros pueden significar algún cambio en algún patrón de uso, eso debe ser explicado. Una gran cantidad de conflictos puede significar que la replicación necesita algunos ajustes. Un alto número de interbloqueos es malo por muchas razones. No solo el rendimiento es bajo porque las transacciones se revierten, sino que también si una aplicación sufre interbloqueos en una topología maestra única, los problemas solo se amplificarán si pasamos a multimaestro. En este caso, el departamento de ingeniería de software debe reescribir las partes del código que causan los interbloqueos.

Cerraduras

El bloqueo es un tema muy importante en PostgreSQL y merece su(s) propio(s) blog(s). Sin embargo, el monitoreo básico de bloqueos debe realizarse de la misma manera que los otros aspectos del monitoreo presentados anteriormente. pg_bloqueos view proporciona información en tiempo real sobre los bloqueos actuales en el sistema. Podemos capturar bloqueos de larga espera configurando log_lock_waits , la información sobre las largas esperas se registrará en el registro de PgSQL. Si notamos un bloqueo alto inusual que da como resultado largas esperas, como en el caso de los interbloqueos mencionados anteriormente, los ingenieros de software deben revisar cualquier pieza de código que pueda causar bloqueos prolongados, p. bloqueo explícito en la aplicación (LOCK TABLE o SELECT... FOR UPDATE).

Al igual que en el caso de los interbloqueos, un sistema con bloqueos cortos pasará más fácilmente a una configuración multimaestro.