PostgreSQL: Introduccin

PostgreSQL es una de las grandes maravillas del software libre, robusto, potente, altamente
funcional, distribuido en miles de formas posibles (greenplum=clusterizador masivo, postgres
Plus=imitador de Oracle,deepgreen=granjas de datawarehousing con postgreSQL, etc)
puede ser optimizado (como todo lo que es software libre) de maneras inimaginables para
cada necesidad especfica. Entonces, por qu hay gente que denigra de l?
El primer error que comete la gente, es pretender que un sistema tan necesario como la
base de datos, sea utilizado directamente luego de su instalacin; un detalle de
distribuciones Linux como Debian, es no optimizar para ningn aspecto (ya que son metadistribuciones genricas sin una orientacin especfica).
Mientras Oracle saca libros de 900 pginas de cmo optimizar al mximo hardware, sistema
de archivos, sistema operativo y la base de datos como tal, mucha gente piensa migrar a
postgreSQL ejecutando un aptitude install postgresql y dejndolo as nada ms perdido y
lejos de la realidad.
Ac, ejecutaremos una instalacin que debera ser bsica, la ms bsica, para un entorno
pequeo de datos, para que sus sistemas rindan.

Prembulo
Uno de los aspectos ms importantes es que postgreSQL no debera compartir acceso a
disco con el sistema operativo, esto es, si es posible que postgreSQL est en una particin
distinta a root (incluso un disco separado, de ser recomendable); por lo que la opcin
instalar y usar no debera ser para instalaciones en produccin de postgreSQL 9.1.
Hay que tomar en cuenta que postgreSQL (como cualquier otra base de datos) debera ser
optimizada posteriormente a su instalacin de manera correcta, una de las optimizaciones
ms necesarias (pero que casi nadie sigue) es gestionar los espacios de datos y separarlos del
tablespace pg_default (que gestiona la DB postgres, la DB de information_schema y
dems informacin, por lo general en /var/lib/postgresql/9.1/main); adems, ambos
deberan estar separados de la particin raz donde est el sistema operativo.
Las optimizaciones ac realizadas son de las ms sencillas a nombrar para postgreSQL, se
tom una mquina virtual en Xen 4.1 en una porttil y se optimiz de lo ms bsico, para
demostrar, que hasta en los cambios ms sencillos, pueden afectar el performance de
aplicaciones diseadas con postgreSQL.

Preparacin primaria

Si estamos instalando un servidor de datos, lo primero que debemos pensar es en separar el

montaje de /var del resto del sistema, de hecho, si podemos incluso separar /var/log sera
muy apropiado; tambin es bueno separar /tmp (ms 1Gb es innecesario) ya que si no
separamos /tmp, Debian GNU/Linux utilizar un tmpfs montado en RAM para gestionar /tmp
(restndonos un poco de RAM para trabajar, adems que postgreSQL no utiliza la particin
/tmp).
Un esquema bsico podra ser:

/ (raiz) (Debian GNU/Linux no ocupa ms de 5Gb en este modo)

/tmp (1Gb como mximo)
swap (Lo necesario, aunque no mayor a 2GB en sistemas con ms de 4Gb de RAM)
/var (2~4GB ya que ser un servidor en produccin)

Y de resto, un volumen lgico (LVM) que podemos modificar de tamao de acuerdo a nuestra
necesidad.
Luego de instalado el sistema, procedemos a instalar PostgreSQL.

Instalacin
La instalacin de postgreSQL 9.1 en Debian GNU/Linux es bastante sencilla:

Instalamos postgreSQL 9.1 (pero as no se debera quedar):

apt-get install postgresql-9.1

PostgreSQL por defecto, crear una carpeta de configuracin en: /etc/postgresql/9.1/main/

Y crear un espacio de datos en: /var/lib/postgresql/9.1/main/
Que no utilizaremos para nuestra base de datos, ya que crearemos un espacio propio.

Configuracin inicial
Siempre es recomendable dejar el usuario postgres (el super-usuario de PostgreSQL) como
un usuario para accesos de emergencia, ya que este usuario tiene garantizado el acceso a
todas partes(si eres root en el sistema), es recomendable que NINGUNA base de datos tenga
como owner el usuario postgres (y evitar en lo posible utilizarlo como usuario de acceso
desde sistemas, aunque esto, obviamente lo he visto ms de una vez ocurrir hasta en
sistemas web).

Creamos un super-usuario para nuestras necesidades, primero cambiamos al usuario

postgres:
su postgres

Creamos un usuario, que ser nuestro super-usuario para nuestros accesos, evitando
as el usuario postgres:

createuser -sPl jesuslara

-- ingresamos nuestra contrasea

Enter password for new role:

Enter it again:

Ejecutamos la consola SQL de postgreSQL:

psql

Garantizamos al usuario que creaste acceso irrestricto sobre el la DB postgres:

psql (9.1.3)

Type "help" for help.

postgres=# grant all on database postgres to jesuslara;

GRANT

Y salimos de la consola:

postgres=#\quit

Configuracin de postgreSQL

Accedemos al directorio

/etc/postgresql/9.1/main

cd /etc/postgresql/9.1/main

Si vamos a acceder de manera remota a nuestro postgreSQL, agregamos la siguiente lnea

al archivo pg_hba.conf:

# la forma es:

# host -> database (all: todas las db) -> usuario (all: todos los usuarios)
-> subnet (de nuestra red) -> modo de clave

host

all

jesuslara

192.168.100.0/24

md5

Habilitamos el acceso remoto en nuestro postgreSQL:

archivo /etc/postgresql/9.1/main/postgresql.conf
listen_addresses = '*'

Optimizacin del archivo postgresql.conf

Y cambiamos algunas opciones bsicas del archivo postgresql.conf:

shared_buffers = 256MB

shared_buffers: Es la memoria de trabajo compartida para todo el servidor postgreSQL,

fjese que por defecto en Debian GNU/Linux la opcin es 24MB (y el valor por defecto si
comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de
postgreSQL, es recomendable al menos el 25% de la RAM disponible (y jams > 40%).
temp_buffers = 16MB

temp_buffers: La memoria temporal utilizada por cada sesin para las tablas temporarias y
para apertura de tablas en cada sesin de cada base de datos, tome en cuenta que este valor
depender obviamente de la cantidad de datos que carga cada sesin y depender
muchsimo del sistema que se utiliza.
work_mem = 16MB

work_mem: uno de los valores ms importantes y ms despreciados, work_mem se

refiere a la memoria temporal utilizada por cada sesin, para las operaciones de
ordenamiento (ORDER BY) para las sesiones de diferenciacin (GROUP HAVING y DISTINCT)
y para la gestin de hash (uniones HASH, indices HASH, hash_aggregations), si en nuestro
sistema realizamos muchsimas consultas ordenadas, agrupadas, diferenciadas por cadenas,
etc se crearn mucho de estos buffers de manera paralela, mientras ms memoria
asignemos, menos probabilidades hay que los ordenamientos y otras operaciones se hagan
con archivos temporales en disco (ms lentos que la memoria RAM).
max_stack_depth = 8MB

max_stack_depth: define el tamao del espacio utilizado para cmputo de operaciones

complejas, su valor est asociado al lmite mximo que un usuario (en este caso, postgres)
tiene derecho a reservar un stack, el valor soportado por nuestra distribucin se determina
con ulimit -s.
shared_preload_libraries = '$libdir/plpython2.so'

shared_preload_libraries: Permite cargar una librera especfica cuando arranca el sistema,

si utilizamos muchos procedimientos almacenados en un lenguaje especfico (ej: python,
perl, tcl, java, etc), es bueno pre-cargarla para que est disponible cuando se utilice por
primera vez. Nota: esta opcin ralentiza un poco el reinicio del sistema.
bgwriter_delay = 500ms

bgwriter_delay: El background-writer es un proceso del servidor que se encarga de escribir

a disco todos los shared_buffers modificados, este proceso conlleva una carga de I/O sobre
el disco, su modificacin permite o reducir el valor para evitar en lo ms posible prdidas de
datos en equipos que pueden fallar, o su incremento permite reducir el I/O al disco duro en
sistemas perfectamente protegidos.

Modificados estos parmetros bsicos, vamos a modificar nuestro sistema operativo.

Optimizacin de Linux para postgreSQL

Una de las cosas que olvidamos optimizar (tunning) es nuestro sistema operativo
GNU/Linux, con grupo de valores en el sysctl ya podemos ayudar mucho a nuestro
postgreSQL.

Agregamos al archivo sysctl.conf

archivo: /etc/sysctl.conf
kernel.sem = 100 32000 100 128
kernel.shmall = 3279547
kernel.shmmax = 289128448
kernel.shmmni = 8192
fs.file-max = 287573
vm.dirty_bytes = 67108864
vm.dirty_background_bytes = 134217728

Nota: observe el valor de shmmax, la cantidad de memoria mxima reservada para un

shared_buffer que puede crear una aplicacin debe ser igual o mayor al valor del
shared_buffer de postgreSQL, este valor est en bytes y es ~ 275MB.
La cantidad mxima de archivos que pueden abrirse en un sistema, depender obviamente
del nivel de trabajo de la DB, durante una operacin regular, la gente puede ejecutar lsof |
wc para obtener la cantidad de archivos abiertos.

Y luego, las aplicamos:

sysctl -p

--

kernel.sem = 100 32000 100 128

kernel.shmall = 3279547
kernel.shmmax = 289128448
kernel.shmmni = 8192
fs.file-max = 287573
vm.dirty_bytes = 67108864

vm.dirty_background_bytes = 134217728

Ya, con estos sencillos cambios, podemos reiniciar el postresql:

/etc/init.d/postgresql restart
Restarting PostgreSQL 9.1 database server: main.

Y estamos listos para crear una particin y tablespace para nuestra DB.

Creacin del espacio de tablas

Creamos una particin del tamao necesario para contener al menos nuestra base de datos
(esta es una gua bsica, no hablaremos de particiones adicionales para metadatos, para
ndices y dems).
Nota: en nuestro caso, la particin es /dev/xvdb1 y mide 10GB.
El journal, para quien no lo conoce, es la razn por la cual no existe software de
desfragmentacin en Linux, todos los sistemas operativos que lo soportan (ext3, ext4, jfs,
reiserfs, xfs, zfs, etc) tienen servicios que se encargan de ordenar, desfragmentar y
gestionar tanto la data como los metadatos (informacin acerca de los archivos y carpetas en
s), pero adems, los journal cumplen otras funciones, entre ellas, recuperar desde sus logs
la data que pudiera haberse perdido luego de un fallo de energa y/o de sistema.
En sistemas de base de datos, la data es contenida en uno o ms (y diversos) tablespaces,
espacios de tablas donde la data, metadata e ndices es contenida, como es la base de datos
la encargada de gestionar la posicin de los datos en ellos, el Sistema Operativo no requiere
la presencia de un journal, o al menos, de un journal ms relajado y menos estricto.

Formateando la particin

Se formatea la particin (disco):

mkfs.ext4 -E stride=32 -m 0 -O
extents,uninit_bg,dir_index,filetype,has_journal,sparse_super /dev/xvdb1

Utilizamos ext4, porque en modo writeback tiene un mayor performance que XFS para
almacenar los tablespaces y tiene menor propensin a fallos.

Habilita el journal en modo writeback:

tune2fs -o journal_data_writeback /dev/xvdb1

Si simplemente desea eliminar el journal, ejecute:

tune2fs -O ^has_journal /dev/xvdb1

Nota: utilice esta opcin a su propio riesgo, recuerde que no tener un journal afecta de 2
modos:
La data no es colocada en orden en el disco, fragmentando el mismo
Ante un fallo de energa, el FS no podr recuperar desde el journal las ltimas actividades
para recuperar esos datos.
Se ejecuta un chequeo de archivo bsico:
e2fsck -f /dev/xvdb1

Creamos la carpeta de postgresql:

mkdir /srv/postgresql

Y luego se monta con las opciones que describiremos ms abajo:

mount -t ext4 /dev/xvdb1 /srv/postgresql -o
noatime,nouser_xattr,noacl,discard,nodelalloc,data=writeback,barrier=0,commi
t=300,nobh,i_version,inode_readahead_blks=64,errors=remount-ro

Las opciones son:

Opciones de FS Linux:
noatime
No guardar la informacin del timestamp del ltimo acceso a los archivos, esta informacin
no es necesaria ya que postgreSQL gestiona apropiadamente el acceso a los tablespaces.
nouser_xattr
Deshabilita el uso de atributos extendidos de usuario, esto es seguro en postgreSQL ya que la
carpeta donde se guardan los tablespaces no requiere ninguno de esos atributos.
noacl
No utilizar atributos extendidos ni ACLs POSIX, no son necesarias ya que solamente
postgreSQL tendr acceso a los archivos en esta particin.
Opciones especficas de ext4:

nobh
ext4 asocia buffers de datos con las pginas de datos, esos bloques de cache proveen
garanta de ordenamiento de los datos; nobh evita el uso de estos buffers de
ordenamiento de datos (slo activable con data=writeback).
data=writeback
No se preserva el ordenamiento de los datos, la data ser escrita en el sistema de archivos
solo despus que la metadata ha sido guardada en el journal. Aunque hay personas que
recomiendan desactivar el journaling del disco, esto no es recomendable pues, aunque
postgreSQL gestiona correctamente los datos, los metadatos (informacin de los archivos y
carpetas en el FS) es responsabilidad de mantenerla consistente el FS.
commit=seconds
Los datos y metadatos son escritos a disco cada n cantidad de segundos, el valor por
defecto son 5 segundos (commit=0 es igual a dejar el valor por defecto), un valor ms bajo
puede mejorar la seguridad de los datos, un valor muy alto mejora el performance pero ante
un fallo podra perderse datos.
barrier=0
Deshabilita el uso de barreras de escritura, las barreras de escritura fuerzan el uso de
ordenamiento on-disk de los commits al journal, haciendo las cach de disco seguras de usar,
pero un dao en el performance del disco.
inode_readahead_blks=n
Cantidad de inodes que el sistema de pre-lectura de ext4 lee al buffer cach, el valor por
defecto de n es 32, pero un valor de 64 es normal para optimizar las lecturas.
discard
Permite decidir que realiza con los bloques que son liberados, por lo general ext4 ejecuta
una operacin de trim (limpieza), con esta opcin, ellos simplemente son marcados como
descartados, evitando la escritura innecesaria de bloques.
i_version
Permite indicar que los inodes sern de 64-bits, solo disponible si se est en un sistema a 64
bits.

Luego de montada de esta manera, lo fijamos en el

/etc/fstab

# particion para postgresql

/dev/xvdb1 /srv/postgresql ext4 rw,noatime,errors=remountro,nouser_xattr,noacl,commit=300,barrier=0,i_version,nodelalloc,data=writeback,in
ode_readahead_blks=64,discard 0 0

Comprobamos:
mount -a

Y ya estamos listos para crear el espacio de datos para nuestra DB!.

El espacio de tablas (tablespace)

Crearemos un simple espacio de tablas en nuestro optimizado sistema de archivos ext4 para
contener nuestra base de datos:

cambiamos el propietario a la carpeta

/srv/postgresql

chown postgres.postgres /srv/postgresql

cambiamos al usuario postgres y abrimos la consola psql:

su postgres

psql

En la consola, ejecutamos el comando para crear un espacio de tablas:

postgres=# CREATE TABLESPACE db_sistema OWNER jesuslara LOCATION
'/srv/postgresql';

Y listo!, ya tenemos un espacio de tablas disponible para crear bases de datos y optimizado!

Usando el espacio de datos optimizado

Para crear una DB que no est asociada al espacio por defecto (pg_default) ejecutamos:

Crear una DB:

CREATE DATABASE sistema WITH ENCODING='UTF8' OWNER=jesuslara TEMPLATE=template0

TABLESPACE=db_sistema;

Y como vern, le pasamos el tablespace db_sistema que hemos creado anteriormente.

Alguna prueba de la eficiencia?

La configuracin siguiente no se hizo en un sistema dedicado para tal, se realiz en una
porttil, corriendo Xen 4.1 y en una VM con 1GB de RAM se instal el postgreSQL con las
opciones nombradas, sin embargo, es posible notar una mejora en el performance general de
las consultas (y eso que son solamente optimizaciones bsicas).
Para ello, creamos una DB adicional, de un sistema administrativo (migrado desde Oracle
hasta postgreSQL) que un amigo amablemente me facilit para esta prueba.
Para ello, se movieron algunas funciones de cdigo Visual Basic a cdigo PL/Python y
PL/pgSQL y se cre una consulta semi-compleja, de unas 26 lneas de extensin, que unifica
unas 6 tablas del sistema para calcular una simple pre-nmina (ivss, paro forzoso, caja de
ahorros, faov, isrl, etc); hay que notar que en la versin cliente-servidor de la aplicacin,
la nmina de 13 mil empleados dura varias minutos hasta horas con mltiples conceptos;
para nuestra versin simplificada (5 asignaciones y 3 deducciones y clculo de salario
integral); la consulta se ejecut en: 33068ms Para 13674 registros.
Pero, lo mejor ocurre si lo ejecutas por segunda vez!, ya que los buffers de trabajo
mantienen en cache las operaciones de hash_aggregate (necesarias para algunos de los
cmputos de agregado realizados), la segunda ejecucin fu: 3107 milisegundos (3 segundos)

13 mil cmputos de empleados en 3 segundos?, Nada mal para ser una porttil!