Puesta a punto

Parmetros de rendimiento
Postgresql.conf
Startup
max_connections
Default: 100
Definir el numero mximo de clientes conectados a la vez, se debe incrementar este numero en proporcin al numero de
clientes concurrentes en nuestro cluster PostgreSQL. Tener en cuenta el uso de work_mem.
Si se usa algn pool de conexiones (pgpool, pgbounder, etc) se puede mantener este valor bajo.
checkpoint_segment
Default: 3
Es un parmetro importante en una base de datos con numerosas operaciones de escritura (insert, update, delete).
Definir al menos 10 o 30 para base de datos con bastante actividad y procesos pesados o una carga grande de datos
Para sistemas de escritura masiva, valores desde 32 (punto de chequeo cada 512MB) a 256 (cada 128GB) son mas
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 confortable. Normalmente los valores altos (>64/1GB) son utilizadas para cargas de gran aumento
de volumen.
Shared_buffer
Incrementa la memoria para datos cache
Default: 32MB
Aproximadamente 1/3 o del RAM disponible (al menos 256MB), por ejemplo un servidor de 4GB de memoria, podemos
usar 1024MB como valor inicial. Valor recomendado mnimo para uso geogrfico es 500MB.
constraint_exclusion
Default: off
Ponerlo en on (examina el constrain para todas las tablas) o partition (examina el constrain solo para tablas heredadas y
subconsultas UNION ALL, recomendado para bases de datos espaciales ) para asegurar que el query planner se optimizara a
su gusto
Se usa cuando se esta usando un esquema de particin basado en herencias de tablas.

Runtime
work_mem
Memoria usada para operaciones y consultas complejas (Order BY, DISTINCT, JOINs, etc) .
Default: 1MB
Se recomienda en 128MB para base de datos espacial
Subir si se tiene grandes bds, consultas complejas, bastante memoria
Minimo Aprox de 2-4% de total de la memoria.
Para mitigar el costo de usar archivos temporales se puede usar el parametro temp_tablespace.
maintainence_wok_mem
Memoria usada por VACUUM, CREATE INDEX, ALTER TABLE, ANALYZE, ADD FOREIGN KEY, etc.
Default: 16Mb
Su valor depende del tamao de nuestras bases de datos. Ejm: en un servidor de 4GB de memoria, se puede usar 256MB
como valor inicial.
Recomendado 23MB a 256MB en servidores de produccin, con bastante RAM.
Se puede ejecutar al momento de hacer el mantenimiento, ejm::
SET maintenance_work_mem TO '128MB';
VACUUM ANALYZE;
SET maintenance_work_mem TO '16MB';

effective_cache_size
Se recomienda configurar a 256MB para bases de datos espaciales
Usado por el 'query planner' del motor de la base de datos para optimizar la lectura de datos.
En un servidor dedicado se puede empezar con un 50% de nuestra memoria. Como mximo es 2/3 (66%) del total. Ejem:
en un servidor con 4GB de memoria, se puede usar 2048MB como valor inicial.
Un valor alto favorece el uso de indices, un valor bajo , las lecturas secuenciales.
vacuum_cost_delay
Determina el tiempo que vacuum dormir luego de haber trabajado un cierto periodo. Esto puede evitar que un VACUUM
consuma demasiados recursos procesando una tabla muy grande y/o con alta concurrencia
random_page_cost
Determina la forma en que el planeador considera los accesos no secuenciales a disco. Un valor bajo favorecer el uso de
indices; un valor alto, las lecturas secuenciales.
Es prudente reducir un poco este valor, pero se debe recordar que el uso de indices tiene un costo y nunca sera mas rpido
que el acceso secuencial (seq_page_cost), se recomienda 2.0
fsync, synchronous_commit
Determina si todas las paginas del WAL deben grabarse a disco antes de que se considere terminada una transaccin
commit_delay, commit_siblings
Se usa para tratar de ejecutar COMMIT simultneamente en varias transacciones
Si existenten otros backends activos cuando una transaccin hace COMMIT, el servidor espera commit_delay segundos con
la esperanza que alguna otra de las transacciones termine (hasta commit_siblings)
checkpoints
Puede suceder en 2 circunstancias
Se han llenado todos los segmentos del WAL (checkpoint_segment)
Ha transcurrido checkpoint_timeout segundos desde el ultimo checkpoint.
checkpoint_competion_target fue concebido para distribuir uniformemente la ejecucin del checpoint actual durante el
periodo de espera siguiente
wal_buffers
Cantidad de memoria usada por write-ahead log (WAL)
Default = 64KB
Se recomienda al menos 1MB
random_page_cost
Default 4.0
Recomendado 2.0
seq_page_cost
Default 1.0
Recomendado 1.0
Control
pg_hba.conf
Se utiliza para definir como, donde y desde que sitio un usuario puede utilizar nuestro cluster PostgreSQL.
Formato:
[Tipo de conexin] [database] [usuario] [IP] [Tipo de autentificacion][opciones]
Tipo de conexin
Local. Conexiones por socket, es mas rpidas, solo si la aplicacin esta en el mismo servidor
Host. Lo normal, conexiones vendrn por la red, pueden o no tener soporte SSL
Hostssl. Solo conexin SSL

Hostnossl. Solo sin SSL

Database
Bases de datos a las que se pueden conectar
ALL es para todas las bases de datos, en caso contrario se debe especificar una.
Se puede usar sameuser, samegroup, samerol para indicar que la base de datos a la que se conecto es la misma que
mi nombre de usuario, grupo o rol.
Se puede poner una lista se bases de datos separadas por comas
Usuario
Usuarios que se pueden conectar
Se puede usar ALL o especificar el nombre de un usuario, si se pone + por detrs, es el nombre de un grupo.
Se puede poner una lista de usuarios separados por comas
IP
Sirve para indicar las direcciones autorizadas para conectarse (solo en caso TCP/IP). Se pueden especificar una IP
directamente o por rangos
192.168.1.10/32
Solo la IP indicada
192.168.1.0/24
Todas las IPs que son 192.168.1.X
192.158.0.0/16
Todas las IPs que son 192.168.X.X
192.0.0.0/8
Todas las IPs que son 192.X.X.X
0.0.0.0/0
Todos
Tipo de autentificacion
Trust.Permite que se pueda ingresar a la base de datos sin claves
Reject.Cierra el acceso a las bases de datos, usuarios e IPs indicadas
Password.Requiere se indique la clave del usuario
Ident.El usuario debe ser del mismo sistema operativo y ademas ser un usuario de la base de datos. Usada en
conexions locales
Ldap.Autentificaciones contra un servicio OpenLdap
Md5, gss,sspi, krb5, radius, cert, pam. Modos de encriptamiento de la acceso (md5 es el mas usado)
Ejem:
1 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el computador con IP 10.0.0.100, y mtodo
de autentificacion md5:
host test001 test 10.0.0.100 255.255.255.255 md5
host test001 test 10.0.0.100/32 md5
2 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los computadores de la red 10.0.0.0,
con mascara de red 255.255.255.0 (254 computadores en total) y mtodo de autentificacion md5:
host test001 test 10.0.0.0 255.255.255.0 md5
host test001 test 10.0.0.0/24 md5
3 .- Acceso por tcp/ip (red), encriptado, a todas las bases de datos de nuestro cluster, como usuario test desde el computador
con IP 10.0.0.100, y el computador 10.1.1.100 y metodo de autentificacion md5 (necesitamos dos entradas en nuestro
fichero pg_hba.conf:
hostssl all test 10.0.0.100 255.255.255.255 md5
hostssl all test 10.1.1.100 255.255.255.255 md5
4.- Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos los computadores de la red
10.0.0.0/24 y dar acceso al resto del mundo con el mtodo md5:
host
all test 10.0.0.0/24 reject
host
all all 0.0.0.0/0 md5