Dba PostgreSQL desde básico a avanzado parte2

EQ Soft Consultoría y Soporte E.I.R.L.
Http://www.eqsoft.net
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
DBA desde Básico a Avanzado
Clínica Santa Isabel - 2011
1/93
Curso de PostgreSQL DBACurso de PostgreSQL DBA
Desde Básico a AvanzadoDesde Básico a Avanzado
20112011
Parte 2Parte 2
Ernesto Quiñones AzcárateErnesto Quiñones Azcárate
ernesto@eqsoft.neternesto@eqsoft.net

●1: Instalación, Configuración y Logs bajo Gnu/Linux
●2: Software administración y SQL para DBAs
●3: Objetos de la DB, Herencias y Tablas particionadas
●4: Schemas y Tablespaces, Roles y Accesos
●5: Backup/Restore/Vacuum, Migraciones, Indices
●6: DBLinks, DbiLinks y Paquetes del Contrib
●7: Análisis de Hardware para soluciones avanzadas,
Monitoreo sobre Gnu/Linux.
●8: Configuración Avanzada y Problemas Comunes
●9: Replicación Asíncrona con PostgreSQL 9.0
●10: Pool de Conexiones con PgPool
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
2/93

1. DBLinks
PostgreSQL no permite acceder de manera transparente entre la data de un servidor y
otro, incluido entre propios servidores PostgreSQL para ello se requiere crear una
conexión entre ambos servidores.
Tome en cuenta uan cosa, acceder a otra db desde la cual se esta trabajando y operar
sobre ella requerirá que PostgreSQL jale toda la data de las tablas que involucren la
operación, luego el dbms filtrará la necesaria en la db actual pero solo después de
haber jalado todo.
DbLink no viene por defecto, es necesario instalar el paquete “contrib” de la versión
que estemos usando
[root@host] yum install postgresqlcontrib
Ahora debemos entrar a la base de datos que se conectará con las demás bases de datos
y ejecutar este script:
prueba5=# i /usr/share/pgsql/contrib/dblink.sql
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
3/93

1. DBLinks
a) CREATE FOREIGN DATA WRAPPER
Creamos una fuente de datos externa, esto es parecido a un canal de comunicación, solo
el super usuario “postgres” debe realizar esta acción.
Prueba5=# CREATE FOREIGN DATA WRAPPER dw_prueba VALIDATOR postgresql_fdw_validator;
VALIDATOR postgresql_fdw_validator esta predeterminado para chequear la consistencia
de la conexión, si no se especifica esto no se validará la misma.
b) CREATE SERVER
Con está sentencia creamos el servidor al cual nos vamos a conectar
prueba5=# CREATE SERVER srv_prueba FOREIGN DATA WRAPPER dw_prueba OPTIONS (hostaddr '127.0.0.1',
dbname 'drupal7',port '5432');
c) CREATE USER MAPPING
Creamos un usuario de conexión a la db foranea.
prueba5=# CREATE USER MAPPING FOR dbadmin SERVER srv_prueba OPTIONS (user 'usuario_foraneo',
password 'password_foraneo');
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
4/93

1. DBLinks
dbadmin          < es el usuario/rol al cual le vamos a dar acceso al servidor, ya debe existir
                     en el servidor.
usuario_foraneo  < es el usuario que tiene acceso a la db foránea, debe estar creado en la db
                     foranea y configurado para permitir el acceso desde la IP del servidor que
                     desea conectarse.
password_foraneo < clave
d) SELECT dblink_connect
Una vez configurada la conexión salimos del usuario “postgres” y utilizamos el usuario
que hemos definod va a hacer uso de la conexión, el primer paso entonces será activar
la conexión dblink de esta forma:
prueba5=# SELECT dblink_connect('dw_prueba','srv_prueba');
e)Probando la conexión:
prueba5=# select dblink_exec('dw_prueba','create table tbl_pruebas(id serial,nombre varchar(100))');
dblink_exec

CREATE TABLE
prueba5=# select dblink_exec('dw_prueba','insert into tbl_pruebas (nombre) values (''ernesto'')');
dblink_exec

INSERT 0 1
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
5/93

1. DBLinks
prueba5=# select dblink_exec('dw_prueba','insert into tbl_pruebas (nombre) values (''juan'')');
dblink_exec

INSERT 0 1
ernesto@depeche:~$ psql drupal7 U dbadmin
psql (8.4.4)

drupal7=# select * from tbl_pruebas;

id | nombre
+
  1 | ernesto
  2 | juan
(2 filas)
f)Trayendo Data:
prueba5=# select * from dblink('mi_conexion','select * from tbl_pruebas') as (f_id integer, f_nomber
varchar(100));
f_id | f_nomber
+
    1 | ernesto
    2 | juan
(2 filas)
Para conocer más sobre las funciones de dblink
http://www.postgresql.org/docs/9/static/dblink.html
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
6/93

2. DBiLinks
Así como necesitamos/podemos establecer conexiones entre diversos servidores
PostgreSQL podemos establecer conexiones con servidores NO PostgreSQL, servidores como
MySQL, Oracle, Ms SQL Server y en general casí cualquier servidores de bases de datos
que tenga un cliente de conexión para el lenguaje de programación Perl (en CentOS solo
tenemos MySQL y SQLite).
a) Instalar los paquetes de software necesarios:
   [root@host] yum install postgresqlplperl                < soporte de lenguaje Perl para
                                                                Postgresql.
   [root@host] yum install libdbidbdmysql perlDBDMySQL  < liberias de Perl para conectarse
                                                                a la base de datos deseada.
   [root@host] yum install perlYAML                        < metalenguaje de Perl para bases de
                                                                datos.
b) Descargar el paquete del DbiLink, desde el url:
   http://pgfoundry.org/projects/dbilink/
c) Configurar el soporte del lenguaje Perl en la base de datos PostgreSQL desde la
   Que deseamos establecer la conexión a la base de datos remota (en este caso MySQL).
   [root@host] createlang plperlu pruebas U dbadmin        < “plperlu” es el lenguaje Perol para
                                                                PostgreSQL y “pruebas” es la base
                                                                de datos donde se instalará el
                                                                lenguaje.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
7/93

2. DBiLinks
d) Desempaquetamos el paquete de DbiLink que bajamos de PgFoundry en un directorio
   desde el que pueda accederse para una vez logeado como el usuario que llevará a
   cabo la conexión importar el script que añade el soporte de DbiLink a nuestra
   base de datos.
   [root@host] cd dbilink2.0.0/
   [root@host] psql f dbi_link.sql pruebas U dbadmin
   Este paso nos creará todo un entorno especial dentro de la base de datos “pruebas”
   para activar conecciones a servidores NO PostgreSQL remotos, la información
   recidirá en un schema especial llamado “dbi_link”.
e) Dentro de la base de datis “pruebas” configuramos un ingreso automático a las
   funciones de Dbi_Link por facilidad para la administración.
    pruebas=# UPDATE pg_catalog.pg_settings
    pruebas#   SET setting = CASE WHEN 'dbi_link' = ANY(string_to_array(setting, ','))
    Pruebas#                   THEN setting
    pruebas#                   ELSE 'dbi_link,' || setting
    pruebas#                 END
    pruebas# WHERE name = 'search_path';
           set_config

     dbi_link,"$user",public
    (1 row)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
8/93

2. DBiLinks
f) Configuramos la conexión a la base de datos remota (en este caso en MySQL).
SELECT make_accessor_functions(
'dbi:mysql:database=mydb;host=localhost',       < “mydb” debe ser el nombre de la db a conectarse
'usuario_coneccion',                            < usario autorizado en la db a conectarse
'password_coneccion',                           < password
'
AutoCommit: 1                                   < Si esto es 0 entonces debemos hacer commit a
RaiseError: 1                                       nuestras transacciones
',
NULL,
NULL,
NULL,
'mydb'                                          < nombre del esquema en PostgreSQL desde al que
);                                                  accederemos a la data en el servidor foraneo.
OJO no intente escribir todo el query en una sola linea, por algún motivo que no
comprendo el servicio requiere que dejes los saltos de linea que se pueden ver aqui,
las cadenas de conexión y parámetros podrían variar si la base de datos a la que nos
queremos conectar es otra como por ejemplo Oracle.
Luego de ejecutarlo se creara un nuevo esquema con el nombre "mydb", osea el mismo
nombre de la db a la que me quiero conectar.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
9/93

2. DBiLinks
Probamos la conexión.
pruebas=# select * from db_en_mysql.tablita;
NOTICE:  SELECT dbi_link.cache_connection( 1 ) at line 12.
campo

1
2
3
(3 rows)
Restricciones:
a. No podemos hacer create, drop ó alter.
b. Cambios en la estructura de la base de datos remota no se ven reflejados
   automáticamente en la base de datos PostgreSQL, para ello es necesario actualizar
   la información del Schema.
    pruebas=# select dbi_link.refresh_schema(1)       < “1” es el número de la conexión.
    pruebas=#  from dbi_link.dbi_connection
    pruebas=#  where local_schema = 'db_en_mysql';
Para saber el número de una conexión:
    pruebas=# select data_source_id, data_source from dbi_connection;
     data_source_id |                  data_source
    +
                  1 | dbi:mysql:database=db_en_mysql;host=localhost
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
10/93

3. Paquetes del Contrib
El contrib es un conjunto de aplicaciones adicionales que se ejecutan sobre PostgreSQL
y añaden nueva funcionalidad, estos no son necesariamente programas independientes, en
su mayoría son scripts en diferentes lenguajes “PL”, especialmente “pl/pgSQL”.
El paquete Contrib que acompaña una distribución Gnu/Linux podría variar en cantidad
de aplicativos del que existe en otra distribución.
    [root@ernesto ~]# rpm qla postgresqlcontrib
    ....
    ....
    /usr/share/pgsql/contrib/_int.sql
    /usr/share/pgsql/contrib/adminpack.sql
    /usr/share/pgsql/contrib/autoinc.sql
    /usr/share/pgsql/contrib/btree_gin.sql
    /usr/share/pgsql/contrib/btree_gist.sql
    /usr/share/pgsql/contrib/chkpass.sql
    /usr/share/pgsql/contrib/citext.sql
    /usr/share/pgsql/contrib/cube.sql
    /usr/share/pgsql/contrib/dblink.sql
    /usr/share/pgsql/contrib/dict_int.sql
    /usr/share/pgsql/contrib/dict_xsyn.sql
    /usr/share/pgsql/contrib/earthdistance.sql
    ....
    ....
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
11/93

3. Paquetes del Contrib
Para instalar uno de los paquetes del Contrib ejecutamos el script deseado:
pruebas=# i /usr/share/pgsql/contrib/cube.sql
SET
Una lista completa de los contribs de mayor uso se puede encontrar aquí:
http://wiki.postgresql.org/wiki/Extensions
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
12/93

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
13/93
●7: Análisis de Hardware para soluciones avanzadas, Monitoreo sobre Gnu/Linux.
1. Análisis de Hardware para soluciones avanzadas
El Hardware en ambientes de gran demanda o gran tamaño requiere unas
consideraciones especiales, dado a que PostgreSQL contiene poca complejidad
de afinamiento y se integra muy estrechamente con el sistema operativo el
rendimiento va a depender más de esté último y del hardware en el que esta
montado que de algún “tuneo” en especial.
Los elementos que uno debe verificar siempre en su infraestructura actual o
en la que piensa adquirir van siempre por analizar estos componentes:
a. CPU
b. RAM
c. Discos Duros
d. Sistema de Archivos

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
14/93
1. Análisis de Hardware - CPU
PostgreSQL no es un software multihilos, pero si es un software que
utiliza 1 Procesador por conexión ó 1 core por conexión, esto permite que
el máximo de cores de nuestro servidor sea utilizado eficientemente en
nuestra base de datos.
Actualmente todas las configuraciones de servidores vienen de serie con
procesadores de 2 cores hasta 8 y pueden soportar desde 1 hasta muchos
cores (normalmente hasta 2 ó 4).
Es importante determinar que tipo de procesador necesito para obtener el
mejor rendimiento, en la mayoría de los casos el poder de procesamiento de
los cores de nuestro servidor es demasiado alto para lo que realmente
necesitamos, en una base de datos transaccional pura los querys hacen un
uso bajo de procesador (pero si más de disco) por lo cual un “core” de
mucha potencia estaría desperdiciado, pero en entorno de querys de gran
movimiento de datos o complejidad estos “cores” si serían una necesidad
imperiosa.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
15/93
¿AMD ó INTEL?
Eso dependerá de lo mencionado en la primera parte:
AMD menor precio que INTEL, más cores por el mismo precio, menor potencia y
por ello menor rendimiento en querys pesados, mayor soporte de
concurrencia.
INTEL mayor precio, menos cores por el mismo precio, mayor potencia y por
ello mejor rendimiento en querys pesados, pero un desperdicio en ambientes
de querys sencillos, menor soporte de concurrencia.
¿Otros?, no tiene sentido.
Para ver la velocidad de un procesador y sus cores:
monstrito@monstritodesktop:~/curso_pgsql$ cat /proc/cpuinfo

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
16/93
processor        : 0
vendor_id        : AuthenticAMD
cpu family   : 16
model   : 10
model name   : AMD Phenom(tm) II X6 1090T Processor
cpu MHz   : 800.000
cache size   : 512 KB
siblings        : 6
cpu cores        : 6
bogomips        : 6400.30
TLB size        : 1024 4K pages
clflush size   : 64
cache_alignment  : 64
address sizes   : 48 bits physical, 48 bits virtual
power management : ts ttp tm stc 100mhzsteps hwpstate [9]
Otra forma de medir performance es verificar el tiempo tomado en ejecutar una operación directa en
el CPU desde PostgreSQL.
prueba2=# timing
prueba2=# select sum(generate_series) from generate_series(1,10000000);
     sum

50000005000000
(1 row)
Time: 2407.629 ms

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
17/93
1. Análisis de Hardware - RAM
¿Más RAM es mejor? Depende
Si tenemos poca data y poca RAM pero buenos procesadores el efecto de bajo
rendimiento no se notará demasiado, el tiempo de respuesta de un procesador
sera inversamente proporcional a la cantidad de RAM que tengamos.
Si tenemos tablas con mucha data pero que no se consulta no será problema
tener poca RAM, pero si se consulta demasiado entonces mientras más RAM
tengamos será mucho mejor.
Para detectar problemas en la RAM podemos usar diferente software como:
* http://pyropus.ca/software/memtester/
  [root@host] yum install memtester
  [root@host] memtestar [bloques de memoria a testear]K|M|G < unidad del bloque
* Http://www.memtest.org
  Se puede instalar ejecutable ó descargar el cd booteable
  [root@host] yum install memtes86+   < reiniciar la máquina

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
18/93
1. Análisis de Hardware – Discos Duros
Básicamente tenemos 2 opciones en el mercado, SAS (Serial Attached SCSI) y
SATA (Serial ATA), el criterio para seleccionar una u otra son muy
parecidos al tema de los procesadores.
SAS mayor velocidad de rotación (10k a 15K RPM), costo elevado por GB de
almacenamiento (existen modelos de SATA 3Gbit/s que son posible de añadir
en un bus SAS).
SATA menor velocidad (7.2K RPM, algunos llegan a 10K RPM) , costo bajo por
GB de almacenamiento y unidades de almacenamiento más grandes que en SAS.
¿Porque Serial SCSI y no Parallel SCSI?
* Serial soporta hasta 65,535 unidades, Parallel solo 8 ó 16 como máximo.
* La transferencia es mayor en SAS (3 á 6 Gbit/s) que en Parallel.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
19/93
1. Análisis de Hardware – Discos Duros - RAIDs
RAID (Redundant Array of Inexpensive Disk) usado para obtener mejoras en
cuanto rendimiento, capacidad de almacenamiento y redundancia en la data.
El soporte de RAID por hardware es siempre el más adecuado.
* RAID 0: 2 ó más discos que unidos funcionan como una solo sumando sus
  capacidades de almacenamiento, el problema es que si uno falla se pierden
  todos los datos.
* RAID 1: 2 discos en espejo conteniendo la misma data, mejora el
  rendimiento al poder acceder el sistema a los datos desde cualquiera de
  los 2 y permite mantener el sistema aunque uno de ellos falle, los discos
  deben ser idénticos ya que solo se tendrá la capacidad de almacenamiento
  de uno de ellos.
* RAID 1+0: 4 discos o más discos (en cantidades pares) idénticos, se
  configuran 2 grupos de Raid 0 y luego se configura una Raid 1 con los 2
  Raid 0, se recomienda para entornos de alta disponibilidad.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
20/93
1. Análisis de Hardware – Discos Duros - RAIDs
RAID (Redundant Array of Inexpensive Disk) usado para obtener mejoras en
cuanto rendimiento, capacidad de almacenamiento y redundancia en la data.
* RAID 5: 3 o más discos, se suman las capacidades del total de discos
  menos 1 y un disco se guarda para fines de paridad, si uno de ellos
  colapsa la información puede ser reconstruida gracias al disco de
  paridad, el rendimiento en escritura podría decaer notablemente.
* RAID 6: 4 o más discos, se suman las capacidades del total de discos
  menos 2 (o más incluso) de tal manera que los adicionales se usan de
  paridad como sistema de tolerancia a fallos en caso de que 2 o más discos
  colapsen.
  Una falla en un disco hará que el uso de los demás suba intensamente,
  probablemente por muchas horas.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
21/93
1. Análisis de Hardware – Discos Duros - SSDs
SSD (Solid State Drive) son memorias FLASH que ofrecen una gran
velocidad de acceso pero a un costo por Gb muy alto en comparación
a otro tipo de unidades, dado a que sus capacidades de
almacenamiento son bastante reducidas son ideales para entornos de
alta demanda de lectura de datos.
Son muy propensos a la corrupción por eso se deben buscar unidades que
cuenten con baterías de respaldo para minimizar el riesgo de perdida de
data en ellos.
Como su longevidad depende del uso de escritura que se le de no son muy
convenientes para cache.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
22/93
1. Análisis de Hardware – Discos Duros – El problema del Write-Back Cache
Toda la data siempre se trabaja entre la RAM y el Procesador antes de bajarse a disco
y liberarlos para recibir y procesar otros datos.
Como RAM y Procesador son extremadamente mucho más rápidos que los discos, el sistema
operativo almacena los datos en una espacio RAM del propio disco para luego grabarlos
realmente a los platos del disco, en situaciones extremas el disco demorará varios
minutos antes de completar la grabación.
PostgreSQL incorpora WAL como mecanismo de protección contra corrupciones a los datos
antes de grabase en los repositorios de data final, en la practica sucede esto:
/pg_xlog
WAL
Write
Cache
/base
DATA
Write
Cache
Disco
RAM
Si en este
Instante se cae el
servicio tenemos
data
corrupta
Transacción
Finalizada
PGSQL
Procesando
Responde antes de grabar
realmente al HD que ya se grabó
la data al disco.Si PostgreSQL lo ve por conveniente
graba cosas directamente a “base” sin
pasar por “pg_xlog”

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
23/93
1. Análisis de Hardware – Discos Duros – El problema del Write-Back Cache
Para evitar la posibilidad de perder datos es necesario  desactivar el Write Cache de
los discos duros.
Para ver si tenemos el Write Cache activo hacemos esto:
[root@host]# hdparm I /dev/sda | egrep "Write cache" < /dev/sda es la unidad HD
          *    Write cache                            < si está activo aparece
                                                          con “*”
[root@host]# hdparm W 0 /dev/sda                     < desactiva el write Cache
/dev/sda:
setting drive writecaching to 0 (off)
writecaching =  1 (on)                              < problema en CentOS, no se
                                                          Puede desactivar el Write
                                                          Cache
En RAIDs ó SANs los Write Cache pueden ser de 128MB hasta 512MB, en discos SATA
generalmente están entre 8MB a 32MB, soluciones alternas son poder configurar el
tamaño del Write Cache del disco ó eventualmente comprar unidades de disco que tengan
baterías para casos de perdida de energía o Cache no volátil

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
24/93
1. Análisis de Hardware – Discos Duros – Limites de commits x segundo
Según la tecnología de los discos vamos a obtener cantidad máxima de
commits que podemos hacer por segundo, estos dependerán de la velocidad de
rotación de los platos, mientras más rápida la rotación mayor será la
cantidad de commits que se podrán procesar.
En un escenario básico, donde tenemos trabajando un disco duro, con el
write cache desactivado tendremos estas tasas de operaciones máximas por
segundo:
5400 RPM == 90 commit/segundo
Para exceder estas tasas de operaciones deberíamos tener un método de
cacheo de disco seguro.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
25/93
1. Análisis de Hardware – Discos Duros – Sistema de Archivos
En la actualidad casi todo sistema de archivos moderno es del tipo
”Journaling”, es decir maneja un sistema de administración de las
escrituras en disco que pasa por varios entornos de caché antes de llegar
a grabar la data a disco (esto no es write cache).
Journaling sigue la misma idea del WAL de PostgreSQL, el uso de ambos
produce un mayor overhead en nuestro servidor.
EXT3 era el sistema de archivos más utilizado anteriormente, en la
actualidad el mundo se está moviendo a EXT4 con muchas ventajas como por
ejemplo poder manejar sistemas de archivos mayores a 16TB.
XFS es la otra alternativa viable a EXT3 si no se desea implementar EXT4,
es ligeramente más veloz que EXT3, JFS y ReiserFS ya no deben ser
considerados como opciones viables, se espera que a futuro Btrfs pueda
reemplazar a EXT4 (aún no es estable) y se considera muy adecuado para base
de datos (fue desarrollado por Oracle).

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
26/93
1. Análisis de Hardware – Discos Duros – Sistema de Archivos
En el caso de sistemas tipo UNIX para bases de datos de altos volumenes de
datos ZFS (Solaris) es la opción más adecuada debido a que utiliza
paginación de 128Kb (pero puede ser configurado para ser menor) esto puede
generar que el sistema no responda eficientemente en caso de lectura y
escritura de datos pequeños.
UFS (FreeBSD) presenta mejor rendimiento para bases de datos de poca data,
este sistema no eS Journaling lo que ocasiona una buena performance para
las escrituras, pero en caso de caidas del sistema el tiempo de
recuperación del sistema de archivos es mayor al de un sistema Journaling.

2. MONITOREO - TOP y HTOP
TOP es un comando convencional de Linux / Unix que nos permite ver los procesos que se
ejecutan en el servidor.
Los procesos ejecutados por PostgreSQL son normalmente ejecutados por los usuarios
“postgres”, “pgsql” ó “postmaster”.
ernesto@depeche:~/aaa$ ps aux | egrep postgres
postgres   961  0.0  0.1 101580  2228 ?        S    Oct08   0:06 /usr/lib/postgresql/8.4/bin/postgres D
/var/lib/postgresql/8.4/main c config_file=/etc/postgresql/8.4/main/postgresql.conf
postgres   989  0.0  0.3 101704  6208 ?        Ss   Oct08   0:11 postgres: writer process
postgres   990  0.0  0.0 101580   568 ?        Ss   Oct08   0:08 postgres: wal writer process
postgres   991  0.0  0.0 102380  1320 ?        Ss   Oct08   0:09 postgres: autovacuum launcher process
postgres   992  0.0  0.0  73704   848 ?        Ss   Oct08   0:17 postgres: stats collector process
Recuerde que PostgreSQL maneja un procesador por conexión, si tiene varios
procesadores un proceso lanzado no usará varios procesadores, solo uno, deja los otros
disponibles para otras conexiones que lanzan sus propios procesos, la ventaja del uso
de esta funcionalidad se complementa con la capacidad de administración de usuarios
concurrentes que tenga el sistema operativo que se está usando (que soporte SMP).
Nunca mate un proceso que demora mucho
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
27/93

2. MONITOREO - PG_TOP
http://ptop.projects.postgresql.org/
En CentOS 6 solo tenemos soporte de PG _TOP para PostgreSQL 9.0 en repositorios no
oficiales pero existe una manera de ejecutar este paquete para PostgreSQL 8.4.
* Descargamos el paquete de esta dirección:
  http://www.pgrpms.org/9.0/redhat/rhel6x86_64/
  pg_top903.6.23.rhel6.x86_64.rpm    < ubicar este paquete
“ Instalamos el paquete forzando que no solicite dependencias
  [root@host]# rpm ivh nodeps /ruta/pg_top903.6.23.rhel6.x86_64.rpm
  warning: /ruta/pg_top903.6.23.rhel6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 442df0f8:
  NOKEY
  Preparing...                ########################################### [100%]
     1:pg_top90               ########################################### [100%]
* Creamos la variable de entorno del sistema operativo con el password del usuario de
  conexión al PostgreSQL , OjO, posible hueco en seguridad de la base de datos.
  [root@host]# export  PGPASSWORD=dbadmin  < aqui debe ir el password del usuario que se conectará
                                               a la base de datos, generalmente es un superusuario
                                               para que tenga la suficiente cantidad de permisos a
                                               las estructuras internas del motor.
* Ejecutamos PG_TOP
  [root@host]# pg_top  U dbadmin d pruebas2 h 127.0.0.1
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
28/93

2. MONITOREO PG_TOP
ernesto@depeche:~/aaa$ pg_top help
pg_top: invalid option ''
pg_top version 3.6.2
Usage: pg_top [ITWbcinqu] [x x] [s x] [o field] [z username]
          [p PORT] [U USER] [d DBNAME] [h HOSTNAME] [number]
ernesto@depeche:~/aaa$ pg_top U dbadmin d prueba5
En una consola:
prueba5=# begin;
prueba5=# lock alumnos in exclusive mode;
En otra Consola:
prueba5=# insert into alumnos values(5,'chicho',12,'nada');
PgTop nos muestra:
ast pid: 29499;  load avg:  1.59,  1.59,  1.69;       up 1+03:48:24

3 processes: 3 sleeping
CPU states: 47.0% user,  2.6% nice,  8.8% system, 40.5% idle,  1.1% iowait
Memory: 1920M used, 81M free, 26M buffers, 659M cached
Swap: 375M used, 1532M free, 45M cached
  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
29500 postgres  20    0  102M 4232K sleep   0:00  0.02%  0.20% postgres: dbadmin prueba5 [local] idle
29215 postgres  20    0  102M 5048K sleep   0:00  0.00%  0.00% postgres: dbadmin prueba5 [local] idle in transaction
29396 postgres  20    0  102M 3628K sleep   0:00  0.00%  0.00% postgres: dbadmin prueba5 [local] INSERT waiting
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
29/93

2. MONITOREO - PG_TOP
A     < permite ver el plan de ejecución de un query, especifique el PID del proceso
C     < activa/desactiva color
c     < permite ver la linea de comandos completa
D     < cambia página de listado
h ó ? < help
E     < ver versión actualizada del plan de ejecución
e     < permite ver errores del sistema
I     < ver/no ver procesos en espera o durmiendo
K     < mata un proceso, indicar el pid
L     < permite ver los locs del proceso, especificar el pid
M     < ordena por uso de memoria
N     < ordena por número de proceso
n ó # <indica cuantos procesos se pueden ver, máximo 65
O     < cambia el orden de muestra dependiendo un parámetro especial ("cpu", "res", "size", "time",
          "seq_scan", "seq_tup_read",  "idx_scan",  "idx_tup_fetch",  "n_tup_ins","n_tup_upd", "n_tup_del")
P     < ordena por utilización del proceso
Q     < muestra el query, especificar el pid
q     < Quit
R     < Display user table statistics.
r     < ??
s     < cambia la cantidad de segundos de refresco de la pantalla
T     < ordena por tiempo de ejecución
T     < ??
U     < muestra los procesos de un usuario, ingresar el usuario
X     < muestra las estadísticas de los índices
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
30/93

2. MONITOREO - VMSTAT
En un servidor podemos determinar si nuestra base de datos esta saturada,
pero otro elemento a revisar es si todo nuestro sistema esta saturado, es
posible que la base de datos este respondiendo mal no por un problema de
sobrecarga en ella sino porque el sistema llego a su tope.
[root@host]# vmstat
procs memory swap io system cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0      0 783628  42440 609340    0    0    49    22  322  462  6  1 91  2  0
* “swap”, en la columna “so” indica la actividad de la paginación y de la
   paginación de memoria al disco, números elevados es un indicativo de que
   nos estamos quedando sisn RAM y que se está moviendo mucha información
   hacia el disco, con “si” vemos la cantidad de memoria subida del swap
   hacia la ram.
* “procs” es el estado de los procesos, en la columna “r” están los
   procesos que están esperando ser atendidos por el procesador y “b”
   Presenta los que están en ejecución.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
31/93

2. MONITOREO - VMSTAT
[root@host]# vmstat
procs memory swap io system cpu
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0      0 783628  42440 609340    0    0    49    22  322  462  6  1 91  2  0
* “memory” indica el estado de la memoria, en la columna “free” tenemos la
   memoria libre, en “swpd” es la cantidad de swap utilizada, mientras que
   “buff” y “cache” es la cantidad de memoria reservada.
* “cpu” muestra el estado del procesador en tiempo de utilización, “us” %
   de tiempo de uso por usuario, “sy” % de tiempo de uso de sistema,”id” %
   de tiempo inactivo, “wa” % de tiempo en espera, si “wa” es un número
   alto entonces estamos requiriendo de procesadores más potentes.
   “st” es el porcentaje de tiempo utilizado por máquinas virtuales.
* “io” muestra información del I/O hacia dispositivo, “si” bloques enviados
  Y “so” bloques recibidos.
* “system” son las interrupciónes por segundo.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
32/93

2. MONITOREO - IOSTAT
IOSTAT nos permite monitorizar el uso de los discos duros de nuestro
servidor.
[root@host]# iostat k
Linux 2.6.3271.el6.x86_64 (host.dominio) 05/21/2011 _x86_64_ (2 CPU)
avgcpu:  %user   %nice %system %iowait  %steal   %idle
           6.32    0.00    1.36    1.56    0.00   90.76
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               5.58        71.51        40.52     496736     281500
* %iowait es el parámetro que principalmente deberíamos controlar, un
  número alto significa que tenemos una saturación en el uso de los
  dispositivos de almacenamiento y que debemos empezar a buscar
  alternativas de almacenamiento.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
33/93

2. MONITOREO - IOTOP
Nos permite ver el consumo de uso de disco de los procesos que se ejecutan
en el sistema.
[root@host]# yum install iotop
[root@host]# iotop
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND

    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    4 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
    7 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]
    8 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/1]
    9 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [events/0]
   10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [events/1]
   11 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [cpuset]
Presionando “o” vemos los procesos que en ese instante están haciendo uso
de disco y no todos los procesos.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
34/93

1. Configuración Avanzada - Afinando Postgresql
PostgreSQL y Gnu/Linux están muy integrados, un Sistema Operativo muy bien afinado
dará como resultado un excelente rendimiento de la base de datos, sin embargo es
posible configurar ciertos atributos del motor de la base de datos para optimizarla
para diferentes escenarios.
Toda la configuración de PostgreSQL se realiza en el archivo “postgresql.conf” y
cualquier cambio para que se active requerirá que se reinicie el servicio, en algunos
casos bastará con hacer un reload.
[root@host]service postgresql restart <-- baja el servicio totalmente y lo vuelve a
iniciar.
[root@host]service postgresql reload <-- el servicio no se baja, conexiones pueden
seguir siendo aceptadas pero aparecerán
con un rendimiento lento durante el periodo
de tiempo que tome recargar el servicio,
este tiempo dependerá de la concurrencia de
usuarios cuando se haya ejecutado el Reload.
Otra forma de recargar las configuraciones modificadas en postgresql.conf es ejecutar
este comando desde dentro de la base de datos.
template1=# select pg_reload_conf();
pg_reload_conf
----------------
t
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
35/93

template1=# show block_size; <-- usamos SHOW para ver el valor de un solo parámetro
block_size
------------
8192
(1 fila)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
37/93

a)SHARED_BUFFERS
El SHARED BUFFER es en si el área de intercambio de lectura y escritura de datos desde
y hacia la base de datos.
El correr el INITDB el PostgreSQL detecta la cantidad de memoria del servidor y
calcula esta valor, el problema es que asume que no deseas dar prioridad a la base de
datos y coloca un valor muy bajo, 32mb o 24mb.
Los valores razonables deberían estar entre 25% a 40% del monto total de RAM, algunos
expertos recomiendan que el 10% es más que necesario, pero en realidad dependerá del
uso que le demos a la base de datos y que tan pesadas sean nuestras consultas,
Aumentar el valor de SHARED_BUFFER llevará generalmente a un aumento de su equivalente
en el sistema operativo
Por ejemplo en este caso deseamos subir nuestro SHARED_BUFFER a 400mb
shared_buffers = 400MB
Acto seguido debemos configurar nuestro sistema operativo antes de que este nuevo
valor pueda ser usado, sino tendremos un error del sistema, lo mejor es bajar la base
de datos cuando se modifique este parámetro.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
38/93

a)SHARED_BUFFERS - SHMMAX
Gnu/Linux por defecto levanta áreas de intercambio de datos en buffer de ram para cada
aplicación que se esté ejecutando, por defecto los valores suelen ser pequeños por lo
cual aumentar el SHARED_BUFFERS en el PostgreSQL hace que aumentemos el valor en el
Gnu/Linux, tomar en cuenta que poner valores muy altos hará que si levantamos muchos
servicios la RAM podría quedarnos corta, por lo cual no es buena idea levantar muchos
servicios en un solo servidor.
Modificar /etc/sysctl.conf
Calculamos el nuevo valor de shmmax:
400mb x 1024kb = 409600 <-- cantidad de kb a utilizar por el buffer
409600 / 8 = 51200 <-- cantidad de páginas a utilizar por el buffer
51200 x 8192b = 419430400 <-- cantidad mínima de ram en bytes que se debe configurar
debe considerarse que hay otras aplicaciones que hacen
uso de esta cantidad de ram asignada.
Abrimos el archivo “/etc/sysctl.conf” y añadimos:
kernel.shmmax = 421527552 <-- añadimos un par de megas más para asegurarnos que no
Nos faltará ram.
Es necesario luego reiniciar el sistema operativo.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
39/93

b)KERNEL SEMAPHORES
Los semáforos son objetos usados para procesar comunicaciones.
[root@host]# ipcs -l <-- para ver la configuración de los semáforos
actual del sistema.
---- Límites memoria compartida ----
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
tamaño mín. segmento (bytes) = 1
------ Límites semáforo --------
número máximo de matrices = 128
máx. semáforos por matriz = 250
máx. semáforos sistema = 32000
máx. oper. por llamada semop = 32
valor máx. semáforo = 32767
------ Mensajes: límites -------
máx. colas sistema = 7660
tamaño máx. mensaje (bytes) = 8192
tamaño máx. predeterminado cola (bytes) = 16384
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
40/93

b)KERNEL SEMAPHORES
PostgreSQL usa un total de 16+1 semáforos por cada conexión activa, 16 son
de uso real y uno de control, mientras más conexiones requeriremos en
nuestra base de datos más semáforos deberíamos tener disponibles para esto.
Para modificar los semáforos editamos el archivo /etc/sysctl.conf
número máximo de matrices = 128 <-- SEMMNI = (conexiones + procesos autovacumm) / 16
redondeado hacia arriba
máx. semáforos por matriz = 250 <-- SEMMSL = como mínimo debería ser 17
máx. semáforos sistema = 32000 <-- SEMMNS = SEMMNI * SEMMSL
máx. oper. por llamada semop = 32
valor máx. Semáforo = 32767 <-- SEMVMX no es necesario cambiarlo generalmente
Para activar los nuevos valores requerirá reiniciar el sistema operativo.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
41/93

c)CHECKPOINTS
Un CHECKPOINT es un área de almacenamiento de datos donde se almacena la
información que está lista para bajarse al repositorio de datos final, esto
se hace para asegurar que ante caídas del sistema el repositorio principal
no se corrompa.
checkpoint_segments = 3 <-- cada segmento es de 16MB, 3 segmentos significa que
tenemos 48MB de historia de procesos almacenados
para reconstruir la información en caso de
Desastres, más segmentos hará un sistema mas seguro
Pero con un overhead mayor.
checkpoint_timeout = 5min <-- tiempo máximo que el checkpoint podrá estar sin ser
Pasado al repositorio principal.
checkpoint_warning = 30s <-- lanza un mensaje al sistema indicando que se están
Sucediendo checkpoints demasiado rápido en
frecuencia de creación, es decir que se genera un
checkpoint en menos de 30s nos alertará
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
42/93

d)WORK_MEM
work_mem es el espacio de memoria que se usará para los ordenamientos de los datos
cuando se ejecutan consultas, no existe una formula exacta de cálculo dependerá de que
tanta data se mueva en las consultas que ejecutamos y cual es la concurrencia de
ejecución de las consultas, por defecto el valor es muy bajo, solo 1MB.
La regla dice, si las consultas se ejecutan con poca concurrencia entonces asignar
entre 2% a 4% de la ram disponible será ideal, pero si la concurrencia es alta
entonces debe asignarse menos memoria debido a que cada consulta consume la misma
cantidad de ram.
work_men = 163MB <-- 4% de 4gb (redondeado)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
43/93

e)WAL
WAL (Write-Ahead Log) son páginas de datos que se generan para trabajar los datos en
un área reservada antes de pasar al repositorio principal de datos, cuando un WAL
culmina su labor se le cambia el identificador y se convierte en un CHECKPOINT y de
ahí recién pasa en ciertos intervalos de tiempo al repositorio principal.
WAL_BUFFERS = 8 <-- es el valor por defecto, significa que tiene 8 * Longitud de página
disponibles (el mínimo de una página de 8k hasta 32k), debería ser
tan grande como lo necesiten nuestras transacciones más comunes.
wal_buffers = 64KB <-- podemos especificar el valor indicando una cantidad de KB pero tomar
En cuenta el peso de las páginas en KB.
wal_writer_delay = 200ms <-- lapso de tiempo en que el WAL realizará escrituras hacía disco
después de informado por el “cliente” que la transacción ha
concluido, un número muy bajo causará un incremento de
overhead en los discos.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
44/93

f)temp_buffers
Es la cantidad de memoria que tendrá asignada cada conexión al dbms para manejo de
tablas temporales, esta no se libera hasta que la sesión muera, cada sesión podría
manejar un tamaño diferente y mayor al de default (8mb) pero solo hasta antes de
generar la primera tabla temporal.
g)max_locks_per_transaction
Permite indicar cuantos objetos se pueden bloquear en una transacción, un registro no
se considera un objeto, el default es 64 solo valdría la pena subirlo si es que
tenemos transacciones que bloquean muchos más objetos únicos (tablas) que este valor,
obviamente el consumo de memoria crecerá.
h)max_connections
Determina cuantas conexiones soportará el dbms, subirlo significará un consumo de
recursos adicional en el OS (sistema operativo), y en realidad no servirá de mucho si
es que el OS no soporta esta carga de trabajo.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
45/93

i)random_page_cost
Determina en que momento se van a utilizar índices ó búsquedas
secuenciales, el valor por defecto es 4, se recomienda aumentarlo para
discos lentos y bajarlo para discos rápidos.
Considere que los índices son efectivos si la variedad de datos es alta, si
es baja entonces es probable que aunque se mueva la configuración se
ejecuten búsquedas secuenciales.
j)effective_cache_size
Setea el tamaño de cache en RAM que se usará en una consulta, el valor por defecto es
128Mb, un valor alto facilitará el uso de índices, un valor bajo hará que se prefiera
el uso de búsquedas secuenciales, se recomienda como máximo 50% del total de la RAM.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
46/93

h)statement_timeout
Configura cuanto tiempo puede demorar un query en ejecutarse, evita que se lancen
querys extremadamente pesados que demoren mucho tiempo en ejecutarse, por defecto es 0
(desactivado) pero se expresa en milisegundos, OjO configurarlo afectará todos los
querys.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
47/93

1. Configuración Avanzada - Automatizando tareas con CRON
PostgreSQL utiliza el sistema de automatización de tareas de Gnu/Linux para
automatizar tareas rutinarias como por ejemplo las de mantenimiento.
CRON es el demonio más utilizado, cualquier usuario puede eventualmente
crear una tarea automatizada, en este caso utilizaremos el usuario
“postgres” del sistema operativo para nuestras tareas que afectan
directamente a las bases de datos.
En CentOS el editor por defecto es VI pero como es algo complicado de usar
utilizaremos NANO, para ello exportamos la variable “EDITOR” de Gnu/Linux
[root@host] su – postgres
[postgres@host] export EDITOR=nano
[postgres@host] crontab -e <-- entramos al editor del cron
0-59 * * * * echo "hola" >> /var/lib/pgsql/file.txt <-- grabar la palabra “hola” y la hora
0-59 * * * * date >> /var/lib/pgsql/file.txt cada minuto en el archivo file.txt
[root@host] service cron restart <-- es necesario reiniciar el demonio del “cron” cada
Vez que se cambie una configuración
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
48/93

Los rangos de tiempo se presentan así:
* * * * * COMANDO
M H D MO DS
M = minuto
H = hora en formato de 0-23
D = día en formato de 1-31 (deben especificarse días válidos)
MO = mes en formato 1-12
DS = día de la semana en formato 0-7 donde 0 ó 7 es domingo
COMANDO = comando del sistema operativo que debe ejecutarse
1 * * * * COMANDO <-- ejecutará el comando al minuto 1 de cada hora
0-59 * * * * COMANDO <-- ejecutará el comando cada minuto
0-59/2 * * * * COMANDO <-- ejecutará el comando cada 2 minutos
5 2 * * * COMANDO <-- ejecutará el comando al minuto 5 de la hora 2 de cada día
5 2 20 * * COMANDO <-- ejecutará el comando al minuto 5 de la hora 2 de cada día
20 del mes
1 * * 1 * COMANDO <-- ejecutará el comando al minuto 1 de todos los Enero
1 * * 1-12/4 * COMANDO <-- ejecutará el comando al minuto 1 de cada 3er mes
1 * * * 1 COMANDO <-- ejecutará el comando al minuto 1 de todos los Lunes
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
49/93

El COMANDO puede ser un archivo aparte que pueda ser interpretado por el PSQL, debe
verificar que se cuente con el acceso pertinente para ejecutar los querys que este
archivo aparte va a ejecutar, por ello es lo mejor ejecutar el CRON como usuario
POSTGRES.
[postgres@host] crontab e
  * * * * * /var/lib/pgsql/cron.sh
Creamos un archivo cron.sh (o cualquier nombre) y le asignamos permisos de ejecución.
[postgres@host]touch cron.sh
[postgres@host]chmod +x cron.sh
[postgres@host]mcedit cron.sh
  #!/bin/sh
  # Programa en bash script de ejemplo de un CRON para PostgreSQL
  echo "Se inicia el log" >> file.txt
  date >> file.txt
  echo "Ejecuta un query con salida al log"
  export PGPASSWORD=dbadmin
  psql prueba c "select * from tablita limit 5"  U dbadmin  >> file.txt
  echo "Inicia un proceso de backup"
  FECHA=$(date)
  pg_dump prueba > $FECHA.dump U dbadmin
  echo "Backup finalizado, proceso concluido $FECHA" >> file.txt

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
50/93

2. Problemas comunes – Bloqueos
El comando LOCK nos permite bloquear una tabla.
prueba=# begin;
BEGIN
prueba=# lock tbl_transaccion in exclusive mode;
LOCK TABLE
En otra consola intentar esto:
prueba=# update tbl_transaccion set id = id * 2; <-- no culmina se queda en espera
En la consola anterior hacer “commit” y el update culminará.
Sin embargo si hacemos un “select” a esa tabla en otra consola la información procesará sin ningún
problema, los niveles de bloqueo permiten ejecutar cierto tipo de operaciones.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
51/93

Tipos de LOCK:
●ACCESS SHARE
●ROW SHARE
●ROW EXCLUSIVE
●SHARE UPDATE EXCLUSIVE
●SHARE
●SHARE ROW EXCLUSIVE
●EXCLUSIVE
●ACCESS EXCLUSIVE
http://www.postgresql.org/docs/9.0/interactive/explicit-locking.html
Hay que se cuidadoso con este comando, todas las operaciones a una DB ejecutan algún
tipo de lock pre-definido y entre ellos pueden llegar a colisionar
Para ver los locks:
prueba=# select * from pg_locks;
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted
------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+-----------------+---------
relation | 22073 | 10969 | | | | | | | | 2/6239 | 17247 | AccessShareLock | t
relation | 22073 | 22183 | | | | | | | | 1/439 | 2498 | ExclusiveLock | t
virtualxid | | | | | 1/439 | | | | | 1/439 | 2498 | ExclusiveLock | t
virtualxid | | | | | 2/6239 | | | | | 2/6239 | 17247 | ExclusiveLock | t
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
52/93

Para ver los querys que están ejecutando los locks:
SELECT
waiting.locktype AS waiting_locktype,
waiting.relation::regclass AS waiting_table,
waiting_stm.current_query AS waiting_query,
waiting.mode AS waiting_mode,
waiting.pid AS waiting_pid,
other.locktype AS other_locktype,
other.relation::regclass AS other_table,
other_stm.current_query AS other_query,
other.mode AS other_mode,
other.pid AS other_pid,
other.granted AS other_granted
FROM
pg_catalog.pg_locks AS waiting
JOIN pg_catalog.pg_stat_activity AS waiting_stm ON ( waiting_stm.procpid = waiting.pid )
JOIN pg_catalog.pg_locks AS other ON ((waiting."database" = other."database" AND waiting.relation = other.relation)
OR waiting.transactionid = other.transactionid )
JOIN pg_catalog.pg_stat_activity AS other_stm ON (other_stm.procpid = other.pid)
WHERE NOT waiting.granted AND waiting.pid <> other.pid
waiting_locktype | waiting_table | waiting_query | waiting_mode | waiting_pid | other_locktype | other_table |
other_query | other_mode | other_pid | other_granted
------------------+-----------------+-----------------------------------------+------------------+-------------+----------------+-----------------
+-----------------------+------------------+-----------+---------------
relation | tbl_transaccion | update tbl_transaccion set id = id * 4; | RowExclusiveLock | 17741 | relation | tbl_transaccion |
<IDLE> in transaction | RowExclusiveLock | 2498 | t
relation | tbl_transaccion | update tbl_transaccion set id = id * 4; | RowExclusiveLock | 17741 | relation | tbl_transaccion |
<IDLE> in transaction | ExclusiveLock | 2498 | t
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
53/93

Dado que PostgreSQL es una base de datos que soporta concurrencia entonces es posible
que un dato al momento de ser consultado este siendo borrado ó modificado por otro
usuario en otra transacción, para determinar en una consulta si los datos que estamos
usando están siendo afectados por otro usuario tenemos los valores de xmin y xmax,
cuando xmax está en blanco quiere decir que el dato no está siendo afectado por otra
transacción, cuando xmin y xmax tienen el mismo valor entonces el dato o fue
modificado o fue borrado por otra transacción.
prueba=# select *, xmin,xmax from tablita;
id | xmin | xmax
----+------+------
1 | 661 | 0
3 | 661 | 0
5 | 661 | 0
7 | 661 | 0
prueba=# select *, xmin,xmax from tablita;
id | xmin | xmax
----+------+------
1 | 661 | 0
3 | 661 | 661 <--- el dato fue borrado o modificado
5 | 661 | 0
7 | 661 | 0
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
54/93

Una manera sencilla de determinar cuantas conexiones tenemos vivas, y que están haciendo es consultar
la tabla pg_stat_activity
prueba=# select datname, usename, current_query, query_start from pg_stat_activity;
datname | usename | current_query |
query_start
---------+---------+----------------------------------------------------------------------------
+-------------------------------
prueba | dbadmin | select datname, usename, current_query, query_start from pg_stat_activity; |
2011-10-01 12:25:09.482213-05
Para ver el tiempo de ejecución de un query solo necesitas restar el current_timestamp
– el menor tiempo entre query_start y xact_start.
prueba=# select datname, usename, substr(current_query,1,15),
query_start, xact_start, current_timestamp - least(query_start, xact_start) as runtime
from pg_stat_activity;
datname | usename | substr | query_start | xact_start
| runtime
---------+---------+-----------------+-------------------------------
+-------------------------------+----------
prueba | dbadmin | select datname, | 2011-10-01 12:29:14.000863-05 | 2011-10-01 12:29:14.000863-05
| 00:00:00
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
55/93

2. Problemas comunes – Controlando el espacio ocupado por las tablas
d+ Nos muestra en psql el consumo de espacio por cada tabla dentro de una
DB, recuerde que es necesario ejecutar VACUMM FULL con cierta periodicidad
para no ocupar espacio útil del servidor con data inútil.
prueba=# d+
Listado de relaciones
Esquema | Nombre | Tipo | Dueño | Tamaño | Descripción
---------+---------+-------+---------+------------+-------------
public | tablita | tabla | dbadmin | 9280 kB |
prueba=# delete from tablita where id = 3;
DELETE 32768
prueba=# d+
---------+---------+-------+---------+------------+-------------
prueba=# VACUUM FULL tablita;
VACUUM
prueba=# d+
---------+---------+-------+---------+------------+-------------
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
56/93

2. Problemas comunes – Controlando el espacio ocupado por las bases de datos
Las bases de datos presentan el mismo comportamiento de las tablas, una manera de conocer
el tamaño de estas desde psql es:
prueba=# select datname, pg_database_size(datname) from pg_database;
  datname  | pg_database_size
+
template1 |          5642000
template0 |          5537796
postgres  |          5642000
prueba    |         72218384
prueba2   |          5537796
(5 filas)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
57/93

2. Problemas comunes – Detectando tablas que requieren VACUUM
Una manera de detectar si una tabla requiere un VACUUM con urgencia es
comparar la desviación entre las filas que almacena su estadística y las
filas físicas que realmente existen, esto se puede controlar así.
prueba=# SELECT (CASE WHEN reltuples > 0 THEN
prueba(# pg_relation_size('tablita')/(8192*relpages/reltuples)
prueba(# ELSE 0
prueba(# END)::bigint AS estimated_row_count
prueba-# FROM pg_class
prueba-# WHERE oid = 'tablita'::regclass;
estimated_row_count
---------------------
1835040
prueba=# select count(*) from tablita;
count
---------
1835040
prueba=# delete from tablita where id = 5;
DELETE 262144
count
---------
1572896
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
58/93

2. Problemas comunes – Detectando tablas que requieren VACUUM
Una manera de detectar si una tabla requiere un VACUUM con urgencia es
comparar la desviación entre las filas que almacena su estadística y las
filas físicas que realmente existen, esto se puede controlar así.
count
---------
1572896
pg_relation_size('tablita')/(8192*relpages/reltuples)
ELSE 0 END)::bigint AS estimated_row_count
FROM pg_class WHERE oid = 'tablita'::regclass;
estimated_row_count
---------------------
1835040
prueba=# VACUUM full tablita;
VACUUM
pg_relation_size('tablita')/(8192*relpages/reltuples)
ELSE 0 END)::bigint AS estimated_row_count
FROM pg_class WHERE oid = 'tablita'::regclass;
estimated_row_count
---------------------
1572896
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
59/93

2. Problemas comunes – Análisis de Querys
TIMING, permite visualizar el tiempo de ejecución de un query.
prueba=# timing
El despliegue de duración está activado.
prueba=# select sum(id) from tablita;
sum

  80
(1 fila)
Duración: 35,951 ms
prueba=# explain analyze select sum(id) from tablita;
                                                QUERY PLAN

Aggregate  (cost=40.00..40.01 rows=1 width=4) (actual time=0.040..0.041 rows=1 loops=1)
   >  Seq Scan on tablita  (cost=0.00..34.00 rows=2400 width=4) (actual time=0.007..0.018 rows=8
loops=1)
Total runtime: 0.103 ms
(3 filas)
Duración: 26,842 ms
Como se puede ver el tiempo de ejecución real de un query y el tiempo de realmente la
base de datos podría ejecutar la resolución del query.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
60/93

Explain permite visualizar el plan de ejecución de un query, el plan de
ejecución son los pasos que sigue la dmbs para procesar la consulta, tabla
por tabla con la que trabaja, las uniones, tipos de índices que utiliza,
tuplas movidas, etc.
prueba4=# explain select * from regla;
QUERY PLAN

Seq Scan on regla (cost=0.00..18.00 rows=800 width=72)
(1 row)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
61/93

Para ver los comandos usados y los tiempos de respuesta
prueba4=# explain analyze select * from regla;
                                            QUERY PLAN

Seq Scan on regla  (cost=0.00..18.00 rows=800 width=72) (actual time=0.012..0.016 rows=2 loops=1)
(2 rows)
Informa los campos requeridos en la consulta
prueba4=# explain verbose select * from regla;
                           QUERY PLAN

Seq Scan on public.regla  (cost=0.00..18.00 rows=800 width=72)
   Output: id, nombre
(2 rows)
prueba4=# explain analyze verbose select * from regla;
                                                QUERY PLAN

Seq Scan on public.regla  (cost=0.00..18.00 rows=800 width=72) (actual time=0.010..0.013 rows=2 loops=1)
   Output: id, nombre
(3 rows)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
62/93

Los Explain siempre se deben leer de “adentro hacia afuera”.
prueba4=# explain select * from factura_cab a  join factura_det b on a.id =b.fac_id;
                                  QUERY PLAN

Merge Join  (cost=260.93..525.73 rows=17120 width=29)
   Merge Cond: (b.fac_id = a.id)
   >  Sort  (cost=111.15..115.15 rows=1600 width=21)
         Sort Key: b.fac_id
         >  Seq Scan on factura_det b  (cost=0.00..26.00 rows=1600 width=21)
   >  Sort  (cost=149.78..155.13 rows=2140 width=8)
         Sort Key: a.id
         >  Seq Scan on factura_cab a  (cost=0.00..31.40 rows=2140 width=8)
(8 rows)
El primer explain fue hecho sin hacer un VACUMM a las tablas, en el segundo se
procedió a ello, nótese las diferencia en las cifras, esto se debe a las estadísticas.
prueba4=# explain select * from factura_cab a  join factura_det b on a.id =b.fac_id;
                               QUERY PLAN

Hash Join  (cost=1.07..2.16 rows=4 width=25)
   Hash Cond: (b.fac_id = a.id)
   >  Seq Scan on factura_det b  (cost=0.00..1.04 rows=4 width=17)
   >  Hash  (cost=1.03..1.03 rows=3 width=8)
         >  Seq Scan on factura_cab a  (cost=0.00..1.03 rows=3 width=8)
(5 rows)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
63/93

Para determinar si un índice debe ser utilizado, PostgreSQL debe tener estadísticas
sobre la tabla. Estas estadísticas se recolectan mediante VACUUM ANALYZE, o
simplemente ANALYZE. Usando las estadísticas, el optimizador sabe cuántas son las
filas en la tabla, y puede determinar mejor si los índices deben utilizarse. Las
estadísticas son también valiosas en la determinación de un orden óptimo y métodos de
unión. La recolección de Estadísticas debe ser realiza periódicamente como el cambio
de contenido de la tabla.
El costo:
(cost=149.78..155.13 rows=2140 width=8)
149.78    < costo inicial de traer la primera tupla
155.13    < costo total estimado
Rows=2140 < filas escaneadas
Width=8   < filas de salida
El costo total estimado se calcula sobre la siguiente formula
(disk pages read * seq_page_cost) + (rows scanned * cpu_tuple_cost)
seq_page_cost  < costo de acceso a las páginas de la data            (1.00 default)
cpu_tuple_cost < costo del proceso de cada fila durante la consultas (0.01 default)
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
64/93

El tiempo:
(actual time=0.007..0.018 rows=8 loops=1)
0.007     < tiempo de espera inicial que toma para empezar a procesar el query
0.018     < tiempo total en segundos que le toma procesar la consulta
Rows=8    < filas esperadas de retorno, una diferencia entre este y los ROWS del
              COST indican un posible problema en el optimizador interno de
              PostgreSQL para resolver la consulta.
loops=1   < En algunos casos, especialmente en JOINs es necesario ejecutar la
              consulta varias veces, los tiempos y ROWs deben ser multiplicados por
              el número de LOOPs para tener los totales reales.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
65/93

Seq Scan on factura_cab a  (cost=0.00..1.03 rows=3 width=8)
Seq Scan          < indica que esta llevando a cabo una busqueda secuencial en la
                      tabla, bien porque no existe un índice o bien porque no la
                      necesita.
on factura_cab a  < nos indica que esta buscando sobre la tabla “factura” con
                      alias “a”.
Hash  (cost=1.03..1.03 rows=3 width=8)
Hash              < significa que esta creando un mapa de datos e índices con el
                      Fin de facilitar búsquedas
Sort  (cost=149.78..155.13 rows=2140 width=8)
         Sort Key: a.id
SORT KEY          < nos índica por que campo esta realizando un ordenamiento y
                      Posteriormente el costo del ordenamiento
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
66/93

Merge Join  (cost=260.93..525.73 rows=17120 width=29)
   Merge Cond: (b.fac_id = a.id)
Hash Join  (cost=1.07..2.16 rows=4 width=25)
   Hash Cond: (b.fac_id = a.id)
Tanto en el caso Merge Join como en el caso Hash Join el dbms esta realizando la unión
de las dos tablas, nos indica el costo para cada caso.
Lo que tenemos que buscar siempre es que los COSTOS de nuestras consultas
sean lo más bajos posibles, no siempre una búsqueda secuencial puede tener
un costo mayor que una búsqueda indexada, eso dependerá de la data y
estructura de las tablas.
Es importante escribir querys limpios, dar el menor trabajo posible al
analizador de querys de PostgreSQL para que la resolución del plan de
ejecución sea la menor posible.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
67/93

Otros operadores que podemos encontrar son:
●Nested Loop      < Se combinan dos tablas utilizando bucles anidados. Por cada fila
                     de la tabla padre, se recorren todas las filas de la tabla hija.
●Index scan       < búsqueda sobre un índice
●Unique           < elimina registros de valores duplicados
●Limit            < indica que se esta pidiendo una cantidad limitada de registros,
                     aparece cuando se ha usado el operador en la consulta
●Aggregate        < concatenación de columnas
●Subquery Scan    < indica una subconsulta dentro del contexto de un UNION
●Subplan          < indica una subconsulta dentro de un subquery
●Append           < indica que se están uniendo 2 tablas, aparece cuando se uso el
                     operador UNION en la consulta
●Tid Scan (raro)
●Group            < indica que se hace un GROUP BY
●Result           < indica una operación que no mueve datos
●Materialize      < se da en caso de que existan subconsultas que se repiten y
                     el dbms decide almacenar los resultados obtenidos para su
                     rehuso.
http://www.iphelp.ru/faq/15/ch04lev1sec3.html
http://explain.depesz.com/ < Herramienta que permite subir un Explain y retorna la
                               información más estructurada y digerible.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
68/93

Instalando PostgreSQL 9.0
Precaución: PostgreSQL 9.0 no es parte oficial aún de los repositorios
oficiales de CentOS 6.
1. Descargar los RPM de la siguiente ruta:
   http://www.pgrpms.org/9.0/redhat/rhel6x86_64/pgdgcentos9.03.noarch.rpm
2. Instalar el rpm descargado, como usuario “root”.
   root@host$ rpm ivh pgdgcentos9.03.noarch.rpm
3. Instalar PostgreSQL 9.0
   root@host$ yum install postgresql90server
4. Iniciar la base de datos
   root@host$ /etc/init.d/postgresql9.0 initdb
   root@host$ /etc/init.d/postgresql9.0 start
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
69/93

El sistema de replicación asíncrona de PostgreSQL 9.0
El concepto de replicación es mantener una copia actualizada de la data en
un servidor alterno al principal, ¿porqué?:
* Para tener un sistema tolerable a fallas.
* Para balancear la carga de trabajo en diversos servidores.
* Para aplicaciones de alto consumo en consultas (B.I.)
* Para tener un ambiente de pruebas o desarrollo lo más parecido al
ambiente de producción.
* Muchas otras que se puedan imaginar .....
Existe al menos unas 10 soluciones viables para replicar bases de datos
PostgreSQL, todas ellas con sus pros y sus contras.
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
70/93

Características de la replicación interna de PgSQL 9.0
* Es Streaming Replication Hot Standby
* No requiere hardware especial
* No requiere de servidores/servicios especiales
* No sobrecarga el servidor principal
* No requiere de un sistema de resolución de conflictos (al menos
  no adicionales al que ya implementa la base de datos)
* Si se cayera la replicación al menos tendré acceso de lectura
  en el servidor alterno.
* PointInTime Recovery, es decir permite recuperar la data al
  Tiempo pasado más cercano donde esta se encuentre bien.
* Usa WAL como método de cache, esta técnica permite asegurar que
  solo las operaciones bien realizadas actualicen la data
  (atomicidad y durabilidad).
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
71/93

Desventajas:
* Múltiples servidores maestros/principales
* Asegurar que ante una falla el servidor principal nunca va a
perder la data (a nivel sistema operativo)
* Controlar la replicación a nivel de tablas
informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
72/93

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
73/93

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
74/93
El WAL es...
Básicamente es un buffer donde se llevan a cabo las
operaciones a la data y una vez terminada se pasan al
almacenamiento de datos principal, si algo pasara entonces el
área de datos permanecerá intacto solo se perderá lo que esta
en el WAL.
WAL genera segmentos de data de 16mb (configurable) en
archivos físicos que tiene páginas de datos de 8kb
(configurable).
WAL nunca borra data, siempre está añadiendo data nueva, en
general PostgreSQL nunca modifica o borra data, desactiva
páginas y crea nuevas con la nueva información, incluso puede
crear nuevas páginas solo para consulta.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
75/93
El WAL es...
Una ventaja del WAL es que puede residir en cualquier
directorio y podemos hacer un enlace simbólico al directorio
donde debería residir.
En caso de que suceda un problema el WAL puede retroceder
hacia el pasado hasta el último momento en que todo estuvo ok.
WAL maneja varios niveles para especificar que tanto deseo
almacenar en este buffer en el nivel mínimo solo contiene
información para recuperar una db en caso de paradas abruptas
del servicio.
Para realizar la replicación requerimos aumentar el nivel de
WAL para reconstruir toda la data de una db.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
76/93
Instalando
(0) Antes que nada creamos un punto de montaje vía SSHFS en el SLAVE
que montará un directorio especial del servidor MASTER, esto se puede
hacer vía NFS también.
En el MASTER:
[root@host] mkdir /home/wal_master <-- en este directorio se grabará el backup
del WAL.
[root@host] chown postgres:postgres /home/wal_master <-- volvemos propietario de este
directorio al usuario POSTGRES.
En el SLAVE:
[root@host] yum install sshfs <-- instalamos sshfs si no lo tenemos
debemos tener el repositorio de RPMFORGE
[root@host] chmod +x /usr/bin/fusermount <-- esto es una limitación de CentOS, hay que
autorizar ejecución a otros usuario del
comando “fusermount”
[root@host] mkdir /home/wal_slave <-- de este directorio se leerá la copia
Del WAL
[root@host] chown postgres:postgres /home/wal_slave <-- volvemos propietario de este
Directorio al usuario POSTGRES.
[root@host] su – postgres <-- ingresamos como usuario POSTGRES
[postgres@host] sshfs root@(ip_master):/home/wal_master /home/wal_slave
Al ejecutar este comando necesitamos ingresar la clave del “root” del servidor MASTER.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
77/93
Instalando
(1) Autorizamos a los servidores a accesar a cada servidor
remoto
Editamos pg_hba.conf en el slave y añadimos esto:
host replication postgres (ip_master)/32 trust
Editamos pg_hba.conf en el master y añadimos esto:
host replication postgres (ip_slave)/32 trust
“replication” no es una base de datos real, es una palabra reservada
de la conexiòn para la réplica, ambos servidores deben poder
autenticarse uno al otro.
Editamos postgresql.conf en el slave y modificamos este parámetro:
listen_addresses = 'localhost,(ip_master)'
Editamos postgresql.conf en el master y modificamos este parámetro:
listen_addresses = 'localhost,(ip_slave)'
Si tenemos un master que alimenta varios slave entonces debemos añadir
en el tantos ips como sea necesario.

informes@eqsoft.net
Teléfonos: (51) (1) 5645744 / 5645424
78/93
Instalando
(2) Configuramos el postgresql.conf del master
wal_level = hot_standby <-- este parámetro permitirá crear archivos que son capaces de
regenerar toda la base de datos.
archive_mode = on <-- indica que se deben generar archivos de backup de lo que
el WAL genere
archive_command = 'cp %p /home/wal_master/%f' <-- indica a donde se van a copiar los
backups del WAL.
max_wal_senders = 5 <-- cantidad de conexiones que ejecutará el proceso
wal_keep_segments = 32 <-- cantidad de “logfile segments” que se mantendrán vivos,
cada uno de ellos es de 16MB, si este número es muy
pequeño el sistema podría eliminar data antes de ser
movida al SALVE, un número muy alto ocupará una cantidad
de espacio moderado.
Iniciamos nuestro servidor MASTER

Dba PostgreSQL desde básico a avanzado parte2

Dba PostgreSQL desde básico a avanzado parte2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Dba PostgreSQL desde básico a avanzado parte2

Ähnlich wie Dba PostgreSQL desde básico a avanzado parte2 (20)

Mehr von EQ SOFT EIRL

Mehr von EQ SOFT EIRL (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (16)

Dba PostgreSQL desde básico a avanzado parte2