tarea 11 gestión de almacenamiento

Tarea 11: Gestión de Almacenamiento

1) Explicar la organización del almacenamiento en PostgreSQL: tamaño y estructura interna de los bloques, extensiones, archivos, grupos de archivos. Cuantos archivos a nivel de sistema operativo se crean con cada base de datos, que relación hay entre tablespace, archivos y tablas.

La data siempre se va a guardar en “disco” (esto puede no ser literalmente un HD).Esto genera un intenso trabajo de I/O, cuando leemos la data la sacamos del “disco” para pasarla a la RAM, cuando escribimos la bajamos de la RAM al “disco”.

La data en cualquier DBMS se almacena en pequeños bloques de disco llamadas “páginas”.Estás “páginas” se guardan en un disco en diferentes posiciones físicas, mucha dispersión creará una baja performance en la dbms, en sistemas de almacenamiento como los HD (osea casi el 99%) esto es un gran problema.Afortunadamente ahora existen Soluciones basadas en Discos de Estado Solido que ayudan con este problema.

El tamaño de una página en PostgreSQL puede ser tan pequeño como 8k (por defecto) hasta un máximo de 32k y no se permite que un tupla pueda ser mas grande que una página de tamaño.Cuando se necesita guardar data muy grande (un video por ejemplo) la data es comprimida y partida en pequeñas “filas” que se guardan en una tabla paralela, esto es transparente para el usuario (http://www.postgresql.org/docs/8.4/interactive/storage-toast.html).Las páginas contienen “items” los cuales apuntan a tuplas o entradas de índices junto con metadata.Para el caso de PostgreSQL las operaciones de R/W primero se consulta al Buffer Manager (memoria RAM) si contiene la página.

https://repositorio.utn.edu.ec/aulavirtual/mod/assignment/view.php?id=10176

PostgreSQL posee un solo “Storage Manager” (MySql tiene 5 o más por ejemplo), este esta compuesto por varios módulos que proveen administración de las transacciones y acceso a los objetos de la base de datos.Los módulos se programaron bajo 3 lineamientos bien claros:●Manejar transacciones sin necesidad de escribir código complejo de recuperación en caso de caídas.●Mantener versiones históricas de la data bajo el concepto de “graba una vez, lee muchas veces”.● Tomar las ventajas que ofrece el hardware especializado como multiprocesadores, memoria no volátil, etc.PostgreSQL siempre esta añadiendo data, la data modificada o borrada realmente no se modifica o se borra, las páginas donde ellas están almacenadas se marca como “no visible” y se inserta un nuevo registro completo con un clon de toda la data (como se maneja esto en detalle se explica mas adelante). Esto hace que la base de datos ocupe mucho espacio y afecta el “tiempo de acceso” a la data.Existe un “tiempo de acceso” para llegar a la data (sea read o write) que depende de:● Tiempo de búsqueda del OS en mover los brazos del disco duro.● Tiempo de rotación de los discos para que el brazo encuentre la posición física donde esta la data.● Tiempo de transferencia de R/W de la data del disco a la memoria.Hay que buscar que reducir este tiempo para que el acceso a la data sea mas rápido.

Hash: es una estructura de datos que asocia llaves o claves con valores. La operación principal que soporta de manera eficiente es la búsqueda: permite el acceso a los elementos almacenados como por ejemplo: teléfono y dirección, a partir de una clave generada (usando el nombre o número de cuenta, por ejemplo). Funciona transformando la clave con una función hash en un hash, un número que la tabla hash utiliza para localizar el valor deseado.

Extensiones:

Las extensiones que maneja postgres son:

.conf son los diferentes archivos de configuración de PostgreSQL.

Las plantillas y las bases de datos, contienen un directorio por cada base de datos, dentro hay un fichero por cada tabla o índice de una base de datos, los números corresponden a los OIDs de las tablas o índices, en el caso de haber instalado por default estará en el directorio. /opt/PostgreSQL/9.0/data/base.

Ejemplo:

/opt/PostgreSQL/9.0/data/base/11866

Archivos:

Cada archivo con su OID corresponde a una tabla o índice de la Base de Datos.

Grupos de Archivos:

Los archivos que contienen en su nombre las siglas fsm por ejemplo 11597_fsm representa

free space map: mapa de espacio libre.

Los archivos que contengan en su nombre las siglas vm por ejemplo 11856_vm representa

Vacumm memory : rutina de mantenimiento vacumm.

Relación de archivos o directorios, con la Base de Datos y Tablas.

Base de Datos.

Como antes se menciono a una Base de Datos en PostgreSQL se la distingue de las demás por su OID.

Ejemplo:

2)Configuración y tamaño de archivos temporales. ¿Para que sirven?

ARCHIVOS TEMPORALES O WAL

WAL: Write-Ahead Log

¿Qué es?

Siglas: Write Ahead Log

Es un log de escritura adelantada, también conocido como log transaccional o REDO log por otros gestores de bases de datos; en el que se graban todos los cambios efectuados a las páginas de datos antes de efectuar tales cambios. Puesto que solo este log es necesario para garantizar que los cambios permanecerán aun en el caso de caída del servidor también se reduce la cantidad de escrituras a disco aumentando así el rendimiento.

El WAL es la base para lograr respaldos incrementales, recuperación hasta un punto en el tiempo (PITR) y una técnica de alta disponibilidad conocida como Warm Standby.

WAL: Principios de diseño

El log de transacciones consiste en una serie de registros de log los cuales describen los cambios que se están realizando a la base de datos y por lo tanto debe existir un registro de log por cada cambio realizado.

El registro en el WAL de una operación siempre se escribe primero que las páginas de los datos afectados, esto asegura que los cambios permanecerán aun cuando el servidor por algún motivo dejará de funcionar abruptamente.

En caso de que el servidor tenga una caída, se reconstruyen las transacciones comprometidas (aquellas en las que se ha hecho COMMIT), y que aún no se hayan escrito en las páginas de los datos, leyendo desde el WAL

¿Qué es un registro de WAL?

Lleva los detalles de la operación a realizar (ej: que tipo de operación es, en que base de datos, en que tabla o índice en que página de disco, información de estado del snapshot de la transacción, la posición del registro de WAL anterior, etc...).

Ejemplo:

INSERT INTO foo VALUES (1234, ’foobar’);

insert: ts 1663 db 11564 rel 16389 block 0 off 2

header: t_infomask2 2 t_infomask 2050 t_hoff 24

0/004F8E14: prv 0/004F8DD0; xid 655; BTREE info 00 len 30 tot_len 58

insert_leaf: index 1663/11564/16395 tid 1/1

0/004F8E50: prv 0/004F8E14; xid 655; XACT info 00 len 24 tot_len 52

commit: 655 at 1979-10-31 18:02:49 EET

Consideraciones sobre el WAL

Si está en el WAL está seguro, es decir que podrá recuperarse de una caída del servidor sin pérdida de datos...

a menos que se dañe el disco que no vaya al disco en el orden correcto, en este caso habrá corrupción de datos.

o Esto último puede ocurrir si hemos desactivado el parámetro fsync en el postgresql.conf

o si tenemos activo el cache de escritura en el disco (entonces el disco decidirá cuando

grabar cada cosa y puede no ser el orden que esperábamos).

Cosas que no van al WAL

tablas temporales índices hash, para recuperar un índice hash después de una caída de servidor es necesario usar el

comando REINDEX.

Se escribe en disco dos veces: primero al WAL y luego a las páginas de datos, aunque no al mismo tiempo; por eso es recomendable poner el directorio del WAL en otro disco.

El WAL no se puede apagar, y aunque se pudiera no sería deseable hacer tal cosa pues se perdería la habilidad de recuperarse de caídas del servidor.

Checkpoints

El WAL crea tantos archivos como necesite, por eso a menos que se reutilicen los archivos viejos podría crecer indefinidamente.

Para evitar que lleguen a ocupar demasiado espacio en disco están los checkpoints que se encargan de sincronizar los cambios registrados en el WAL a las páginas de disco de las tablas e índices.

Un checkpoint realiza las siguientes operaciones:

1. Sincroniza todos los cambios en las páginas de datos al disco2. Escribe en WAL un registro de checkpoint3. Borra los WAL viejos

Un checkpoint en modo de recuperación, es decir el que se ejecuta al iniciar el servidor, realiza lo siguiente:

1. Determina el punto de inicio de recuperación en el WAL es decir, qué transacciones que están comprometidas aún no se han sincronizado a las páginas de los datos

o pg_control

2. Sincroniza todos los cambios en las páginas de datos al disco3. Escribe en WAL un registro de checkpoint4. Borra los WAL viejos

Estructura del WAL

El WAL está dividido en segmentos. Cada segmento es un archivo en el directorio $PGDATA/pg_xlog, generalmente de 16MB cada uno (configurable en tiempo de compilación).

$ ls -l

total 131236

-rw------- 1 postgres postgres 16777216 nov 18 21:09 000000010000000000000041








drwx--S--- 2 postgres postgres 4096 nov 9 17:08 archive_status

Nombres de los archivos del WAL

El nombre de los segmentos del WAL consta de 3 partes:

Usemos el siguiente nombre de un segmento de WAL para nuestro ejemplo:

000000010000000000000048

1. Los primeros 8 dígitos (contando de izquierda a derecha), indican el id de la línea de tiempo del registro.

o El id de la línea de tiempo se usa para distinguir segmentos de WAL generados antes y

2. después de una recuperación PITR.3. Los siguientes 8 dígitos (contando de izquierda a derecha), indican el id del log4. Los últimos 8 dígitos (contando de izquierda a derecha), indican el id (secuencial) del segmento

Los últimos 16 dígitos en conjunto conforman la primera parte del LSN.

Detectando el final del WAL

¿Cómo se determina donde termina el WAL, de forma que no se intente sincronizar basura? Cada registro tiene un puntero que apunta al registro anterior en la cadena si no coinciden, hemos llegado al final del WAL.

CONFIGURACION WAL

Nota: Las configuración se realizan en el archivo postgresql.conf

Write Ahead Log

fsync = on determina si PostgreSQL debe forzar al SO a escribir en disco, jamas se debe apagar

synchronous_commit = on

wal_sync_method = fsync Método que usa el gestor WAL para forzar la escritura de los buffers en disco. Posibles valores: fsync, fdatasunc, open_sync, open_datasync, fsync_writethrough (de forma predeterminada usa el primero soportado por el SO)

full_pages_writes = on Establece si se copia el bloque entero al diario después de la primera modificación que sufra o no, después de un punto de verificación (por defecto está a on, para evitar problemas de corrupción de bloques).

wal_buffers = 64kB cantidad de buffers para los diarios que forman la cache de la WAL

wal_writer_delay = 200ms

commit_delay = 0 Tiempo en microsegundos que espera el servidor para llevar las entradas del buffer de diario a los diarios después de que una transacción se confirme. Permite que otros procesos puedan aprovechar esta operación, es decir, que se haga un solo commit para varias transacciones.

commit_siblings = 5 no mínimo de transacciones activas que debe de haber para que el gestor WAL se espere el tiempo indicado en commit_delay

Archivado del WAL

archive_mode = off

archive_command = instrucción del SO que se debe ejecutar para archivar un segmento completado del WAL. Por ejemplo: ‘cp %p /mnt/archivedir/%f’ donde %p es el camino completo al fichero y %f el nombre

archive_timeout = 0 Fuerza el archivado pasado este tiempo

Configuración del log

log_destination = 'stderr' existen varios métodos para emitir los mensajes del servidor (stderr, csvlog, syslog y eventlog)

logging_collector = on permite enviar los errores enviados a stderr a los ficheros de seguimiento

log_directory = 'pg_log' si el parámetro anterior está habilitado determina el directorio donde se crean los ficheros de seguimiento

log_filename = 'postgresql-%Y-%m-%d_

%H%M%S.log'

nombre de los ficheros de seguimiento

log_truncate_on_rotation = off establece la rotación de ficheros, aunque se pueden usar alternativas

log_rotation_age = 1d si redirect_stderr = on establece la duración máxima de cada fichero de seguimiento, con 0 deshabilita esta opción

log_rotation_size = 10MB tamaño de los ficheros rotados

syslog_facility = 'LOCAL0' si el seguimiento lo hace syslog, aquí se determina qué utilidad se usa

syslog_ident = 'postgres' Si se usa syslog este es el nombre del programa utilizado para identificar los mensajes de PostgreSQL.

silent_mode = off la salida estándar y los errores se envían a /dev/null

client_min_messages = notice establece el nivel de los mensajes que serán enviados a los clientes

log_min_messages = warning controla el nivel de los mensajes que son escritos en el fichero de seguimiento

log_error_verbosity = default controla el detalle de la información que se escribe en el fichero de seguimiento (terse, default, verbose), cada nivel añade más campos

log_min_error_statement = error Controla si la instrucción SQL que ha provocado el error debe ser recordada o no el el fichero de seguimiento.

log_min_duration_statement = -1 Registra las instrucciones y su duración si su ejecución tarda más que el indicado aquí. Con 0 registra todas y con -1 ninguna

debug_print_parse = off configuran el servidor para que registre de cada consulta información de su ejecución

debug_print_rewritten = off

debug_print_plan = off

debug_pretty_print = off

log_checkpoints = off

log_connections = off información detallada de cada conexión

log_disconnections = off información detallada de cada desconexión

log_duration = off registra la duración de cada instrucción que va a ser registrada

log_hostname = off con esta opción, aparte de la IP, se registra también el nombre del host desde donde se establece la conexión

log_line_prefix = '' Escribe una cadena antes de cada línea de informe.

log_lock_waits = off Muestra las esperas de bloqueos mayores o igual a deadlock_timeout

log_statement = 'none' controla qué instrucciones son registradas (none, ddl, mod y all)

log_temp_files = -1 Se indica el tamaño en kB. -1 es desactivado y 0 muestra todos.

log_timezone = unknown

Nota: Información adicional se encuentra en Segundo tema el archivo Afinamiento de Base de Datos.

3) Como hacer monitoreo de: número de extensiones, fragmentación de dispositivos, espacio libre disponible, tamaño de segmentos y particiones, tablas e índices por segmento, cantidad de espacio asignado que no está siendo utilizado, objetos no utilizados que deben ser borrados, etc.

Fuente de Información.

Extensiones:

Fragmentación de Dispositivos:

Para verificar la fragmentación en Linux se utilizara la herramienta shake:

Instalación:

yum install shake

Análisis del disco:

fsck -nvf /dev/sda1 (sda1 puede cambiar según el disco a verificar)

Análisis de fragmentación con shake para SSOO Centos:

shake --pretend --verbose --verbose /dev/sda1

Desfragmentación del disco:

shake /dev/sda1

Nota: esto no es necesario ya que los sistema de archivos de Linux (ext3, ext4) realmente no sufren problemas se fragmentación, esta es una gran ventaja sobre los sistemas de archivos de Windows.

Espacio libre Disponible

El comando iostat permite monitorear la actividad de los dispositivos, particiones y sistemas en red (NFS) del sistema, además también muestra una media en% del uso de CPU en la máquina.

La primera vez muestra información promediada desde la última vez que se reinicio el sistema.

Tamaño de Particiones

Análisis de todo el disco:

df -h | grep / | awk '{ print $1 " " $2 " " $3 }'

Tamaño de Segmentos:

El tamaño de segmentos en Postgresql es de 1 GB y el tamaño de bloque es de 8kb.

Fuente bibliográfica documentación oficial de PostgreSQL Capítulo 28 versión 9.0

http://www.postgresql.org/

Tamaño de espacio asignado

Como ya se refirió antes en postgres no permite asignar tamaño a una tabla o Base de Datos.

Borrado de Objetos no Utilizados.

En Postgres, los DELETE y UPDATE no sobrescriben el registro modificado Más bien, crean uno nuevo y marcan el anterior como obsoleto.

Esto permite que alguien que estaba leyendo antes del DELETE pueda todavía ver el registro antiguo y saltarse el nuevo

Un lector nuevo puede saltarse el antiguo y leer el nuevo.

Una vez que todos los lectores “antiguos” terminan, el registro viejo ya no es necesario hay que eliminarlo para reutilizar el espacio a este modelo se le llama MVCC.

http://www.postgresql.org/

Hay otras implementaciones posibles por ejemplo en Oracle: “rollback segment” la de postgres es mejor porque no exige que los backend tengan que hacer trabajo extra este trabajo extra lo hace un proceso aparte que no causa retardo para los clientes

VACUUM es la implementación del “recolector de basura”

Hay dos formas de VACUUM.

lazy vacuum vacuum full

Lazy vacuum

Características:

Se realiza por página por página.

No requiere bloquear la tabla.

INSERT, UPDATE, DELETE pueden continuar operando concurrentemente.

El algoritmo de LAZY VACUUM

En cada página: Elimina registros obsoletos Compacta el espacio disponible Registra cuánto espacio libre hay en esa página en el FSM Lleva en memoria las direcciones de las tuplas que se eliminaron

Limpieza de índices: recorrer todos y cada uno de los índices de la tabla Para cada tupla:

Examinar si está en la lista de tuplas eliminadas En caso de estar, se elimina

Esto ocurre cada vez que al algoritmo de limpieza de páginas se le acaba el espacio de memoria para llevar la lista de tuplas eliminadas

Variable de configuración maintenance_work_mem

Free Space Map

El espacio libre en cada página de la tabla se guarda en el FSM Cuando un INSERT necesita registrar una nueva tupla, pregunta al FSM dónde ponerla Si el FSM no tiene información, se extiende la tabla Problema típico: el FSM queda chico Si una página no cabe en el FSM, se “olvida” INSERT necesita extender la tabla aún cuando puede quedar mucho espacio libre todavía (pero

el FSM nolo sabe) I max_fsm_pages, max_fsm_relations

VACUUM FULL

Forma más antigua de VACUUM Requiere bloquear totalmente la tabla No deja ningún espacio libre en las páginas Operación posterior necesita extender la tabla Desventajas

Los índices quedan en mal estado Es muy lento No es muy recomendable, salvo casos de extrema desesperación Por ejemplo, cuando uno ha estado usando la BD mucho tiempo con el FSM mal configurado

4) Indicar los niveles de RAID que soporta la DBMS y sus requisitos para implementarlos.

Niveles de RAID soportados:

RAID level 0 RAID level 1: RAID level 5: RAID level 1+0, 5+0 RAID level 0+1, 0+5

Referencia: http://wiki.postgresql.org/wiki/Community_Disk_Tuning_Guide

Consideraciones sobre el Sistema de Discos

Puesto que el sistema de discos es la parte más lenta de todo sistema, se recomienda los siguientes puntos al configurar el servidor.

• Configuración RAIDo En la comunidad se ha recomendado el nivel 10

• Apagar cache de escritura o usar battery backed array controllers

• Distribución de los discoso Poner el WAL ($PGDATADIR/pg_xlog) en un disco aparte

o Si es posible; disponer de discos separados para poner los datos, índices y archivos

temporales.

5) Herramientas de terceros para gestión de almacenamiento.

No existe ninguna herramienta libre que facilite el monitoreo hasta el momento de realizar esta práctica.

http://wiki.postgresql.org/wiki/Community_Disk_Tuning_Guide

tarea 11 gestión de almacenamiento

Documents