Monitoreando Servidor Postgresql

8/3/2019 Monitoreando Servidor Postgresql

1/10

Consorcio SIU

Monitoreando y midiendo el rendimiento de un servidor Postgresql en SistemasWindows, Linux y Solaris. Parte 1

SIU PGINA 1 DE 10

Consideraciones Preliminares

Antes de comenzar debemos tener en cuenta aque plataformas est destinado este White Paper:

Sistema Operativo: Linux, Windows. Otrosderivados 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 lasherramientas incorporadas en el sistema operativoms, algunas adicionales que pueden ser descargasgratuitamente desde el sitio pgdoundry.org(repositorio oficial de Postgresql).

Para entender de manera cabal este WhitePaper, le aconsejamos tener conocimientos bsicosde programacin sobre bash (GNU/Linux y derivadosde Unix) y batch en Windows. Tambin deberconocer muy pequeos conceptos de expresionesregulares en Perl o Python, pero no sern obligatoriosen un principio.

Objetivos de la monitorizacin

Los fines principales de monitorear un servidorde 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 paraubicar donde esta el problema.

Deteccin de problemas de hard o red. Obtener informacin de una determinada

tarea o consulta (especial para puesta a puntode sentencias o servidor).

Por lo que deducimos que tenemos tres grupos:actividad del motor, comportamiento del servidor einvestigacin de consultas.

Informacin sobre procesos

Los procesos son tareas que se ejecutan conuna cuota de tiempo en el procesador. Cada proceso,puede tener hilos de ejecucin internos, simulandotener varios procesos hijos. Los procesos puedenconsumir rangos de memoria y tiempos deprocesamiento determinados en la configuracin delsistema operativo y desde las aplicaciones oherramientas que los lanzan.

Sin embargo, es el SO quien administra demanera transparente al usuario dichas asignaciones(aunque uno pueda asignar determinados retoquesdesde el SO). Para tales ajustes, es requerido poseerprivilegios desde el sistema operativo para poderasignarlas.

Los procesos tienen asignados una prioridad. Esesta la que le indica al sistema operativo cuantotiempo y cantidad de recursos de procesador leasignar. En el caso especfico de plataformas Unix oderivadas, este valor puede ir de -20 a 20, siendo lamenor, la ms prioritaria. En Windows, desde elAdministrador de Tareas, ctfmon.exe o tasklist desde

la lnea de comandos, podremos observar 6 nivelesde prioridades que van desde 'Tiempo Real' a 'Baja'.

Algunos sistemas operativos, tienen mecanismosavanzados de asignacin de permisos, tal comoSolaris. Este, tiene la opcin de FP (Fixed Priority) elcual ir variando la prioridad de acuerdo al uso de losprocesos.

Adems, podemos considerar el nivel deintrusividad del monitoreo. A mayor cantidad deinformacin recolectada, ms se ver afectado elsistema. Sin embargo y por lo general, los monitoreosno suelen ser consumidores abruptos de recursos.

A diferencia de la monitorizacin normal, existenlos benchmarks. Estas tcnicas, permiten medir elrendimiento de un determinado servidor, ya sea condatos ficticios y aleatorios, como con datos reales deuna base. Este tipo de evaluaciones suele consumirmuchos recursos, en especial cuando se hacenpruebas de stress sobre los servidores para conocerlos lmites de prestacin del mismo.


2/10

Consorcio SIU

SIU PGINA 2 DE 10

Existen herramientas especficas en Postgresqlpara la efectivizacin de este tipo de tests, entre ellosel ms popular es PgBench. Sin embargo, y gracias alauge de los lenguajes de scripting, es muy sencillodisear un bench que incluya las particularidades denuestro sistema.

PgBench requiere primero una creacin de unarelacin (pgbench_branches), por lo que el primercomando a ejecutar es 'pgbench -U -i'. 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 ensegundos (-T num_segundos), entre otras.

Tambin est disponible un script en Pythondesarrollado por Mariano Reingart y Emanuel CalvoFranco durante el viaje hacia la ciudad de Junn,cuando se dirigan al PgDay de esa misma ciudad. Elcdigo de dicho benchmark est disponible demanera totalmente libre y ser publicado en nuestrotrack (Wiki) prontamente. Sin embargo PgBench esuna herramienta muy til e informativa, por lo quecumple ampliamente sus propsitos.

Para hacer ms legible el presente documento,

dividiremos el monitoreo de los procesos desde el SOy desde la base, as como tambin las herramientasespecficas para cada plataforma.

Es recomendable, que los monitoreos ensistemas en produccin sean constantes, pero nointrusivos (a menos que una situacin en especial lorequiera).

Con respecto a los tests, utilizaremos unidadesde testeo con herramientas propias de Postgresql.

Monitoreando en plataformas Linuxo Unix compatibles

Herramientas Previas

Existen una serie de comandos cde los que elusuario debe estar familiarizado con su salida:

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 elusuario no tiene permisos, no podr ver losprocesos)

Comandos

Podemos empezar por verificar que el servidoreste corriendo actualmente:

Esto indica que el servidor est corriendo. Siobservamos en ms detalle nos esta diciendo:

El PPID 4526 nos est informando el procesoprincipal que se abri contra el cluster.Tambin nos esta informando la ruta de laubicacin fsica del PGDATA.

El PPID 4622 es el proceso de escritura sobrela base.

El PPID 4623 es el proceso que escribe sobre

la WAL. El PPID 4624 es el proceso de autovacuum y

el 4635 es el recolector de estadsticas. Estosdos procesos puede ser desactivados, perono es recomendable hasta el momento.

El PPID 4739 es un cliente abierto. Nos estindicando tambin sobre que base y queusuario se estn utilizando. Incluido a esto,tambin nos informa que se est accediendolocalmente.


3/10

Consorcio SIU


SIU PGINA 3 DE 10

Viendo ms de cerca los procesos, podemosaadir mayores opciones al comando 'ps', para quenos muestre informacin ms detallada.

# ps fauxw | egrep 'postmaster|postgres'

Esto nos dar informacin ms precisa yextensa, lo que incluye el tiempo de consumo enCPU.

Vamos a ir un paso ms all de los procesos.

Una de las cosas ms importantes que debemossaber es a que archivos est accediendo undeterminado proceso. En el ejemplo siguiente, sedecidi obtener el listado de todos los archivos queestn siendo accedidos por el proceso de escrituraWAL. Se le aadi un filtro 'head' para fines delegibilidad.

En el caso de necesitar conocer la cantidadsolamente, debemos agregar | wc -l .

Saber cuantos archivos consume el servidor debase de datos es importante para tener en cuenta elparmetro del kernel (maxfiles, openfiles). Esteparmetro establece el mximo de archivos abiertos.Esto es de suma importancia en ambientes crticos.

Una de las formas con la que podemos sabercuantos archivos est accediendo el servidorpostgres, es tecleando:

# lsof | perl -lane 'if (/postgres|postmaster/) {print$F[1]}' | wc -l

Esto es simplemente el total de ocurrencias quefiltra la expresin regular de Perl. Esta lnea no es losuficientemente inteligente como para diferenciarentre distintos clusters (recordar que podemos tenerdos clusters en una mquina, lo que el conteo deberahacerse por separado).

Mejorando la lnea anterior podemos obtener lacantidad de procesos activos en un determinadomomento a fin de crear estadsticas de conexiones.Simplemente deberemos aadir la siguente lnea decomando en el cron del sistema y este se encargarde loguear las ocurrencias.

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

En el cron simplemente podremos establecerlo

para correr cada 20 o 10 minutos de acuerdo anuestras necesidades:

*/10 * * * * root

Haciendo el siguiente anlisis conoceremos elvalor ms alto de procesos simultneos:

# awk '{print $2}' < /stat | sort -u | head -1

Debemos tener en cuenta que hay procesos queson netamente del servidor, por lo que no sonconexiones clientes.

Una de las cosas que ms afecta el rendimientode las bases de datos, son los procesos I/O. Por lotanto, cuanto ms logremos disminuir la latencia enestos procesos, menores sern los tiempos derespuesta. Es por eso que siempre es recomendableconfigurar un RAID para una base de datos.

La herramienta iostat no permitir ver lasestadsticas de escritura y lectura en disco. Parahacerlo ms dinmico se recomienda utilizar laherramienta 'watch':

# watch --interval=1 'iostat 1 1'

La salida de dicho comando se puede apreciaren la siguiente imagen:


4/10

Consorcio SIU

SIU PGINA 4 DE 10

De este grfico podemos observar que: elservidor tiene 3 discos (de los cuales 1 es el que estsiendo escrito), el porcentaje de iowait (es la esperapara poder escribir y leer y a mayor porcentaje,indicar necesidad de contar con ms recursos enalmacenamiento 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 muysencilla y que permite ver los recursos consumidos enI/O por proceso. Es iotop, una herramientadesarrollada en Python y pueden encontrarla en susitio web http://guichaz.free.fr/iotop. Esta herramienta

requiere que tengamos Python, kernel superior a 2.6e instalado el paquete python-pkg-resources (endebian y derivados). Requiere adems algunosparmetros en el kernel activados.

Cuando el servidor se queda sin memoria o elproceso de postgres requiere ms memoria RAM dela que el SO le puede otorgar a las aplicaciones, elSO comienza a 'swapear' (anglicismo que indica quese comenz a utilizar el archivo de intercambio paratrabajos que no pueden ser ejecutados en RAM porfalta de espacio o cuota asignada). Este mecanismo,por lo general, arroja muy malos tiempos de respuestapor 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 particinvirtual o Swap.

La imagen anterior fue ejecutada con el comando

'free ; vmstat 1 1'. Se recomienda utilizar watch paraque muestre los resultados de manera constante ydinmica.

Del primer prrafo del resultado del comandoanterior, nos interesa la lnea 'Swap'. Si verificamos elvalor 'used' est en 0, por lo que indica que hasta elmomento todos los procesos estn usando la RAM.

Tambin vemos que el total de la memoria RAMes de 605000 MB, teniendo libres 308880.

EL segundo prrafo corresponde al comando'vmstat', el cual nos indica que no hay actividad en laswap (si 0, so 0).

Otra de las cosas que nos interesa saber es laactividad del procesador. El comando para esto es'mpstat'.

Es recomendable, utilizar 'top' o 'htop' para unresumen de lo ms importante de todos estoscomandos. Ambas herramientas no estn en todos lossistemas unix-like, por lo que es recomendableconocer las herramientas estndar.

Tanto top como htop son muy amigables, por loque no deberan tener mayores inconvenientes en lalectura de sus resultados.

En el caso de top es aconsejable que cuando sedespliegue la ejecucin, utilizar la ayuda (presionandoh) para poder adaptarlo a lo que queremos observarcon ms detalle. Por ejemplo: Si queremos desplegarla informacin del tamao por proceso en el archivode intercambio y en memoria, debemos presionar f

(agrega columnas) y luego P y S.

Verificando la apertura del servidor a la red

Hemos configurado el servidor para que puedaescuchar sobre el puerto 5432, pero adems leestablecimos que pueda escuchar desde otro host(esto ltimo agrega que el puerto no slo esta creadosino habilitado para recibir y comunicarse con otrosclientes en otras terminales).


5/10

Consorcio SIU


SIU PGINA 5 DE 10

En esta imagen apreciamos que el servidor tieneabierto el socket correspondiente.

La forma manual de investigar acerca de losprocesos es buscando dentro de la carpeta /proc. Endicha carpeta encontraremos, por PPID, lainformacin de cada proceso.

Por ejemplo:

cd /proc && pgrep '(postgres|postmaster)' | awk'{print $NF"/stat"}' | xargs cat

Esta lnea de comando simplemente muestra loscontenidos del archivo stat dentro de cada directoriode /proc/.

Para conocer el contenido de los archivos de /proc, lea el anexo que se adjunta a ladocumentacin.

Otra de las tareas importantes es monitorear elespacio libre que queda en el disco. Si el disco sellena, los datos no se corrompern pero el servidorentrar en el estado PANIC y caer, por lo que esmuy til tener en cuenta o monitorear constantementeestos valores, en especial si utilizamos PITR oparticiones separadas para los archivos de la WAL.

El comando df h nos mostrar todas lasparticiones montadas y el espacio que se estutilizando de cada una de ellas. Para saber el tamaoactual del directorio que contiene los archivos de laWAL podemos utilizar du h /ruta/a/la/WAL.

Monitoreando en sistemas Windows

La monitorizacin en sistemas Windows sepuede hacer desde el Administrador de Tareas.

Existen otras herramientas privativas y librespara la medicin estadstica de los recursos.

Desde la lnea de comando podemos utilizarnetstat, tasklist (similar al psde unix-compatibles).

Utilizando herramientas propias dePgFoundry y nativas del paqueteoficial

Como suele ser recomendable, las herramientasespecficas de un determinado aplicativo suelen serms explcitas que las estndares.

Sin utilizar herramientas externas a laempaquetacin oficial (dentro de la cual incluiremos

PgAdmin III), se puede monitorear la base a travs delogs y consultas intensivas al catalogo. De ah, que esnecesario tener establecida la variable de recoleccinde estadsticas activada (track_activities).

Como otra recomendacin, se encuentra elevarel valor por defecto de la variable del motordefault_statistics_target. Un valor recomendado paraun servidor en produccin es superior a 100. Luego deeso, se puede establecer un nmero mayor o menorde acuerdo a la importancia de la tabla.


6/10

Consorcio SIU

SIU PGINA 6 DE 10

En cuanto a los logs, por lo general, en unsistema en produccin variarn de acuerdo a unasituacin en especial. El nico recaudo a tener es quea medida que el nivel de mensajes que se almacenanson ms detallados y a valores ms bajos (DEBUG[1-5]) ms sobrecarga a nivel de procesamiento y mayorespacio de almacenamiento se ver afectado. Porello, siempre se recomienda que el almacenamientode logs se haga separado del almacenamiento de la

base y los servidores de aplicacin. Esto ademspermite que el sistema de ficheros a utilizar sea elms sencillo (caso ext2-3, FAT).

La herramienta ms popular para el anlisis delogs en Postgres es PgFouine. Ms detalle en laseccin 'Archivado de Logs'.

Iopp es una herramienta desarrollada enpostgres que sirve para medir las estadsticas de i/opor proceso(http://git.postgresql.org/gitweb?p=iopp.git;a=blob_plain;f=iopp.c;hb=HEAD). Requiere ser compilada congcc, las indicaciones se hallan en el mismo rbol del

git. Asimismo, se requiere tener compilado el kernelde linux con el soporte para el archivo /proc//io.Nuevas versiones de kernel, soportan esta opcin demanera automtica.

Otra herramienta sencilla de instalar es pgstat.Desarrollada en python, puede ser descargada delPgFoundry 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 encaso de estar interesados (ya que al momento deescribir este documento, los cambios no fueronaprobados an por el autor).

La herramienta grfica ms estable para elmonitoreo es PgAdmin. Para acceder a esta opcindebemos ir al men Tools->Server Status. Ahpodremos ver la actividad de las conexiones, losbloqueos y las transacciones. Desde all mismopodremos seleccionar backends y cancelar susconsultas o terminarlos. Se puede establecer inclusiveel intervalo en segundos.

Ms all de las herramientas disponibles para lamonitorizacin en caliente de la base de datos, otromtodo de monitoreo es utilizando el catalogo.

Las tablas-vistas que nos proveen informacin deescritura y lectura de bloques son:

pg_stat_* pg_statio*

Las consultas sobre el catlogo se realizan atravs de SQL, y slo debemos considerar queexisten tipos de datos especficos para la relacinentre las mismas (OID).

Asimismo poseemos funciones especiales parala administracin de los backends, desde al base dedatos, permitiendo as, una administracin ms cabalsimplemente desde cualquier cliente.

Seguidamente veremos algunas de las posiblesconsultas tiles al catalogo

Contabilizar conexiones:SELECT count(*) FROM pg_Stat_activity;

Verificar hace cuanto se esta ejecutando laltima 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_rollbackFROM pg_Stat_database;


7/10

Consorcio SIU


SIU PGINA 7 DE 10

Sumarizacin de consultas DML:

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_locksGROUP BY mode ORDER BY mode;

Sumarizacin de I/O en bloques (bloques son de8k), si desea saber en cantidad de Kb, multiplique por8:

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;

Tamao de las bases:

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

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 de8k):

SELECT relfilenode, relpagesFROM pg_classWHERE relname = 'tabla';

Uso del disco para Toast:

SELECT relname, relpagesFROM pg_class ,

(SELECT reltoastrelidFROM pg_class

WHERE relname = 'tabla') ssWHERE oid = ss.reltoastrelidOR oid = (SELECT reltoastidxid

FROM pg_classWHERE oid = reltoastrelid)

ORDER BY relname;

Para indices:

SELECT c2.relname, c2.relpagesFROM pg_class c, pg_class c2, pg_index iWHERE c.relname = 'customer'

AND c.oid = i.indrelidAND c2.oid = i.indexrelid

ORDER BY c2.relname;

Encontrar las tablas e ndices ms grandes(tambin se puede multiplicar x 8):

SELECT relname, relpagesFROM pg_classORDER 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_tablesWHERE schemaname !~ '^pg.*'


8/10

Consorcio SIU

SIU PGINA 8 DE 10

GROUP BY schemaname;

La siguiente consulta obtiene los datosnecesarios para calcular los accesos a disco, tambinpodremos obtener una sumarizacin de las tuplasvivas y muertas de toda la base:

SELECTmax(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 liveFROM(SELECT c.relname as nombreFROM pg_catalog.pg_class c

JOIN pg_catalog.pg_roles rON r.oid = c.relownerLEFT JOIN pg_catalog.pg_namespace n

ON n.oid = c.relnamespaceWHERE c.relkind = 'r'

AND n.nspname 'pg_catalog'AND n.nspname !~ '^pg_toast'AND pg_catalog.pg_table_is_visible(c.oid)

) xx JOIN pg_stat_all_tables xpON xx.nombre = xp.relname

) k,(SELECT count(*) as locks from pg_locks) c,(SELECT count(*) as sess

FROM pg_stat_activityWHERE current_query !~ '.**') d

WHERE datname = '';

La vista pg_statio_user_tables contiene lainformacin por relacin, por lo que si queremos

visualizarla deberemos filtrar a travs del camporelname o schemaname. Anteriormente mostramosalgunos ejemplos con esta vista.

La vista pg_stats, contiene las estadsticas porcolumna, por lo que filtraremos por tabla.

Una consulta como la siguiente:

SELECT tablename, attname, avg_width,


9/10

Consorcio SIU


SIU PGINA 9 DE 10

n_distinct, most_common_vals,most_common_freqs,histogram_bounds, correlation

FROM pg_StatsWHERE tablename !~ '^(pg|sql)';

Arroja:

Esta vista contiene los datos de cada columna, yes importante ya que nos indicar la frecuencia dedeterminados valores en las columnas, pudiendoinferir directamente en el plan de ejecucin. El casoms comn es cuando un valor determinado tiene unafrecuencia superior a 0.3, en cuyo caso el planeadorpreferir accesos por Seq_scan debido a la repeticinde datos.

Esta vista utiliza los valores de la tablapg_statistic y es mucho ms accesible que esta ultima

en trminos de consultas.

La vista pg_stat_user_tables posee la siguienteestructura:

Esta vista nos puede mostrar el estado de cadarelacin, incluidos sus ltimos mantenimientos, tuplas

actualizadas, estimacin de tuplas muertas y vivas,etc.

Tambin poseemos las vistas para los ndices,que nos pueden indicar cuales son los ndices msutilizados o, lo que es ms til, los menos utilizados(pg_stat_user_indexes, pg_statio_user_indexes).

Existen una serie de variables que mejoran larecoleccin de estadsticas (adems obviamente derealizar usualmente ANALYZE a la base).

Hay una serie de variables que influyen en larecoleccin de estadsticas. track_activities(recoleccin de estadsticas por sesin) , track_counts(recoleccin de estadsticas por base) yupdate_process_title (muy til si realizamos muchomonitoreo 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 odesarrollo, queramos desactivarlas para evitarrecoleccin de estadsticas en mquinas que correnvarias aplicaciones y que no tienen un rol crucial en elresultado.

Existen otras variables que pueden ser deutilidad tambin: log_parser_stats, log_planner_stats,log_executor_stats y log_statement_stats. Por defectoestn en off. La activacin de estas variables acarreanms necesidad de procesamiento del recolector, porlo que afectan directamente al rendimiento delservidor. Si log_statement_stats est en on, las otrasdeben estar en off, debido a que esta contiene lasotras. El resto son configuraciones por mdulo.

Esta opcin genera bastante overhead, as quees recomendable activarla cuando estamos enproceso 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 serecomienda un valor de 100 en produccin.


10/10

Consorcio SIU

SIU PGINA 10 DE 10

Archivado de Logs

Los archivos de logs suelen ser molestos porqueconsumen ms I/O a medida que necesitamos msnivel de informacin.

Sin embargo, tenerlos bajo control esindispensable ya que son los nicos testigos de unerror o una situacin a la que posiblemente nopodamos reproducir fcilmente en un ambienteaislado.

Si vistamos el postgresql.conf observaremos una

serie de variables especiales para esta tarea:log_destination: este valor indica a que salida

van dirigidos los mensajes.

logging_collector: necesario habilitarlo siqueremos capturar los mensajes

log_directory: directorio en el cualalmacenaremos los logs.

log_filename: nombre del archivo de log. Estepodr utilizar un formato compatible con POSIX(%Y=ao, %m= mes, %d=da , etc.)

log_truncate_on_rotation: esto borrar elcontenido de un log cuando rota. No es recomendablepara ambientes de produccin.

log_rotation_age y log_rotation_size: indicancada cuanto se deber realizar la rotacin de los logs.

log_min_messages: esto indica el nivel delogueo.

log_line_prefix: esta variable indica como va aestar formateada la salida del log. PgFouine requiereque establezcamos esta variable para analizar el log.

log_statement: esto indica que tipo de sentenciasirn al log (ddl, mod, all).

Tal como dijimos antes, la herramienta mspopular de revisin de logs es PgFouine. Est escritoen PHP, por lo que requiere la instalacin del paquetephp5-cli (Debian y derivados).

La desventaja que tiene PgFouine es querequiere tocar la salida de los logs, por lo que alprincipio puede parecer incomodo.

PgFouine tiene varias opciones, las quepodremos ver ejecutando 'pgfouine.php' en la linea decomando. La ejecucin bsica seria : 'pgfouine.php -file -logtype stderr'. La opcin logtypedeber corresponder a la que tenemos en elpostgresql.conf (log_destination). Previo a estodebemos preformatear la salida (log_line_prefix) a: '%t[%p]: [%l-1] 'si utilizamos stderr.

ANEXO I (link: http://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/proc.txt )

Monitoreando Servidor Postgresql

Documents

Transcript of Monitoreando Servidor Postgresql