Bitcora

Administracin de bases de datos

Rodrguez Ramirez Miguel ngel
Instalacin de PostgreSQL
Entramos a la pgina oficial de postgres y elegimos la versin que queremos
descargar.

Descargamos el archivo y lo ejecutamos.

Nos aparecer la siguiente ventana de bienvenida para comenzar la
instalacin.
Le daremos siguiente.

Elegimos el lugar donde estar el directorio, y seleccionamos siguiente.

Elegimos un
directorio donde se
almacenaran los
datos. Y le daremos
siguiente.

Nos aparecer una

ventana para
comenzar la
instalacin,
seleccionamos
siguiente.

Al trmino de la instalacin, nos dar la opcin para descargar un

complemento, en caso de no querer, deseleccionamos la opcin y le damos
terminar.

En la siguiente ruta podremos encontrar el archivo postgresql.conf

Que es el archivo de configuracin de postgres, aqu podremos tener acceso a
varias configuraciones de postgres para mejorar el performance del sistema.

El nmero de shared_buffers es el parmetro que ms afecta al rendimiento de

PostgreSQL. Este valor, de tipo entero, indica el nmero de bloques de
memoria o buffers de 8KB (8192 bytes) que postgres reservar, como zona de
trabajo, en el momento del arranque para procesar las consultas. De forma
predeterminada (en postgresql.conf), su valor es de 1000. Un nmero
claramente insuficiente para conseguir un rendimiento mnimamente
aceptable.
Estos buffers se ubican dentro de los denominados segmentos de memoria
compartida. Es importante saber que el espacio ocupado por el nmero de
buffers que pretendamos asignar, nunca podr exceder al tamao mximo que
tengan los segmentos de memoria. En caso contrario, postgres se negar a
arrancar avisando con un error que no puede reservar el espacio solicitado.
En esta parte podemos cambiar el tamao siempre y cuando no elevar ms
all del 33% de nuestra memoria

Informacin de base en la configuracin

Los seteos en PostgreSQL pueden ser manipulados por diferentes vas, pero
generalmente ud. puede preferir actualizarlos en el archivo postgresql.conf. Las
opciones de que dispone cambian de versin en versin; la lista definitiva esta
en el cdigo fuente src/backend/utils/misc/guc.c de su versin de PostgreSQL
(pero la vista pg_settings debera ser suficiente para la mayora de casos).

Los tipos de configuracin

Existen diferentes tipos de variables de configuracin, divididas en base a los
posibles valores de entrada

Boolean true, false, on, off

Integer Nmeros (2112)

Float Valores decimales (21.12)

Memory / Disk Enteros (2112) o "Unidades computacionales" (512MB,

2112GB). Evite usar nmeros enteros sin unidad; necesitar saber la
unidad subyacente para entender lo que significa.

Time "Unidades de tiempo" aka d,m,s (30s). A veces se omite la unidad;

no haga esto.

Strings Texto simple con comilla simple('pg_log')

ENUMs Cadenas de caracteres, pero de una lista especfica ('WARNING',

'ERROR')

Lists Una lista de cadenas separada por comas ('"$user",public,tsearch2)

Cuando surten efecto

Los seteos en PostgreSQL tienen diferentes niveles de flexibilidad para cuando
pueden ser cambiados, usualmente relacionados a las restricciones del cdigo
interno. La lista de estos niveles es:

Postmaster: requiere reiniciar el servidor

Sighup: requiere para el servidor, o hacer un 'kill -HUP' (usualmente -1),

pg_ctl reload o 'select pg_reload_config();'

Usuario: peude setearse en cada sesin individual, teniendo efecto en

esa misma

Interno: puesto a la hora de compilar, no puede ser cambiado,

principalmente por referencia

Backend: se pondrn antes de iniciar una sesin

Superuser: puede aplicarse mientras corre el servidor solo por

superusuarios

La mayor parte del tiempo utilizar el primero, pero el segundo puede ser til si
tiene un servidor que no quiere detener. El tercer nivel es til en situaciones
especiales. Puede saber de qu nivel es cada opcin mirando la columna
"context" de la vista pg_settings.
Notas importantes acerca de postgresql.conf

Debera poder encontrarlo en $PGDATA/postgresql.conf, mire enlaces

simblicos y mediante otros posibles trucos.

SHOW config_file le dar la ubicacin del archivo de configuracin

Las lineas con # son comentarios que no tienen efecto. Para una base de
datos nueva, esto significar que se est usando el valor por defecto,

pero en sistemas en funcionamiento no se deberan descomentar! En

versiones anteriores a 8.3, al comentar una lnea no se devuelve
al valor por omisin. Incluso en versiones posteriores, los cambios en
postgresql.conf no surten efecto sin un restart/reload; por tanto, es
posible que el sistema est corriendo algo diferente a lo configurado en
este archivo.

Si el mismo valor es declarado varias veces, el ltimo es el que importa.

Viendo la configuracin actual

Mire el archivo postgresql.conf. Esto funciona si ud. sigue buenas

prcticas, pero no es definitivo!

show all, show <setting> le mostrarn el valor actual de una variable.

Tenga cuidado con los cambios especficos de valores de sesin

select * from pg_settings le mostrar los cambios de sesin especficos

como los ha modificado localmente.

listen_addresses
Por defecto, PostgreSQL solo responde a conexiones provenientes desde
localhost. Si desea que su servidor fuera accesible por otros sistemas via red
de TCP/IP, debe cambiar el valor por defecto de listen_addresses. Lo ms usual
es configurarlo de esta manera:
listen_addresses = '*'
Luego, controlar quienes no pueden conectarse a travs del
archivo pg_hba.conf .
max_connections
max_connections aplica la cantidad mxima de conexiones de clientes. Esto es
muy importante para algunos de los parmetros siguientes (particularmente
work_mem) porque hay recursos de memoria que pueden ser ubicados por
cliente, entonces el nmero mximo de clientes puede sugerir el mximo de
memoria utilizada posible. Generalmente, postgresql en un buen hardware
puede soportar unos pocos cientos de conexiones. Si desea tener por miles,
debe considerar utilizar connection pooling software para reducir la sobrecarga
de conexin.
shared_buffers
La configuracin del parametro shared_buffers determina cuanta memoria est
dedicada a PostgreSQL para datos en cach. Por defecto es bajo porque en
algunas plataformas (como versiones viejas de solaris y SGI) teniendo valores
altos requieren acciones invasivas como recompilar el kernel. Si tiene un
sistema con 1GB o ms de RAM, un valor inicial razonable es un 1/4 de dicha
memoria. Si tiene menos deber calcular cuidadosamente este valor de
acuerdo al sistema operativo, cercano al 15% en los casos ms comunes.

Note que en Windows y versiones viejas de Postgresql (anteriores a 8.1), altos

valores de shared_buffers no son efectivos, teniendo buenos resultados
mantenindolo relativamente bajo (alrededor de 50.000, quizs menos) y
utilizando mejor el cach del sistema operativo.
Es parecido a que elevando la cantidad de memoria de su sistema operativo le
permitir establecer el valor de shared_buffers alto. Si ud. lo establece ms all
de lo soportado, obtendr un mensaje parecido a este:
IpcMemoryCreate: shmget(key=5432001, size=415776768, 03600) failed:
Invalid argument

This error usually means that PostgreSQL's request for a shared memory
segment exceeded your kernel's SHMMAX parameter. You can either
reduce the request size or reconfigure the kernel with larger SHMMAX.
To reduce the request size (currently 415776768 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 50000) and/or
its max_connections parameter (currently 12).

Cambiar este valor requerir reiniciar la base de datos. Adems, se trata de

una difcil asignacin de memoria; quedar todo fuera de la memoria virtual
cuando se inicie la base de datos.
effective_cache_size
Este debe ser establecido en un monto estimado de cuanta memoria est
disponible para memorai intermedia en el disco para el sistema operativo,
luego de entrar a una cuenta usada por el Sistema operativo, dedicado a la
memoria de postgresql y otras aplicaciones. Esta es una gua para como se
espera que est disponible la memoria en el bfer de cach de sistema
operativo, no una asignacin! Este valor es solo utilizado por el planeador de
consultas para tener en cuenta los planes que puedan o no caber en memoria.
Si es establecido demasiado bajo, los indices no se utilizaran del modo que Ud.
esperara.
Estableciendo effective_cache_size a la mitad del total de la memoria, debera
ser la opcin ms conservadora y 3/4 para una opcin ms agresiva pero que
sigue siendo razonable. Sera conveniente que elija este valor de acuerdo a las
estadsticas del sistema operativo. En sistemas Unix/linux, sume free + cached
arrojados por los comandos free o top para tener una estimacin. En Windows
vea el tamao del "System Cache" de la pestaa del Administrador de Tareas.
Cambiar este valor no requiere reiniciar el servidor (un HUP sera suficiente o
un RELOAD).

checkpoint_segments checkpoint_completion_target
PostgreSQL escribe las nuevas transacciones a la Base de Datos en un archivo
llamado segmentos del WAL que son de 16MB de tamao. Todo el tiempo el
valor de checkpoint_segments escrito, por defecto 3, ocurre un 'checkpoint' o
punto de chequeo. Estos pueden ser un recurso intensivo, y en un sistema
moderno hacer uno cada 48 MB puede ocasionar cuellos de botella.
Estableciendo este valor un poco ms alto mejorara este inconveniente. Si
est corriendo en una configuracin pequea, debera establecer esta al menos
en 10, permitiendo alcanzar los objetivos.
Para sistemas de escritura masiva, valores desde 32 (punto de chequeo cada
512MB) a 256 (cada 128GB) son vas populares. Sistemas muy grandes utilizan
muchsimo ms disco lo que la recuperacin llevara ms tiempo, por lo que
debera elegir en que rango se encuentra comfortable. Normalmente los
valores altos (>64/1GB) son utilizadas para cargas de gran aumento de
volumen. De cualquier manera que elija los segmentos, necesitar un punto de
chequeo por lo menos cada 5 minutos menos que aumente el
checkpoint_timeout (lo que no es necesario en muchos sistemas).
Comenzando con PostgreSQL 8.3, las escrituras del punto de chequeo se
extiende un poco mientras comienza a trabajar en el prximo punto. Puedes
difundir las nuevas escrituras, la reduccin de escribir encima de la media,
incrementando el parametro checkpoint_completion_target a su mximo de 0.9
(con el objetivo de terminar en el 90 % del tiempo antes del proximo
checkpoint) en vez del valor por defecto de 0.5 (terminando cuando el prximo
est en un 50%). Establecerlo a 0 dara algo similar a lo que era en las veriones
ms tempranas. La razn principal de que 0.9 no es el valor por defecto es que
se necesita un valor alto de checkpoint_segments para la difusin funcione
bien. Para mayor informacin de mejoras en el checkpoint vea Checkpoints and
the Background Writer (aprender a mejorar de fondo los parmetros de
escritura particularmente de 8.2 o menores, siendo un reto hacerlo bien).
autovacuum max_fsm_pages,max_fsm_relations
NOTA TRADUCCIN: Vaccum significa 'vaciar' literalmente hablando. El proceso
de VACUUM lo que realiza es una limpieza de tuplas muertas que han sido
marcadas como borradas o modificadas, ya que el motor de base de datos no
las borra inmediatamente de la parte fsica para no sobrecargar las
operaciones normales.
El proceso automtico de Vacuum (autovacuum) realiza una serie de
operaciones de mantenimiento en la base que ud. necesita. Como en 8.3, est
activo por defecto y debera dejarlo as. En 8.1 y 8.2 ud. debe activarlo. Tenga
en cuenta que en esas versiones antiguas, debe configurar sus variables para
uqe tenga un efecto ms rotundo; puede que no haga el trabajo suficiente por
defecto si tiene una base de datos muy grande o realice muchas
actualizaciones en los datos.

Generalmente, si ud. piensa que necesita desactivarlo si est tomando muchos

recursos, significa que este hacindolo trabajar incorrectamente. Las
respuestas a todos los problemas del vacuum es realizarlo ms seguido, no
menos, por lo que cada operacin de vacuum individual tendr menos que
mantener.
Debera entonces incrementar el valor de max_fsm_pages y max_fsm_relations
hasta donde lo necesite. El mapa de espacio libre (Free Space Map) es usado
para seguir donde se encuentran lsa tuplas muertas (rows o filas) . Solo
obtendr un efectivo desbloqueo de las consultas de VACUUM si las tuplas
muertas pueden ser listadas en el FSM. Como resultado, si no planea correr
VACUUM frecuentemente, y espera muchas actualizaciones, debera
asegurarse de que estos valores sean altos (y recuerde, estos valores son del
largo del cluster, no de base de datos). Debera ser bastante fcil establecer
max_fsm_relations lo suficientemente alto; el problema ms comn es cuando
max_fsm_pages no est establecido en un valor suficientemente alto. Una vez
uqe FSM est lleno, VACUUM estara deshabilitado para seguir y anotar las
pginas muertas. En una base de datos con mucha actividad, esto necesita
estar en un valor 1000... Entonces, recuerde que cambiando estos valores
requerir reiniciar la base de datos, por lo que se debera establecer en
mrgenes cmodos.
Si ejecuta VACUUM VERBOSE en su base de datos, le dir cuntas pginas y
relaciones estn en uso (y, superiores a la 8.3, cuales son los lmites). por
ejemplo:

INFO: free space map contains 5293 pages in 214 relations

DETAIL: A total of 8528 page slots are in use (including overhead).
8528 page slots are required to track all free space.
Current limits are: 204800 page slots, 1000 relations, using 1265 kB.
Si Ud. encuentra que sus valores son realmente bajos, ud. necesitar un
VACUUM ms intenso de su sistema, y posiblemente reindizando y reallizando
vacuum full puedan ser necesarios tambin. Si est cerca de los lmites para
las franjas de las pginas, lo comn en la prctica es establecer el doble de sus
valores actuales, y quizs con un procentaje menor de incremento una vez que
obtenga valores muy altos (en un rango de millones). Para los valores de 'max
relations', tenga en cuenta que este valor incluye a todas als bases de datos de
su cluster.
Otra situacin es tener cuidado es al autovacuum_max_freeze_age. Cuando
una base de daots se acerca a este valor, realizar vacuum a cada tabla en la
base de datos que no haya sido pasada por este proceso antes. En algunos
sistemas no resultar con mucha actividad, pero en otros que tengan muchas
tablas sin limpiar, puede ocacionar mayores ocurrencias (inclusive si el sistema

est en estado de dump/restore). El significado de todo esto, incluo en un

sitema con el valor de fsm's bien establecido, una vez que su sistema
comience el proceso de vacuum de las tablas adicionales. su viejo fsm no ser
apropiado.
logging
Existen muchas cosas que se pueden registrar que pueden o no ser
importantes para Ud. Debera investigar la documentacin para todas las
opciones, pero existen algunos trucos para empezar:

log_destination & log_directory (& log_filename): Lo que establece con

estas opciones no es tan importante como saber que pueden dar
informacin para determinar donde esta registrando el servidor. Una
mejor prctica sera intentar y hacerlo similar a travs de todos sus
servidores. En algunos casos, el init script comnezar su base de datos
utilizar el destino detallado en la linea de comandos, sobreescribiendo
lo que esta en el postgresql.conf (por lo que puede tener un
comportamiento disinto al utilizar pg_ctl en vez de el script de inicio).

log_min_error_statement: Quizs debera estar seguro que est en al

menos a nivel de error, para ver que sentencias generan error. Dejel
por defecto en las versiones ms recientes.

log_min_duration_statement: No es necesario para el uso diario, pero

puede generar registros de "consultas lentas" en su sistema.

log_line_prefix: Adhiere informacin al principio de cada linea. Una

recomendacin generica es '%t:%r:%u@%d:[%p]:
' : %t=timestamp, %u=db user name (usuario), %r=host desde donde se
conecta, %d=base de datos conectada, %p=PID de la conexin. Puede
ser que no sea obvio que el PID sea til, pero puede ayudar a solucionar
inconvenientes en el futuro, por lo que se recomienda en los registros.

log_statement: Puede elegir entre NONE(ninguna), DDL, MOD, ALL

(todas). Usar "all" puede causar problemas de performance. "ddl" puede
ser til para ayudar a descubrir cambios hechos desde afuera de sus
procesos recomendados, por otros "cowboy DBAs" por ejemplo.

default_statistics_target
El software de bases de datos recolecta estadsticas de cada una de las tables
en su base de datos para decidir como se ejecutarn las consultas sobre ellas.
Por defecto, no recolecta demasiada informacin, y si no esta obteniendo
buenos planes de ejecucin particularmente en las ms largas (o variadas)
tablas debera incrementar default_statistics_target y luego correr ANALYZE la
base de datos nuevamente (o esperar al autovacuum que lo haga por ud.).
Mucha gente cree que el valor por defecto para default_statistics_target en
hardware ms moderno debe ser llevado a 100 (de su valor de 10), ya que

hace menos probable que se ejecute un mal plan slo en el coste de la

actividad de algunos antecedentes.
work_mem maintainance_work_mem
Si hace muchas ordenaciones complejas, y tiene bastante memoria,
incrementando esta variable le permitir a PostgreSQL a realizar
ordenamientos ms distendidos en memoria, obviamente incrementando la
performance en comparacin a las basadas en disco.
Este tamao est aplicada a cada uno de los ordenamientos para cada usuario,
y consultas complejas pueden utilizar mltiples buffers de memoria dedicados
a estos. Establecerlo en 50MB y teniendo 30 usuarios ejecutando consultas y
estara utilizando 1.5GB de memoria real. Mas all, si una consulta implica
hacer ordenamientos con juntas de 8 tablas, requeriria 8 veces work_mem.
Debera considerar lo que tiene establecido en max_connections para
establecer el work_mem apropiadamente. Este es un valor donde los
almacenes de datos, donde los usuarios ejecutan consultas extensas, podran
llegar a utilizar gigas en memoria.
maintenance_work_mem es utilizada para operaciones de vacuum (limpieza).
Usar valores muy altos no ayudara mucho, y porque deberpia reservar esa
memoria cuando vacuum entre en escenario, para cuando realmente estara
con mejores propsitos. En esos casos 256mb es anecdticamente razonable
para los valores altos.
En 8.3 puede utilizar log_temp_files para verificar si los ordenamientos estn
utilizando disco en vez de caber en memoria. En versiones ms antiguas, tena
que monitorear el tamao de ellas mirando cuando espacio estaba siendo
utilizado en los archivos de $PGDATA/base/<db oid>/pgsql_tmp. Puede ver
como suceden los ordenamientos en disco en el EXPLAIN ANALYZE. Por
ejemplo, si ve una linea que reza "Sort Method: external merge Disk: 7526kB",
ud. sabra que el work_mem en al menos 8mb podra mejorar la velocidad en la
que se ejecutara la consulta (siendo ordenada en RAM en vez de realizar
escrituras en disco).
wal_sync_method wal_buffers
Luego de cada transaccin, Postgresql fuerza a comprometer para aliviar la
WAL. Esto puede hacerse en varias formas, y en algunas plataformas las otras
opciones pueden ser consideradas ms rpidas que la opcin conservadora por
defecto. open_sync es la ms comn de las otras opciones que no estn por
defecto, en las plataformas que lo soportan pero por defecto es una de los
mtodos de fsync. Puede ver Tuning PostgreSQL WAL Synchronization para ver
ms detalles de esto. Tenga en cuenta que open_sync tiene algunos errores en
algunas plataformas, y debera (como siempre) realizar varios testeos de
inserciones masivas para estar seguro de que no har inestable a su sistema.
Incrementando los wal_buffers de su pequeo valor por defecto con un par de
kilobytes, debera ayudar para sistemas con grandes inserciones. Las

estadsticas indican que incrementando a 1MB es suficiente para sistemas

grandes. Cambiar este valor requiere reiniciar la base de datos.
constraint_exclusion
Si planea utilizar particionado de tablas, necesitar establecer en 'on' este
valor. Hasta que esto genere una sobrecarga del planeador de consultas, es
recomendable que lo deje en 'off' fuera de este escenario.
max_prepared_transactions
Este valor es usado para manejar 2 phase commit (transaccin a dos fases). Si
Ud. no lo utiliza (y no sabe lo que es, ni lo utiliza), puede llevar este valor a 0.
Esto salvar un poco de memoria compartida. Para los sistemas de bases de
datos con un alto numero (minimo 100) de conexiones concurrentes, tenga
precaucion ya que este valor adems afecta el nmero disponible de lugares
para bloqueos en pg_locks, por lo que querr dejar este en el valor por defecto.
Existe una frmula para saber cuanta memoria ubica in the docs y en el valor
por defecto en postgresql.conf.
El cambio de max_prepared_transactions requiere reiniciar el servidor.
synchronous_commit
PostgreSQL solo puede utilizar la escritura intermedia segura si tiene una
bateria respaldo. Vea WAL reliability para ver una introduccin al tema . De en
serio! Lealo ahora para comprender como tiene que funcionar correctamente
su base de datos.
Puede que este limitado aproximadamente a 100 transaction commits por
segundo y por cliente en situaciones donde no tenga una escritura intermedia
durable (y posiblemente solo 500 segundos incluso con muchos clientes). Para
situaciones donde perdidas pequeas de datos son aceptables en retorno de
una gran respuesta en como muchas actualizaciones puede hacer por segundo,
considere pasar a cometer sincrnicamente. Es particularmente til en la
situacin donde no tiene una batera de escritura intermedia en su disco
controlador, porque ud. podra tener potencialmente miles de cometiciones por
segundo en vez de unas cientos.
Fue introducida en PostgreSQL 8.3. Para versiones ms tempranas de
PostgreSQL, podra encontrar gente que recomienda que
establezca fsync=of para aumentar las escrituras en sistemas con mucha
carga. Es peligroso! una prdida de energa podra resultar en una base de
datos corrupta e incapaz de reiniciar. Este sistema no introduce estos riesgos
en su base de datos, solo prdida de algunos datos.
random_page_cost
Este valor sugiere al optimizador cuanto tiempo le llevar a tus discos
encontrar una pgina aleatoria de disco, como cuanto lleva una lectura
mltiple secuencial (con un costo de 1.0). Si tiene discos rpidos, como los

comnmente encontrables con RAID de SCSI, sera apropiado dejarlo bajo, con
cual animara al optimizador utilizar rastreos de acceso aleatorios. Algunos
creen que 4.0 es muy alto para el hardware actual, sin embargo no es inusual
en los administradores estandarizar el valor entre 2.0 y 3.0. En algunos casos
este comportamiento es un vestigio de versiones tempranas de PostgreSQL
que tenan el valor random_page_cost muy alto lo que hoy representa a
entorpecer el plan de optimizacin (y establecerlo en 2.0 o mayor era
regularmente necesario). Dado que estas estimaciones de gastos que son slo
eso (estimaciones) no deberan afectar tratar con valores menores.
Pero no es aqu donde debera empezar a buscar problemas en el plan. Tenga
en cuenta que random_page_cost est muy abajo en esta lista (en el final, de
hecho). Si est teniendo planes malos, no debera ser el primero en el que
debera pensar, incluso bajar este valor puede ser efectivo. Sin embargo,
debera confirmar que est trabajando correctamente el autovacuum, que est
recolectando estadsticas asiduamente y que tiene establecidas correctamente
los parmetros de cantidad de memoria en el servidor (todas las cosas
anteriores). Una vez que haya revisado todas estas cosas importantes, y ud.
sigue teniendo malos planes solo luego de eso debera revisar si tener bajo
este valor le sigue siendo til.