On Fri 12 Sep 2014 14:12:36 Leslie León Sinclair escribió:
> Gracias ya entré, un poco lento el https pero es algo, leeré un poco y
> después comento mis resultados...
Dejame ver si te ahorro un poco de trabajo, aunque no estan las figuritas, pero
bueno es algo..
Unidad II – Instalación de PostgreSQL
Objetivo: Que el alumno conozca las bases y los pasos para lograr una
instalación exitosa de la
PostgreSQL por diferentes medios y en diferentes plataformas.
1 . 1 Instalación de PostgreSQL en GNU/Linux
La instalación de programas en GNU/Linux es un tema amplio y donde se debe
tener en cuenta varias
cosas antes de instalar cualquier programa. El mecanismo de instalación
depende de la distribución en
la que pretendemos instalar la PostgreSQL.
La mayoria de las grandes distribuciones que existen en el mercado (Red Hat,
Debian, Slackware,
Gentoo, Suse y Mandrake) disponen en sus CD's de instalación los paquetes para
instalar una
PostgreSQL. Si no queremos complicar mucho las cosas podemos simplemente
instalarlo desde el
administrador de paquetes correspondiente. Pero en cambio si queremos la
ultima versión disponible y
deseamos personalizarla al máximo tendremos que compilar los fuentes.
1. 2 Instalación de programas en GNU/Linux, consideraciones.
Antes de instalar la PostgreSQL tenemos que conocer como se instalar cosas en
GNU/Linux.
Podemos clasificar a las distribuciones GNU/Linux según su sistema de
instalación de paquetes, si lo
hacemos tendremos 3 grandes ramas.
Basadas en paquetes Rpm
Red Hat / Fedora
Mandrake
Suse
Basadas en paquetes Deb
Debian
Knoppix
Rxart
Basadas en archivos Fuentes
Gentoo
Ututo
Se debe conocer que sistema de paquetes tiene su distribución antes de
instalar algo por que no
podemos instalar Rpm en Debian por ejemplo, para instalar en Debian debemos
buscar los paquetes
Deb. Lo mismo sucede al revez, no podemos instalar Deb en Red Hat.
Además, si tenemos Red Hat, debemos buscar los paquetes Rpm para Red Hat por
que puede ser que
los paquetes Rpm de Mandrake fallen al instalarse en Red Hat. Con esto
pretendo decir que cada
distribución tiene sus propios paquetes, así que si eligen este mecanismo de
instalación lo primero que
deben hacer el buscar el paquete para la distribución que tienen instalada.
Si no quieren pelear con esto lo que pueden hacer es compilar el programa
desde su código fuente, para
ello deben descargarse el código fuente del programa, verificar que se cumplen
los requerimientos y
realizar una compilación, igualmente este mecanismo se puede complicar si el
proceso de compilación
nos arroja un error.
Debido a la variedad de sistemas de instalación solo veremos en detalle como
instalar la PostgreSQL
desde código fuente, pero al final veremos brevemente como usar los otros
mecanismos.
1. 3 Instalación por medio de los Fuentes
Lo primero que se debe hacer es descargarse los fuentes, lo puede hacer desde
la sección downloads de
la pagina oficial www.postgresql.org. Al momento de escribir esta documentación
la ultima versión
disponible es la 8.1.3 y el paquete se llama postgresql8.1.3.tar.bz2.
Antes de empezar la instalación debemos crear el usuario postgres, este
usuario se usará para asignar
los permisos de los archivos en el file system y lanzará el demonio con sus
permisos. Se puede llamar
de otra manera pero por lo general se lo llama así.
Para crearlo usaremos el comando useradd y para asignarle una contraseña
passwd. La secuencia de
comandos es la siguiente.
#useradd postgres
#passwd postgres
Enter new UNIX password:
Retype new UNIX password:
passwd: contraseña actualizada correctamente
Con eso ya tenemos el usuario, lo que haremos ahora es descomprimir el archivo
con los fuentes que
descargamos de internet. Para ello usamos el comando tar.
#tar jxvf postgresql8.1.3.tar.bz2
Al terminar de descomprimir nos quedara un directorio llamado postgresql
8.1.3, entramos adentro de
dicho directorio con el comando cd.
Una vez allí adentro lo que debemos hacer es preparar el archivo de
configuración ejecutando el
comando configure. Aquí se deben pasar los flags de compilación para lograr una
postgres
personalizada según nuestras necesidades. Para ver los flags de compilación
pude ver el archivo
INSTALL dentro del mismo directorio. Ejecutaremos el configure sin flags.
#./configure
Nótese el uso de ./, esto es por que el comando configure esta en el directorio
y no el el Path del
sistema. Configure es propio del archivo fuente y cada paquete de fuente trae
su propio configure.
Después que termino de configurar y si no fallo se debe proceder a la
compilación. Para ello usamos el
comando make.
#make
Este se alimenta de la salida de configure y realiza la compilación. Cuando
termine si no nos devuelve
errores procederemos a la instalación con make install.
#make install
Ahora tenemos instalados los archivos de la postgres. Nos resta configurar el
entorno para esto
debemos exportar una variable de entorno, $ LD_LIBRARY_PATH . Si realizaron
una instalación por
defecto estas estaran en '/usr/local/pgsql/lib', así que deberán añadir al
final del archivo /etc/profile la
siguiente linea.
export LD_LIBRARY_PATH=/usr/local/pgsql/lib
Ahora lo que vamos a hacer es crear el cluster, lo primero que debemos hacer
es crear el directorio en
donde queremos que se guarden las bases, por lo general
'/var/lib/postgres/data', poner como dueño del
directorio al usuario postgres y loguearnos como el. Por ultimo usamos el
comando initdb para iniciar
el cluster. La secuencia de comando de todo esto es la siguiente.
#mkdir /var/lib/postgres
#mkdir /var/lib/postgres/data
#chown postgres.postgres /var/lib/postgres/data
#su – postgres
$initdb d /var/lib/postgres/data
Si todo nos sale bien nos aparecerá un mensaje que dice “Success”.
Ya tenemos la postgres lista para usar, lo único que falta es configurar los
scripts de arranque para que
se inicie junto con el sistema operativo.
Nos logueamos como root y debemos ir al directorio de los fuentes, mas
precisamente al directorio
postgresql8.1.3/contrib/startscripts/, y copiar el archivo linux, que es el
script que maneja el demonio
en linux, al directorio /etc/init.d/ de la siguiente manera.
#cp linux /etc/init.d/postgres
Debemos asignarle permisos de ejecución con chmod
#chmod +x /etc/init.d/postgres
Y para finaliza ejecutamos el comando chkconfig para configurara en que momento
se debe iniciar y
apagar.
#chkconfig add postgres
Con esto finalizamos la instalación, el paso siguiente será configurar el motor
y los metos accesos a los
usuarios, pero eso le veremos más adelante.
1.4 Extras
En esta sección veremos muy brevemente como se instalaría con los paquetes
precompilados en cada
tipo de distribución.
1.4.1 Instalación por Rpm
Supongamos que tienen instalado Suse y optaron por instalar los paquetes por
medio de Rpm. En los
CD's de instalación seguramente están los paquetes de la PostgreSQL pero
ustedes deciden descargarse
de internet la ultima versión. Al encontrarla la descarga directamente a su
home y el nombre del
archivo es postgresql8.3noarch.rpm.
Entonces para instalarlo deben entrar al sistema como el usuario root y
ejecutar el siguiente comando.
#rpm Uvh postgresql8.3noarch.rpm
Este comando comenzará el proceso de instalación, copiara todos los archivos
binarios, crea el usuario
postgres y configurará los archivos de inicio del demonio, algunos paquetes
también crean el cluster.
1.4.1 Instalación en sistemas Debian
Debian cuenta con uno de los sistemas de instalación de programas mas
eficientes del mundo, este se
llama el apt. Consiste en que existen servidores en internet en los que se
almacenan todos los paquetes
de las diferentes versiones de Debian y cuando alguien desea instalar algo
automáticamente se descarga
de los servidores los paquetes y los instala.
Para instalar un programa se utiliza el comando “aptget install programa...”,
en este caso para instalar
la PostgreSQL se deberá ejecutar el siguiente comando.
#aptget install postgresql8.0
1.4.1 Instalación en sistemas Gentoo
Si son usuarios de Gentoo no deberían estar mirando esta documentación de como
hace una instalación
por que me imagino que estarán cerca de ser unos expertos en GNU/Linux.
Gentoo trabaja casi de igual manera que Debian, posee servidores en internet
con los paquetes de
instalación y cuando uno pretende instalar algo se los descarga
automáticamente. La principal
diferencia es que este sistema no se descarga paquetes precompilados, se
descarga los códigos fuentes y
los compila para esa maquina.
Para instalar programas se usa el comando “emerge”, en el caso de la
PostgreSQL sería de la siguiente
manera.
#emerge postgresql
2 Instalación en Windows
2.1 Concideraciónes
Antes de comenzar la instalación de PostgreSQL en Windows se debe tener en
cuenta lo siguiente.
Disponer de Windows XP o 2000.
Tener una partición NTFS, no se puede instalar en Fat.
Estar logueado como usuario con privilegios.
Cerrar todos los programas actualmente en uso.
Seguir al pie de la letra el siguiente instructivo.
2.2 Selección del Idioma
Lo primero que se debe hacer es seleccionar el idioma del asistente de
instalación, hasta la versión
existente a la hora de escribir este material no se encontraba disponible el
idioma español, lo más
entendible es ingles así que veremos el ejemplo en este idioma.
Luego de seleccionar el idioma nos recomendara cerrar todos los programas que
estemos ejecutando,
seleccionamos siguiente.
A continuación nos muestra un mensaje con las Reléase Notes de la ultima
versión, las reléase notes
son los cambios y características nuevas de la versión que estamos instalado,
después de leer hacemos
clic en siguiente.
2.3 Selección de Paquetes a instalar
La siguiente pantalla nos pregunta que es lo que deseamos instalar, lo único
que se instala por defecto
es el motor, todas la herramientas adicionales son opcionales. Este instalador
para Windows nos provee
de una amplia gama de herramientas de mucha utilidad, veremos una por una las
opciones.
La primera opción es “Data Directory”, esta especifica que se ejecute el initdb
para inicializar el cluster
inicial, siempre debe ser elegida.
“Nacional Language Support” agrega soporte multi lenguaje a los mensajes
emitidos por la Postgres,
por defecto solo arroja mensajes en Ingles. Puede ser utilizado con el psql.
“Postgis” es un conjunto de tipos de datos y funciones para sistemas GIS
(Geographic Information
Sistems), estos son sistemas para guardar y manipular información geográfica.
No existe ningún
sistema de Base de Datos con mejor soporte para este tipo de sistema que la
Postgres. Si no trabajan, o
no pretenden aprender, sobre sistemas GIS no elijan esta opción.
Entre las interfaces de usuarios tenemos el archiconocido psql, consola
interactiva de tipo textual, ideal
para fanáticos de las consolas, para maquinas con pocos recursos y para
administración remota vía
Internet dado que consume poco ancho de banda.
La otra opción es pgAdminIII, uno de los clientes visuales mas completos que
andan dando vuelta
alrededor de la Postgres, es muy sencillo de usar y ayuda mucho a la hora de
crear Funciones y
Triggers. La recomendación es que instalen las dos opciones dado que una es
buena para algunas cosas
y la otra es buena para otras cosas, entre ambas se compensan.
Continuando con las opciones tenemos que el instalador nos trae un conjunto de
drivers para
conectarnos desde las aplicaciones que desarrollemos.
JDBC driver es el driver para conectarnos desde Java.
Npgsql es un Driver ADO.NET para conectarnos desde aplicaciones .NET.
ODBC y OLEDB son drivers para conectarnos desde cualquier lenguaje y
plataforma de desarrollo.
Igualmente estas no son las únicas opciones para conectarnos a la postgres
desde nuestras aplicaciones
pero son las más comunes.
Documentación, nos instala una carpeta con toda la documentación oficial de la
actual versión en
formato HTML en ingles, esta documentación esta muy completa y abarca todos
los aspectos que se
deben conocer sobre el motor. El material de este curso esta basado en un 85%
sobre dicha
documentación.
Por ultimo trae los paquetes para Development, es decir desarrollo. Con estos
paquetes podemos
desarrollar funciones más complejas y extender las funcionalidades de la
postgres a nuestras
necesidades con funciones externas al motor desarrolladas en C o C++, las
librerías que trae son
compatibles con Visual C++ de Microsoft.
Este aspecto de la Postgres en muy avanzado y escapa de los objetivos del
curso, así que no podremos
abordar mucho sobre este tema pero en la documentación oficial encontraran un
capitulo llamado
“Extendiendo PostgreSQL” donde se explica detalladamente como hacer esto. Por
ahora no elegiremos
esta opción.
Luego de terminar de elegir los paquetes debemos hacer clic en siguiente.
2.4 Instalando el Servicio
Lo siguiente que nos pregunta es si deseamos que la postgres corra como un
servicio de Windows, que
es lo mas práctico dado que podemos administrarlo desde la Magnament Console
de Windows.
Para el curso elegiremos esta opción, en caso de no querer que sea así
destilden la opción “install as a
service”, el instalador pasara a copiar los archivos y dejara en nuestras
manos todas las tareas restantes.
Como vimos previamente en el curso, el servicio o demonio de la PostgreSQL, el
postmaster, debe ser
inicializado por un usuario sin privilegios de administrador, comúnmente
llamado postgres.
Este instalador nos pregunta quien será el usuario que ejecutará el servicio,
en caso de no haberlo
creado todavía el usuario, el instalador lo crea por nosotros, solo debemos
poner el nombre de usuario
en “Account Name” y la contraseña en “Password”, de no poner una contraseña se
le asignara una
automáticamente. Aparecera la siguiente Pantalla pidiendo la confirmación para
crear el usuario.
Si ya creamos el usuario con el que deseamos iniciar el servicio solo debemos
poner el nombre del
usuario, el instalador se verificará la existencia del mismo y no creara uno
nuevo.
2.5 Iniciar el Cluster
Ahora debemos configurar los parámetros para iniciar el cluster, en caso de no
querer que el instalador
inicialice el cluster solo se debe destilar la opción “Initialize database
cluster”.
Lo primero que nos pregunta es el puerto en el cual escuchará el servidor, así
como la MySql escucha
en el puerto 3306 y el SQL Server escucha en el 1433, por defecto la Postgres
siempre escucha en el
5432, pero se puede poner que escuche en otro puerto.
Addreses lo que hace es habilitar la escucha en dicho puerto, si no la activan
solo se podrán conectar al
Motor desde la maquina local.
Locale es el lenguaje en que se mostraran los mensajes, y Encoding es la
formato en que se guardarán
las cosas, a menos que sean unos expertos dejen estas dos opciones por
defecto.
“Super username” es el nombre de la cuenta del súper usuario del motor, es
creada cuando se inicializa
el cluster. No olviden poner una contraseña.
2.6 Selección de los Lenguajes Procedurales.
En esta versión solo trae para elegir PL/pgsql, pero seguramente próximas
versiones traerán mas
lenguajes posteriormente. Elijan si o si instalar el PL/pgsql por que mas
adelante en el curso lo
usaremos para hacer Procedimientos de Almacenado.
2.7 Selección de Módulos Adicionales
En esta etapa debemos elegir, si queremos, módulos adicionales a los
estándares. No conozco para que
sirven todos los módulos, por lo general son funciones y conjunto de tipos de
datos y reglas que se
instalan en la template1. Pueden ser instalados manualmente mas adelante.
Algunos módulos interesantes son:
Cube: Implementación para cubos de decisión.
Time Travel: Permite ver los datos que la base tenia guardados hace X tiempo
atrás, aunque ya se
hallan borrado, es muy peligrosa y ocupa mucho espacio en el disco.
TSearch2: Permite búsquedas dentro de textos.
ISBN y ISSN: Tipos de datos para manipular ISBN e ISSN.
Large Object: Extención para manejar BLOB, útil para DataWhereHousing.
2.8 Finalizando
Después de haber terminado de elegir los módulos adicionales pedirá
confirmación para comenzar la
copia de los archivos.
Nos mostrara una barra de progreso y no indicara lo que esta haciendo.
Después nos aparecerá el siguiente mensaje que indica que el cluster esta
siendo inicializado.
Cuando esta operación termine registrará el servicio y terminara la
instalación mostrándonos el
siguiente mensaje.
Hacemos clic en finalizar y podemos empezar a trabajar.
3 Archivos de Configuración
Como la gran mayoría de las herramientas Unix, PostgreSQL se configura a partir
de tres archivos de
configuración. Estos archivos de configuración se encuentran en el directorio
en
donde inicializamos el
cluster (por lo general /usr/lib/pgsql/data).
El primer archivos que veremos es el postgresql.conf, este es el archivo de
configuración de los
parámetros globales del motor. Los otros dos archivos vienen juntos de la
mano, el pg_hba.conf
configura los métodos de acceso para los usuarios, el pg_ident.conf es la tabla
de mapeo para los
usuarios que tienen configurado el método ident en el pg_hba.conf, ya lo
veremos esto con más detalle.
En esta unidad solo trataremos el archivo postgresql.conf, pero en el capitulo
de administración de
usuarios veremos con detealle el pg_hba.conf y el pg_ident.conf.
3.1 Sobre los archivos de configuración
Antes que nada dejaremos claro algunas consideraciones sobre los archivos de
configuración.
Lo primero a tener en cuenta es que las líneas que tengan un # (numeral o
sharp) en el comienzo son
comentarios, estas líneas no son procesadas, en vez de borrar una línea es
mejor comentarla.
Los parámetros consisten básicamente en “nombre = valor”, salvo algunas
excepciones.
Tengan en cuenta siempre la identación del archivo, sino se puede hacer
ilegible con el tiempo.
Por lo general todos los archivos de configuración poseen un comentario acerca
de los parámetros que
contienen y para que sirven, lean siempre estos comentarios.
Antes de cambiar algún valor recuerden hacer una copia de los archivos de
configuración.
En Linux pueden usar el Vim para editar los archivos, este editor colorea la
sintaxis del archivo
haciendo más fácil su lectura.
Para que los cambios en el archivo de configuración tengan efectos se debe
reiniciar el servidor.
3.2 postgresql.conf
Este es el archivo de configuración más importante de la PostgreSQL, desde aquí
se pueden manipular
todo el motor. Las variables que configura este archivo pueden pasarse a mano a
la hora de iniciar el
servicio, pero es recomendado manejar los parámetros desde este archivo de
configuración.
Esta compuesto por varias secciones, cada sección posee un conjunto de
parámetros referidos a alguna
característica en particular del motor. Las secciones del archivo son las
siguientes.
Secciones
FILE LOCATIONS: Path de los archivos de la PostgreSQL.
CONNECTIONS AND AUTHENTICATION: Parámtros de Conexión.
RESOURCE USAGE (excepto WAL): Establece los recursos que puede usar.
WRITE AHEAD LOG: Parámetros del Protocolo Wal (ver Transacciones).
QUERY TUNING: Parámetros para el Optimizador de Consulta.
ERROR REPORTING AND LOGGING: Establece cuantos y que tipo de mensajes
mostrar.
RUNTIME STATISTICS: Establece que debe registrar para generar estadísticas.
CLIENT CONNECTION DEFAULTS: Parámetros de conexión.
LOCK MANAGEMENT: Establece parámetros para el manejo de Bloqueos (ver
Transacciones).
VERSION/PLATFORM COMPATIBILITY: Parámetros de compatibilidad para bases
heredadas que se migraron a versiones actuales.
No veremos en detalle cada uno de los parámetros del motor dado que esto sería
muy aburrido, solo
veremos los parámetros más importantes. Pero entre los recursos del curso
encontrarán un PDF en
ingles llamado “Postgresql.conf detalle de Parámetros” que detalla todos los
parámetros de este
archivo.
3.2.1 FILE LOCATIONS
Estas variables por defecto toman las mismas que se generaron al momento de
crear el cluster, pero
suelen modificarse en caso de querer realizar cambios o utilizar otros cluster
creados posteriormente o
previamente al cluster actual. Las más importantes de esta sección son.
data_directory: especifica el directorio donde se almacena el cluster.
hba_file: especifica la ubicación del archivo pg_hba.conf
ident_file: especifica la ubicación del archivo pg_ident.conf
3.2.2 CONNECTIONS AND AUTHENTICATION
Esta sección es muy importante, aquí se establece por ejemplo el puerto TCP en
el que escuchara las
peticiones el motor. También se establece si se aceptaran conexiones desde
otras maquinas. Lo primero
que suele suceder después de instalar una PostgreSQL es que no podemos
conectarnos con ninguna
herramienta que no sea la consola interactiva, esto sucede por que por defecto
esta no escucha
peticiones TCP, solo se puede conectar a través de sockets, y casi todas las
herramientas de terceros
pretenden conectarse por puertos TCP. Para abrir un puerto TCP debemos cambiar
el valor de
listen_addresses, esta variable especifica una lista de conexiones a las que se
le permite conectarse,
pueden ponerse direcciones IP como nombres de Host estos deben ir separados
por comas simples. El
valor de esta variable por defecto es localhost, es decir la maquina que tiene
el servidor, pero en
algunas versiones esta línea aparece comentada para evitar conexiones no
permitidas. En caso de querer
aceptar conexiones de cualquier dirección de la red se puede poner un ‘*’,
úsese con mucho cuidado
puede traer problemas de seguridad.
Otras variables importantes son:
port: Establece el número de puerto TCP en el que se escuchará, por defecto
5432.
max_connections: Número máximo de conexiones permitidas, por defecto se
permite 100, pero esto
dependerá del hardware del servidor, se estima que por lo menos se necesita
como mínimo 500 bytes de
memoria por cada conexión. Es decir que aproximadamente, si se establecen las
100 conexiones se
llegara a consumir 50 mb de RAM.
3.2.3 RESOURCE USAGE
Aquí configuramos los recursos que le permitiremos utilizar. De esta
configuración depende el
funcionamiento óptimo del motor. Esta sección a su vez esta dividida en otras
tres subsecciones.
Veamos cada una de estas en detalle.
Memoria
shared_buffers: Establece el número de buffers de memoria compartida usados por
el servidor de base
de datos. Como mínimo deberá ser de 2 x max_connections. Por defecto él numero
es 1000, pero suele
suceder que el kernel del Sistema Operativo subyacente no soporte tantos y al
hacer el initdb este
proceso falle, para solucionar esto se deberá recompilar el kernel del S. O. o
bajar él numero de buffers.
Cada buffer tiene un tamaño de 8 kb, es decir que por defecto consumé 8 mb de
memoria. El consumo
de memoria de los buffers nunca debe ser mayor a 1/3 de la memoria física.
work_mem: Establece la cantidad de memoria que será usada para ordenamiento y
tablas de Hash
antes de pasar a archivos temporales de disco. Antes de cambiar este valor se
debe tener en cuenta que
varias operaciones de ordenamiento o que usen tablas de Hash pueden estar
corriendo paralelamente,
cada una de estas operaciones consumirá su work_mem antes de pasar a disco.
Esto producirá que el
tamaño de work_mem aumente considerablemente, imagínese el peor de los casos
en que las 100
conexiones por defecto realicen simultáneamente operaciones de ordenamiento,
tendrían 100 x 1 mb =
100 mb de memoria de física utilizada para los ordenamientos.
maintenance_work_mem: Estable la cantidad de memoria que se utilizara en
operaciones de
mantenimiento. Por defecto la cantidad asignada es de 16 Mb, asignarle mas
memoria solo agilizará los
procedimientos de VACUUM y DUMP, es recomendado dejarlo como esta.
Free Space Map – Mapa de Espacio Libre
max_fsm_pages: Establece el número de paginas de disco para el cual se llevara
un registro de dicho
espacio en el mapa de espacio libre compartido. El tamaño por defecto es 2000,
pero es recomendado
para bases grandes que sea 16 x max_fsm_relations.
max_fsm_relations: Establece el número máximo de relaciones para el cual se
llevara un registro de
dicho espacio en el mapa de espacio libre compartido.
Kernel Resource Usage
max_files_per_process: Establece el número máximo de archivos que puede abrir
un proceso.
preload_libraries: Indica las librerías dinámicas que deben cargarse al
momento de iniciar el servidor,
se indican las librerías por lo general de la siguiente manera
’$libdir/plpgsql:plpgsql_init' donde en este
caso las librerías son para el lenguaje procedural PL/pgSQL.
Vacumm Delay
El conjunto de estos valores modifica los procesos de vacumm, solo establecen
parámetros para tratar
de optimizar el mantenimiento de la base. Por lo general no se suelen
modificar.
vacumm_cost_delay: Es el tiempo en milisegundos que el proceso debe esperar si
el costo de
realizarlo excedió los limites aceptables.
vacumm_cost_page_hit: Es el costo de hacer un vacumm sobre un buffer encontrado
en la cache de
buffers compartida.
vacumm_cost_page_miss: Es el costo de hacer un vacumm sobre un buffer no
encontrado y que debe
ser recuperado del disco.
vacumm_cost_limit: Es el costo que cuando un proceso de vacumm lo excede causa
que este sea
pausado durante vacumm_cost_delay tiempo.
Background Writer
Esta parte del RDBMS lo que hace es bajar un porcentaje de paginas sucias, es
decir que se
modificaron recientemente, de la memoria al disco. Lo que hace básicamente es
cada cierto intervalo de
tiempo recupera un porcentaje de paginas y lo descarga al disco. Desde esta
sección del archivo de
configuración se puede manipular los parámetros de este mecanismo.
bgwriter_delay: Tiempo del intervalo.
bgwriter_percente: Porcentaje de paginas que serán bajadas al disco.
bgwriter_maxpages: Numero máximo de paginas que serán bajadas al disco.
3.2.4 WAL Options
WAL es el protocolo para realizar transacciones, se verá con más detalle en
capítulos posteriores. Este
protocolo tiene un conjunto de parámetros manipulables desde este archivo de
configuración para hacer
al motor más robusto, confiable y lento, o en el otro extremo más relajado,
menos confiable y rápido.
fsync: Por defecto esta opción es verdadera (true), lo que indica es que el
RDBMS envié la llamada del
sistema fsync() en varios lugares para asegurar la persistencia de los datos
que están en memoria en el
disco, es decir que los cambios sean permanentes. Esto asegura la consistencia
del motor todo el
tiempo.
Esta opción hace que el motor tenga una penalización de performance, dado que
por cada Commit se ve
obligado a hacer un fsync(), debe bajar los cambios al disco. Si esta
desactivado el sistema operativo
retrasa las escrituras al disco hasta el momento en que calcule que es el más
optimo para realizar la
operación. Esto mejora significantemente la performance de la PostgreSQL pero
no se puede asegurar
la consistencia del cluster ante un imprevisto en el Sistema Operativo,
cualquier error del sistema
operativo puede causar la perdida de información y hasta la perdida del
cluster por completo.
wal_sync_method: Este parámetro indica que señal es enviada para realizar la
descarga de memoria al
disco, la señal a emplear depende totalmente del sistema operativo de base. No
todas las señales
disponibles en el archivo de configuración funcionarán en todos los sistemas
operativos.
Si pretenden cambiar este parámetro es recomendada una profunda lectura de las
señales del sistema
operativo y disponer del tiempo para correr test comparativo y de fallas.
Por defecto se utiliza fsync que es una señal elemental y esta disponible en
todos los sistemas
operativos que digan cumplir algo del estándar POSIX.
wall_buffers: Establece él numero de buffers para mantener información de WAL,
por defecto trae 8
buffers. Modificar este valor no mejorara la performance del motor a menos que
se procesen
constantemente transacciones enormes, cosa poco común, pero si ese es el caso
no se debe exceder de
16 32.
commit_delay: Indica el tiempo que debe esperar una transacción commited antes
de hacer un fsync.
Este valor es por defecto cero, pero con un valor mayor lo que puede pasar es
que se haga fsync para un
conjunto de transacciones que terminaron dentro del delay de otra transacción.
En la figura pueden ver
que T1 termina y espera, mientras tanto termina T2 y T3 que también entran en
espera, cuando termina
el tiempo de espera de T1 se envía el fsync para esta y también para T2 y T3,
es decir se uso un fsync
para 3 transacciones.
Esta configuración es realmente útil en el caso de que la carga sean muchas
pero pequeñas
transacciones.
commit_siblings: Este valor esta profundamente relacionado con el anterior, en
caso de usar
commit_delay este parámetro establece él numero máximo de transacciones
concurrentes dentro de un
commit_dely. Si alguna transacción esta esperando su fsync y se encuentran
abiertas él numero máximo
de transacciones posibles no se pueden abrir nuevas transacciones, estas deben
esperar a que terminen
las anteriores.
Se debe tener en cuenta que entra más grande sea este numero mayor será la
probabilidad de que se
finalicen transacciones dentro del commit_delay. Pero un exceso en él numero
transacciones abiertas
causa mas inseguridad ante fallos en el sistema.
Checkpoints
La secuencia de transacciones se registran en el archivo xlog, pero en un
determinado momento esto se
vuelca a los archivos de datos todo lo que a sido logeado, este momento se
denomina checkpoint.
Es un punto del archivo xlog que asegura que todo lo registrado antes de este
checkpoint sé a guardado
satisfactoriamente en los archivos de datos.
La PostgreSQL, mas exactamente el proceso escritor en segundo plano o
background writer process,
automáticamente crea checkpoints cada un determinado segmento o cierta
cantidad de tiempo, esto se
configura con los parámetros checkpoint_segment y checkpoint_timeout
respectivamente. Este
parámetro es uno de los que hacen variar las prestaciones del RDBMS
notablemente, se debe estudiar
bien el escenario en el que corre el motor.
checkpoint_segment: Establece la máxima distancia entre checkpoints dentro de
un segmento del
archivo de log. Por defecto es 3, en caso de sistema con mucha carga de
escritura suele recomendarse 8,
en bases donde se realizan escrituras de varios GB se recomienda 128, también
es necesario contar con
gran espacio para el archivo de log.
checkpoint_timeout: Establece el tiempo máximo entre dos checkpoints. Por
defecto es 300
milisegundos, en sistemas con mucha carga se suele poner en 30 minutos.
Estos dos valores se deben configurar juntos, si uno aumenta el otro también y
viceversa. No tiene
sentido hacer crecer el checkpoint_segment y dejar el checkpoint_timeout como
estaba, dado que
relativamente trabajara igual.
3.2.5 Resumen
Quedaron muchos parámetros por ver los veremos a medida que avancemos con los
temas, esto solo
fue una visión panorámica de las cosas más fundamentales.
4 Manejo del Servicio PostgreSQL
Como ya hablamos anteriormente la Postgres corre dentro del sistema operativo
como un servicio, esto
es un programa que corre en segundo plano y espera peticiones para realizar
alguna tarea en particular.
El servicio de la Postgres se llama Postmaster, y tanto en linux y en windows
se administran de manera
diferentes.
4.1 Manejo en Linux
Suponiendo que tiene un sufijo xxx, que es el numero de versión por lo general.
Para dar de baja el servicio
#/etc/init.d/postgresql-xxx
stop
Para dar de alta
#/etc/init.d/postgresql-xxx
start
Para reiniciarlo
#/etc/init.d/postgresql-xxx
restart
Para ver su estado
#/etc/init.d/postgresql-xxx
status
En caso de usar RedHat, Suse, Mandrake se puede usar el comando service de la
siguiente manera.
#service postgresql-xxx {stop|start|restart|status}
4.2Manejo en Windows
Para administrar el servicio en windows debemos ir a inicio, panel de control,
herramientas
administrativas, servicios.
Una vez aquí adentro solo deben buscar el servicio postgresql-xxxx, y hacer
sobre el click derecho,
propiedades.
En esta pantalla les aparecerá un conjunto de opciones para Para, Iniciar,
Reiniciar el servicio, Además
les brindara información sobre el estado del mismo.
------------
Salu2, Ulinx
"En un problema con n ecuaciones
siempre habrá al menos n+1 incógnitas"
Linux user 366775
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
