Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

Consideraciones Preliminares
Antes de comenzar debemos tener en cuenta a
que plataformas est destinado este White Paper:

Sistema Operativo: Linux, Windows. Otros

derivados de Unix podran incluirse.
Base de Datos: Postgresql 8.1 a 8.3

En este documento, ud. encontrar los caminos

para monitorear un servidor Postgresql utilizando las
herramientas incorporadas en el sistema operativo
ms, algunas adicionales que pueden ser descargas
gratuitamente desde el sitio pgfoundry.org (repositorio
oficial de Postgresql).
Para entender de manera cabal este White
Paper, le aconsejamos tener conocimientos bsicos
de programacin sobre bash (GNU/Linux y derivados
de Unix) y batch en Windows. Tambin deber
conocer muy pequeos conceptos de expresiones
regulares en Perl o Python, pero no sern obligatorios
en un principio.

Objetivos de la monitorizacin
Los fines principales de monitorear un servidor
de bases de datos son:

Verificar el consumo de recursos.

Actividad positiva del mismo.
Tiempo de respuesta del servidor.
Recabar la mayor cantidad de informacin a
fin de poder tener los suficientes datos para
ubicar donde esta el problema.
Deteccin de problemas de hard o red.
Obtener informacin de una determinada
tarea o consulta (especial para puesta a punto
de sentencias o servidor).

Por lo que deducimos que tenemos tres grupos:

actividad del motor, comportamiento del servidor e
investigacin de consultas.

Informacin sobre procesos

Los procesos son tareas que se ejecutan con
una cuota de tiempo en el procesador. Cada proceso,
puede tener hilos de ejecucin internos, simulando
tener varios procesos hijos. Los procesos pueden
consumir rangos de memoria y tiempos de
procesamiento determinados en la configuracin del
sistema operativo y desde las aplicaciones o
herramientas que los lanzan.
Sin embargo, es el SO quien administra de
manera transparente al usuario dichas asignaciones
(aunque uno pueda asignar determinados retoques
desde el SO). Para tales ajustes, es requerido poseer
privilegios desde el sistema operativo para poder
asignarlas.
Los procesos tienen asignados una prioridad. Es
esta la que le indica al sistema operativo cuanto
tiempo y cantidad de recursos de procesador le
asignar. En el caso especfico de plataformas Unix o
derivadas, este valor puede ir de -20 a 20, siendo la
menor, la ms prioritaria. En Windows, desde el
Administrador de Tareas, ctfmon.exe o tasklist desde
la lnea de comandos, podremos observar 6 niveles de
prioridades que van desde 'Tiempo Real' a 'Baja'.
Algunos sistemas operativos, tienen mecanismos
avanzados de asignacin de permisos, tal como
Solaris. Este, tiene la opcin de FP (Fixed Priority) el
cual ir variando la prioridad de acuerdo al uso de los
procesos.
Adems, podemos considerar el nivel de
intrusividad del monitoreo. A mayor cantidad de
informacin recolectada, ms se ver afectado el
sistema. Sin embargo y por lo general, los monitoreos
no suelen ser consumidores abruptos de recursos.
A diferencia de la monitorizacin normal, existen
los benchmarks. Estas tcnicas, permiten medir el
rendimiento de un determinado servidor, ya sea con
datos ficticios y aleatorios, como con datos reales de
una base. Este tipo de evaluaciones suele consumir
muchos recursos, en especial cuando se hacen
pruebas de stress sobre los servidores para conocer
los lmites de prestacin del mismo.

SIU

PGINA 1 DE 11

Consorcio SIU

Existen herramientas especficas en Postgresql

para la efectivizacin de este tipo de tests, entre ellos
el ms popular es PgBench. Sin embargo, y gracias al
auge de los lenguajes de scripting, es muy sencillo
disear un bench que incluya las particularidades de
nuestro sistema.
PgBench requiere primero una creacin de una
relacin (pgbench_branches), por lo que el primer
comando a ejecutar es 'pgbench -U<usuario> -i
<base>' . Luego, simplemente quitamos la opcin -i.
Podemos indicar cantidad de conexiones (-c num),
forma de comprometer una consulta (-M [extended|
simple|prepared]), cantidad de transacciones por
cliente (-t num), duracin en segundos (-T
num_segundos), entre otras.

Existe otra herramienta (benchmark.py), la cual

esta disponible de manera totalmente libre en nuestro
track (desarrollos.siu.edu.ar/trac/postgresql).
Las herramientas de benchmark permiten
conocer las capacidades de transacciones por un
lapso de tiempo en nuestros servidores. Es muy util
para cuando queremos modificar valores de
configuracin del motor o el servidor en general y
queremos comprobar su repercusin.

ps
lsof
free
iostat
mpstat
sar (si lo tiene)
htop o top
vmstat
/etc/init.d/postgres status o service postgres
status (de acuerdo a la distribucin)
netstat
pgrep
awk y perl (bsico)
Tuberas y redirecciones.
Permisos de usuarios (muchas veces si el
usuario no tiene permisos, no podr ver los
procesos)

Comandos
Podemos empezar por verificar que el servidor
este corriendo actualmente:

Para hacer ms legible el presente documento,

dividiremos el monitoreo de los procesos desde el SO
y desde la base, as como tambin las herramientas
especficas para cada plataforma.
Es recomendable, que los monitoreos en
sistemas en produccin sean constantes, pero no
intrusivos (a menos que una situacin en especial lo
requiera).
Con respecto a los tests, utilizaremos unidades
de testeo con herramientas propias de Postgresql.

Esto indica que el servidor est corriendo. Si

observamos en ms detalle nos esta diciendo:

Monitoreando en plataformas Linux o

Unix compatibles

Herramientas Previas
Existen una serie de comandos de los que el
usuario debe estar familiarizado con su salida:

SIU

El PID 4526 nos est informando el proceso

principal que se abri contra el cluster.
Tambin nos esta informando la ruta de la
ubicacin fsica del PGDATA.
El PID 4622 es el proceso de escritura sobre
la base.
El PID 4623 es el proceso que escribe sobre
la WAL.
El PID 4624 es el proceso de autovacuum y el
4625 es el recolector de estadsticas. Estos
dos procesos puede ser desactivados, pero
no es recomendable hasta el momento.
El PID 4739 es un cliente abierto. Nos est
indicando tambin sobre que base y que
usuario se estn utilizando. Incluido a esto,
PGINA 2 DE 11

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

tambin nos informa que se est accediendo

localmente.
Viendo ms de cerca los procesos, podemos
aadir mayores opciones al comando 'ps', para que
nos muestre informacin ms detallada.
# ps u C postgres C postmaster
Esto nos dar informacin ms precisa y
extensa, lo que incluye el tiempo de consumo en
CPU. Los parmetros C permiten filtran por
ocurrencias (postmaster es un alias que qued por
compatibilidad con versiones anteriores y se suele
utilizar para identificar la conexin al PGDATA).
Adems este comando nos permite hacer cosas
algo ms avanzadas como por ejemplo:
# ps f -o pid,ppid,args -C postgres -C postmaster

Una de las formas con la que podemos saber

cuantos archivos est accediendo el servidor
postgres, es tecleando:
# lsof | perl -lane 'if (/postgres|postmaster/) {print
$F[1]}' | wc -l
Esto es simplemente el total de ocurrencias que
filtra la expresin regular de Perl. Esta lnea no es lo
suficientemente inteligente como para diferenciar
entre distintos clusters (recordar que podemos tener
dos clusters en una mquina, lo que el conteo debera
hacerse por separado).
Mejorando la lnea anterior podemos obtener la
cantidad de procesos activos en un determinado
momento a fin de crear estadsticas de conexiones.
Simplemente deberemos aadir la siguente lnea de
comando en el cron del sistema y este se encargar
de loguear las ocurrencias.

Esto permitir visualizar en forma de arte ascii,

los procesos padre (PPID) y sus hijos (PID).

# ps -A | egrep '(postgres|postmaster)' | wc -l |
xargs echo `date +%Y%m%d%H%M ` >> /stat

Vamos a ir un paso ms all de los procesos.

Una de las cosas ms importantes que debemos
saber es a que archivos est accediendo un
determinado proceso. En el ejemplo siguiente, se
decidi obtener el listado de todos los archivos que
estn siendo accedidos por el proceso de escritura
WAL. Se le aadi un filtro 'head' para fines de
legibilidad.

En el cron simplemente podremos establecerlo

para correr cada 20 o 10 minutos de acuerdo a
nuestras necesidades:
*/10 * * * * root <comando>
Haciendo el siguiente anlisis conoceremos el
valor ms alto de procesos simultneos:
# awk '{print $2}' < /stat | sort -u | head -1
Debemos tener en cuenta que hay procesos que
son netamente del servidor, por lo que no son
conexiones clientes.

En el caso de necesitar conocer la cantidad

solamente, debemos agregar | wc -l .
Saber cuantos archivos consume el servidor de
base de datos es importante para tener en cuenta el
parmetro del kernel (maxfiles, openfiles). Este
parmetro establece el mximo de archivos abiertos.
Esto es de suma importancia en ambientes crticos.

SIU

Una de las cosas que ms afecta el rendimiento

de las bases de datos, son los procesos I/O. Por lo
tanto, cuanto ms logremos disminuir la latencia en
estos procesos, menores sern los tiempos de
respuesta. Es por eso que siempre es recomendable
configurar un RAID para una base de datos.
La herramienta iostat no permitir ver las
estadsticas de escritura y lectura en disco. Puede que
algunas versiones de Linux no incluyan las
PGINA 3 DE 11

Consorcio SIU

herramientas de stat, por lo que debemos instalarlas

ejecutando:
# apt-get install sysstat
Para hacerlo ms dinmico se recomienda
utilizar el modo continuo de iostat (-d) la herramienta
'watch':
# iostat d 2
La salida de dicho comando se puede apreciar

por lo que debemos evitar en todo momento que el

servidor se vea obligado a 'swapear'.
Los comandos free y vmstat nos permitirn ver el
espacio libre de memoria RAM y el uso de la particin
virtual o Swap.

La imagen anterior fue ejecutada con el comando

'free ; vmstat 1 1'. Se recomienda utilizar watch para
que muestre los resultados de manera constante y
dinmica.
Del primer prrafo del resultado del comando
anterior, nos interesa la lnea 'Swap'. Si verificamos el
valor 'used' est en 0, por lo que indica que hasta el
momento todos los procesos estn usando la RAM.

en la siguiente imagen:

De este grfico podemos observar que: el

servidor tiene 3 discos (de los cuales 1 es el que est
siendo escrito), el porcentaje de iowait (es la espera
para poder escribir y leer y a mayor porcentaje,
indicar necesidad de contar con ms recursos en
almacenamiento separados o RAID).
Si bien iostat y lsof son comandos muy tiles,
puede que no sean tan intuitivos a primera vista.
Existe una herramienta en particular que es muy
sencilla y que permite ver los recursos consumidos en
I/O por proceso. Es iotop, una herramienta
desarrollada en Python y pueden encontrarla en su
sitio web http://guichaz.free.fr/iotop. Esta herramienta
requiere que tengamos Python, kernel superior a 2.6 e
instalado el paquete python-pkg-resources (en debian
y derivados). Requiere adems algunos parmetros
en el kernel activados.
Cuando el servidor se queda sin memoria o el
proceso de postgres requiere ms memoria RAM de
la que el SO le puede otorgar a las aplicaciones, el
SO comienza a 'swapear' (anglicismo que indica que
se comenz a utilizar el archivo de intercambio para
trabajos que no pueden ser ejecutados en RAM por
falta de espacio o cuota asignada). Este mecanismo,
por lo general, arroja muy malos tiempos de respuesta

SIU

Tambin vemos que el total de la memoria RAM

es de 605000 MB, teniendo libres 308880.
EL segundo prrafo corresponde al comando
'vmstat', el cual nos indica que no hay actividad en la
swap (si 0, so 0).
Otra de las cosas que nos interesa saber es la
actividad del procesador. El comando para esto es
'mpstat'.

Es recomendable, utilizar 'top' o 'htop' para un

resumen de lo ms importante de todos estos
comandos. Ambas herramientas no estn en todos los
sistemas unix-like, por lo que es recomendable
conocer las herramientas estndar.
Tanto top como htop son muy amigables, por lo
que no deberan tener mayores inconvenientes en la
lectura de sus resultados.
En el caso de top es aconsejable que cuando se
despliegue la ejecucin, utilizar la ayuda (presionando
h) para poder adaptarlo a lo que queremos observar
con ms detalle. Por ejemplo: Si queremos desplegar
la informacin del tamao por proceso en el archivo
de intercambio y en memoria, debemos presionar f
(agrega columnas) y luego P y S.

PGINA 4 DE 11

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

muy til tener en cuenta o monitorear constantemente

estos valores, en especial si utilizamos PITR o
particiones separadas para los archivos de la WAL.
El comando df h nos mostrar todas las
particiones montadas y el espacio que se est
utilizando de cada una de ellas. Para saber el tamao
actual del directorio que contiene los archivos de la
WAL podemos utilizar du h /ruta/a/la/WAL.

Monitoreando en sistemas Windows

Verificando la apertura del servidor a la red

La monitorizacin en sistemas Windows se

puede hacer desde el Administrador de Tareas.

Hemos configurado el servidor para que pueda

escuchar sobre el puerto 5432, pero adems le
establecimos que pueda escuchar desde otro host
(esto ltimo agrega que el puerto no slo esta creado
sino habilitado para recibir y comunicarse con otros
clientes en otras terminales).

En esta imagen apreciamos que el servidor tiene

abierto el socket correspondiente.
La forma manual de investigar acerca de los
procesos es buscando dentro de la carpeta /proc. En
dicha carpeta encontraremos, por PPID, la
informacin de cada proceso.
Por ejemplo:
cd /proc && pgrep '(postgres|postmaster)' | awk
'{print $NF"/stat"}' | xargs cat
Esta lnea de comando simplemente muestra los
contenidos del archivo stat dentro de cada directorio
de /proc/<pid>.
Para conocer el contenido de los archivos de
/proc, lea el link [1] que se adjunta al final de la
documentacin.
Otra de las tareas importantes es monitorear el
espacio libre que queda en el disco. Si el disco se
llena, los datos no se corrompern pero el servidor
entrar en el estado PANIC y caer, por lo que es
SIU

Existen otras herramientas privativas y libres

para la medicin estadstica de los recursos.

PGINA 5 DE 11

Consorcio SIU

Desde la lnea de comando podemos utilizar

netstat, tasklist (similar al ps de unix-compatibles).

Iopp es una herramienta desarrollada en

postgres que sirve para medir las estadsticas de i/o
por
proceso
(http://git.postgresql.org/gitweb?
p=iopp.git;a=blob_plain;f=iopp.c;hb=HEAD). Requiere
ser compilada con gcc, las indicaciones se hallan en el
mismo rbol del git. Asimismo, se requiere tener
compilado el kernel de linux con el soporte para el
archivo /proc/<pid>/io. Nuevas versiones de kernel,
soportan esta opcin de manera automtica.

Utilizando herramientas propias de

PgFoundry y nativas del paquete
oficial
Como suele ser recomendable, las herramientas
especficas de un determinado aplicativo suelen ser
ms explcitas que las estndares.
Sin utilizar herramientas externas a la
empaquetacin oficial (dentro de la cual incluiremos
PgAdmin III), se puede monitorear la base a travs de
logs y consultas intensivas al catalogo. De ah, que es
necesario tener establecida la variable de recoleccin
de estadsticas activada (track_activities).
Como otra recomendacin, se encuentra elevar
el valor por defecto de la variable del motor
default_statistics_target. Un valor recomendado para
un servidor en produccin es superior a 100. Luego
de eso, se puede establecer un nmero mayor o
menor de acuerdo a la importancia de la tabla.
En cuanto a los logs, por lo general, en un
sistema en produccin variarn de acuerdo a una
situacin en especial. El nico recaudo a tener es que
a medida que el nivel de mensajes que se almacenan
son ms detallados y a valores ms bajos (DEBUG[15]) ms sobrecarga a nivel de procesamiento y mayor
espacio de almacenamiento se ver afectado. Por
ello, siempre se recomienda que el almacenamiento
de logs se haga separado del almacenamiento de la
base y los servidores de aplicacin. Esto adems
permite que el sistema de ficheros a utilizar sea el
ms sencillo (caso ext2-3, FAT).
La herramienta ms popular para el anlisis de
logs en Postgres es PgFouine. Ms detalle en la
seccin 'Archivado de Logs'.
SIU

Otra herramienta sencilla de instalar es pgstat.

Desarrollada en python, puede ser descargada del
PgFoundry y slo requiere descomprimir y ejecutar,
indicando a travs de parmetros la base y el usuario.
Est en versin beta an, pero es utilizable.
Personalmente realic algunas modificaciones en este
aplicativo, pueden escribirme al mail personal en caso
de estar interesados (ya que al momento de escribir
este documento, los cambios no fueron aprobados
an por el autor).
La herramienta grfica ms estable para el
monitoreo es PgAdmin. Para acceder a esta opcin
debemos ir al men Tools->Server Status. Ah
podremos ver la actividad de las conexiones, los
bloqueos y las transacciones. Desde all mismo
podremos seleccionar backends y cancelar sus
consultas o terminarlos. Se puede establecer inclusive
el intervalo en segundos.
Existe una herramienta que recientemente
adhiri un plug-in para recoleccin de estadsticas
(collectd). En el momento que se escribi este
documento la ltima versin es la 4.8.0. Para
descargar la misma utilizamos wget:
#
wget
http://ipv4.collectd.org/files/collectd4.8.0.tar.gz
# gzip d collectd-4.8.0.tar.gz
# tar xvf collectd-4.8.0.tar
Le recomiendo leer el link [2] para obtener
detalles ms avanzados de cmo configurar este
servicio. Para la compilacin se necesita el compilador
gcc y las libreras libdbd-pg-perl y libperl-dev, asi como
las libreras por estndar de gcc. Cuando ejecutemos
PGINA 6 DE 11

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

./configure (que por defecto tratar de compilar con

todos los plugins), debemos verificar que la lnea
postgresql
yes est en la salida. Caso contrario
puede que aparezca un dependency failed o un error
que no permita su compilacin.
Para la visualizacin del resultado de collectd,
necesitamos la herramienta rrdtool (instalable con aptget install).
Ms all de las herramientas disponibles para la
monitorizacin en caliente de la base de datos, otro
mtodo de monitoreo es utilizando el catalogo.
Las tablas-vistas que nos proveen informacin
de escritura y lectura de bloques son:

pg_stat_*
pg_statio*

Las consultas sobre el catlogo se realizan a

travs de SQL, y slo debemos considerar que
existen tipos de datos especficos para la relacin
entre las mismas (OID).
Asimismo poseemos funciones especiales para
la administracin de los backends, desde al base de
datos, permitiendo as, una administracin ms cabal
simplemente desde cualquier cliente.
Seguidamente veremos algunas de las posibles
consultas tiles al catalogo

SELECT SUM(n_tup_ins),
SUM(n_tup_upd), SUM(n_tup_del)
FROM pg_stat_all_tables;
Sumarizacin de los planes:
SELECT SUM(seq_scan),
SUM(seq_tup_read), SUM(idx_scan),
SUM(idx_tup_fetch)
FROM pg_Stat_all_tables;
Visualizar bloqueos:
SELECT mode, count(mode)
FROM pg_locks
GROUP BY mode ORDER BY mode;
Sumarizacin de I/O en bloques (bloques son de
8k), si desea saber en cantidad de Kb, multiplique por
8:
SELECT SUM(heap_blks_read) * 8
FROM pg_statio_user_tables;
SELECT SUM(idx_blks_read)
FROM pg_statio_user_tables;
SELECT SUM(toast_blks_read)
FROM pg_statio_user_tables;
SELECT SUM(tidx_blks_read)
FROM pg_statio_user_tables;

Contabilizar conexiones:

Tamao de las bases:

SELECT count(*) FROM pg_Stat_activity;

select pg_database_size(name);
select pg_tablespace_size(name);

Verificar hace cuanto se esta ejecutando la

ltima consulta de un backend:
SELECT (now() - query_start) as tiempo_query,
backend_start as back_vivo_desde,
current_query as query,
usename as usuario
FROM pg_stat_activity;
Commits y rollbacks por cada base:
SELECT datname, xact_commit, xact_rollback
FROM pg_Stat_database;
SIU

Sumarizacin de consultas DML:

Ver consultas actuales corriendo:

SELECT pg_stat_get_backend_pid(s.backendid)
as procpid,
pg_stat_get_backend_activity(s.backendid)
as current_query
FROM
(SELECT pg_Stat_get_backend_idset()
as backendid) AS s;
Uso de disco (cada pgina es tpicamente de 8k):
PGINA 7 DE 11

Consorcio SIU

SELECT relfilenode, relpages

FROM pg_class
WHERE relname = 'tabla';

podremos obtener una sumarizacin de las tuplas

Uso del disco para Toast:

SELECT relname, relpages
FROM pg_class ,
(SELECT reltoastrelid
FROM pg_class
WHERE relname = 'tabla') ss
WHERE oid = ss.reltoastrelid
OR oid = (SELECT reltoastidxid
FROM
pg_class
WHERE oid = reltoastrelid)
ORDER BY relname;
Para indices:
SELECT c2.relname, c2.relpages
FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer'
AND c.oid = i.indrelid
AND c2.oid = i.indexrelid
ORDER BY c2.relname;
Encontrar las tablas e ndices ms grandes
(tambin se puede multiplicar x 8):
SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;
Monitorear estado de las tuplas por esquema
(preferentemente utilice la opcin \x en psql):
SELECT schemaname ,
sum(seq_scan) as Seq_Scan,
sum(seq_tup_read) as Tuplas_seq_leidas,
sum(idx_scan) as Indices_scaneados ,
sum(idx_tup_fetch) as tuplas_x_indices_fetchs,
sum(n_tup_ins)
as
tuplas_insertadas,
sum(n_tup_upd) as tuplas_actualizadas,
sum(n_tup_del) as tuplas_borradas,
sum(n_tup_hot_upd) as tuplas_actualizadas_hot,
sum(n_live_tup) as tuplas_vivas,
sum(n_dead_tup) as tuplas_muertas
FROM pg_stat_all_tables
WHERE schemaname !~ '^pg.*'
GROUP BY schemaname;
La siguiente consulta obtiene los datos
necesarios para calcular los accesos a disco, tambin
SIU

vivas y muertas de toda la base:

SELECT
max(xact_commit) as commits,
max(xact_rollback) as rollbacks,
max(blks_read)::text
|| '/' || (max(blks_read)*8)::text || 'kbs'
as bloques_leidos,
max(blks_hit),
max(numbackends) as numbackends,
sum(seq_scan) as seq_scans,
sum(seq_tup_read) as seq_tup_reads,
sum(idx_scan) as idx_scans,
sum(idx_tup_fetch) as idx_fetchs,
sum(n_tup_ins) as tup_ins,
sum(n_tup_upd) as tup_upds,
sum(n_tup_del) as tup_dels,
max(c.locks) as locks,
max(d.sess) as active,
sum(k.dead) as dead_tup,
sum(k.live) as live_tup
FROM pg_stat_database a, pg_stat_user_tables b,
(SELECT xp.n_dead_tup as dead,
xp.n_live_tup as live
FROM
(SELECT c.relname as nombre
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_roles r
ON r.oid = c.relowner
LEFT JOIN pg_catalog.pg_namespace n
ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
AND n.nspname <> 'pg_catalog'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
PGINA 8 DE 11

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

) xx JOIN pg_stat_all_tables xp
ON xx.nombre = xp.relname
) k,
(SELECT count(*) as locks from pg_locks) c,
(SELECT count(*) as sess
FROM pg_stat_activity
WHERE current_query !~ '.*<IDLE>*') d
WHERE datname = '<nuestra_base>';

La vista pg_statio_user_tables contiene la

informacin por relacin, por lo que si queremos
visualizarla deberemos filtrar a travs del campo
relname o schemaname. Anteriormente mostramos
algunos ejemplos con esta vista.

La vista pg_stats, contiene las estadsticas por

columna, por lo que filtraremos por tabla.

most_common_freqs,
histogram_bounds, correlation
FROM pg_Stats
WHERE tablename !~ '^(pg|sql)';
Arroja:

Esta vista contiene los datos de cada columna, y

es importante ya que nos indicar la frecuencia de
determinados valores en las columnas, pudiendo
inferir directamente en el plan de ejecucin. El caso
ms comn es cuando un valor determinado tiene una
frecuencia superior a 0.3, en cuyo caso el planeador
preferir accesos por Seq_scan debido a la repeticin
de datos.
Esta vista utiliza los valores de la tabla
pg_statistic y es mucho ms accesible que esta ultima
en trminos de consultas.
La vista pg_stat_user_tables posee la siguiente
estructura:

Una consulta como la siguiente:

SELECT tablename, attname, avg_width,
n_distinct, most_common_vals,
SIU

Esta vista nos puede mostrar el estado de cada

relacin, incluidos sus ltimos mantenimientos, tuplas
actualizadas, estimacin de tuplas muertas y vivas,
etc.
PGINA 9 DE 11

Consorcio SIU

Tambin poseemos las vistas para los ndices,

que nos pueden indicar cuales son los ndices ms
utilizados o, lo que es ms til, los menos utilizados
(pg_stat_user_indexes, pg_statio_user_indexes).
Existen una serie de variables que mejoran la
recoleccin de estadsticas (adems obviamente de
realizar usualmente ANALYZE a la base).
Hay una serie de variables que influyen en la
recoleccin
de
estadsticas.
track_activities
(recoleccin de estadsticas por sesin) , track_counts
(recoleccin
de
estadsticas
por
base)
y
update_process_title (muy til si realizamos mucho
monitoreo desde consola del sistema operativo,
actualiza el ttulo del proceso de acuerdo a la consulta
) son las principales y por defecto vienen activadas.
Posiblemente si tenemos servidores de testeo o
desarrollo, queramos desactivarlas para evitar
recoleccin de estadsticas en mquinas que corren
varias aplicaciones y que no tienen un rol crucial en el
resultado.
Existen otras variables que pueden ser de
utilidad tambin: log_parser_stats, log_planner_stats,
log_executor_stats y log_statement_stats. Por defecto
estn en off. Las variables al ser activadas acarrean
mayor necesidad de procesamiento del recolector, por
lo que afectan directamente al rendimiento del
servidor. Si log_statement_stats est en on, las otras
deben estar en off, debido a que esta contiene las
otras. El resto son configuraciones por mdulo.
Esta opcin genera bastante overhead, as que
es recomendable activarla cuando estamos en
proceso de afinamiento de determinadas consultas o
del servidor.
Otra de ellas es default_statistics_target, por
defecto est en un valor de 10, pero en produccin se
recomienda un valor de 100 en produccin.

Archivado de Logs
Los archivos de logs suelen ser molestos porque
consumen ms I/O a medida que necesitamos ms
nivel de informacin.
SIU

Sin embargo, tenerlos bajo control es

indispensable ya que son los nicos testigos de un
error o una situacin a la que posiblemente no
podamos reproducir fcilmente en un ambiente
aislado.
Si vistamos el postgresql.conf observaremos ua
serie de variables especiales para esta tarea:
log_destination: este valor indica a que salida van
dirigidos los mensajes.
logging_collector:
necesario
queremos capturar los mensajes
log_directory:
directorio
almacenaremos los logs.

habilitarlo
en

el

si
cual

log_filename: nombre del archivo de log. Este

podr utilizar un formato compatible con POSIX
(%Y=ao, %m= mes, %d=da , etc.)
La rotacin de un log, es la accin de llegar a un
lmite establecido y empezar a loguear en un archivo vaco
o nuevo.

log_truncate_on_rotation:
esto
borrar
el
contenido de un log cuando sucede la rotacin. No es
recomendable para ambientes de produccin.
log_rotation_age y log_rotation_size: indican
cada cuanto se deber realizar la rotacin de los logs.
log_min_messages: esto indica el nivel de
logueo.
log_line_prefix: esta variable indica como va a
estar formateada la salida del log. PgFouine requiere
que establezcamos esta variable para analizar el log.
log_statement: esto indica que tipo de sentencias
irn al log (ddl, mod, all).
Tal como dijimos antes, la herramienta ms
popular de revisin de logs es PgFouine. Est escrito
en PHP, por lo que requiere la instalacin del paquete
php5-cli (Debian y derivados).
La desventaja que tiene PgFouine es que
requiere tocar la salida de los logs, por lo que al
principio puede parecer incomodo.

PGINA 10 DE 11

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en Sistemas

Windows, Linux y Solaris. Parte 1

PgFouine tiene varias opciones, las que

podremos ver ejecutando 'pgfouine.php' en la linea de
comando. La ejecucin bsica seria : 'pgfouine.php
-file <archivo_log> -logtype stderr'. La opcin logtype
deber corresponder a la que tenemos en el
postgresql.conf (log_destination). Previo a esto
debemos preformatear la salida (log_line_prefix) a:
'%t [%p]: [%l-1] ' si utilizamos stderr.

[1]

http://www.cyberciti.biz/files/linuxkernel/Documentation/filesystems/proc.txt

[2]
http://collectd.org/documentation/manpages/collectd.conf.5.shtml#pl
ugin_postgresql

Autor:
Emanuel Calvo Franco (SIU-Bs. As.)
Agradecimientos:
Al aporte incondicional de Alvaro Herrera
(PostgreSQL Core Developer - Chile), Nicols
Dominguez Florit (SIU-Tandil), Sebastin Natarelli
(SIU-Bs. As.).
Al aporte indirecto de los miembros de la lista
[email protected].

SIU

PGINA 11 DE 11