Monitoreo y entonacion de PostgreSql

1. Monitoreo y Tunning
Ing. Lennin Caro Pérez

3. Pasos para entonar...
Probar
Documentar
Entonar

4. Hardware... el primer punto
Componentes básicos
Procesador
Memoria RAM
Disco – E/S
Red
Cada equipo es diferente
Auque esten configurados igual, son diferentes
Para cada de base de datos existe un equipo
OLTP
OLAP
Web

5. Procesador
Hoy en día las aplicaciones están relacionadas
con los procesadores
Cualquier actividad genera E/S hasta la escritura en disco
Cuantos nucleos necesito para ejecutar consultas
PostgreSQL es multi-procesador
Cada núcleo solo puede procesar una consulta a la vez
Lo mejor es realizar maximo dos consultas por nucleo
Si puedes aumentar la cantidad de procesadores ...
Hazlo
No tienes que pagar licencias por procesadores adicionales

6. Tips del Procesador
Procesador
Los multiprocesadores simétricos no son perfectos
En ocasiones es mejor tener mas procesadores con
menos núcleos
Características de los procesadores
Velocidad
Los que tienen mas memoria L2 son mejores
Los de 64 bit pueden mejorar considerablemente el
rendimiento
Especialmente cuando se use mas de 4 Gb de RAM
Pero no siempre es la solución al bajo rendimiento

7. Memoria RAM
Usar la memoria necesaria es un caso de ensayo
y error
Mientras estes cerca (1% de diferencia) de la cantidad de
memoria que necesitas tu servidor sera rapido.
Estar mas alla del 2% de lo necesario bajaria el rendimiento
Limites mas críticos
Tienes la RAM suficiente para mantener en share_buffers la
base de datos
Aproximadamente 6 veces el tamaño de la base de datos
Tienes la RAM suficiente para mantener la base de datos en
el cache
Aproximadamente de 2 a 3 veces el tamaño en disco de la
base de datos

8. E/S el cuello de botella
Cual es el límite de E/S de tu base de datos
Alto volumen de escrituras
Escritura del log por cada transacción
Base de datos mas grandes que la RAM (aprox. 3 veces)
Cada consulta sera afectada por el límite de E/S
Optimiza la E/S
Si la base de datos es muy grande, invierte en discos
Calcula cuánto tarda en escribir en disco un bloque de datos
Calcula cuánto tarda en leer toda la base de datos desde el
disco
Revisa cuantos log de transacciones se generan

9. El camino del hardware

10. La Red
Posibles cuellos de botella
Tiempo de respuesta
Ancho de banda
Switches mal configurados u obsoletos
Conexiones dedicadas
Entre el aplicativo y el servidor de BD
Entre el servidor de BD y el de replica o de recuperación de
desastres
Varias interfaces de conexion
Transferencias de archivos
Conexiones Gigabits o Megabits
Calcular la capacidad de transferencia para la copia de la
data, los dumps, los logs y los WAL

11. Prueba tu HW
Herramientas para comprobar tu HW
Procesador: PassMark, sysbench, Spec CPU
Memroia RAM: memtest, cachebench, Stream
E/S: bonnie++, dd, iozone
Red: bwping, netperf
Base de datos: pgBench, sysbench
Prueba el HW antes de montar tu BD
Prueba y compara antes de comprar
Involucra a tus administradores de sistemas en la toma de
decisión
No creas en todo lo que te venden
Prueba nuevamente
Y por ultimo prueba de nuevo y compara

12. Mitos...
Todos los discos son iguales
Asi sean de la misma marca y hasta el mismo modelo
Todos las tarjetas de RAID son iguales
Todos los sistemas operativos son iguales
Asi sean la misma versión y tipo
Una pieza mal configurada o en mal estado no
puede inutilizar tu sistema
Las estadísticas te van a decir todo
Los vendedores siempre dicen la verdad
No existe un lugar donde te puedan ayudar con tu
manejador de base de datos PostgreSQL
No busques la combinación correcta, comprala

13. Y el Sistema Operativo.....
Sistemas operativos recomendados
Free BSD
GNU/Linux (Debian)
Red Hat
Solaris
Unix
Metodos de sync para los sistemas operativos
Platform open_datasync fdatasync fsync_writethrough fsync open_sync
Linux No Sí No Sí Directo
Mac OS X/Darwin No No Sí Sí Sí (Directo?)
Solaris Sí Sí No Sí Yes
BSD/OS No No No Sí Sí (Directo?)
FreeBSD No No No Sí Sí (Directo?)

14. Separa el log de transacciones
Directorio de pg_xlog
Tener un arreglo de disco puede mejorar el rendimiento entre
un 10% y 50%
Tablespaces en discos distintos
Para tablespace que contengan tablas muy grandes
Para tablespace que contengan tablas particionadas
Para tablespace que tengan indices grandes
Para tablespace que tengan indices paticionados
Tablespace diferente para las tablas que tengán más
transacciones que otras.
Tablespace diferente para las tablas que sean más grandes
que otras.

15. Entonación en GNU/Linux
Sistema de Archivos
XFS para base de datos grandes
Raiser para base de datos pequeñas
Etx2
No es seguro cuando sucede una caida
Etx3
Mas lenta que ext2 pero mas segura ya que tiene Journalling
Etx4
Presenta un bug con el fsync
NFS o cualquier sistema de archivos remoto
No tiene el mismo archivo manejo semántico del sistema de
archivos local, y pueden causar problemas de fiabilidad de los datos
o la recuperación de fallas

16. Sistema Operativo
Modifica los valores de tu kernel en el sistema operativo
Shmmax y shmall
Verifica la versión del kernel para mejorar el rendimiento
Versión superior a 2.6
Verifica las opciones de los puntos de montura
data = writeback, noatime, nodiratime
Ubica los puntos de monturas PM en diferentes discos o
arreglos
Crea la base de datos en un PM diferente
Crea enlaces simbolicos para colocar las tablas en PM diferentes
Crea enlaces simbolicos para ubicar los índices
Mueve las tablas que realicen mucho en JOIN a PM diferentes
Coloca los WAL en un PM diferente

17. Monitoreo
Monitorea pro-activamente
Conoce el rendimiento de tu equipo antes de que sea crítico
Planifica tus alertas
Más alla del 80% es problemático
Monitorea todo
Uso de los procesadores (y sus cores)
Discos que mas escriben
Discos que mas se leen
Uso de la memoria
Horas picos o de alto impacto para el servidor
Usa las herramientas que quieras
nagios, cacti, reconnitor, Hyperic, OpenNMS

18. Entonación de PostgreSQL
shared_buffers
Usa una pequeña parte de la memoria
Cuanto se usa de la memoria
Entre el 15% y el 25% en servidores dedicados
Calcular acierto del buffer en PostgreSQL 9 “EXPLAIN (ANALYZE
ON, BUFFERS ON) SELECT ...“
Calcular acierto del buffer en versiones anteriores “select
datname, blks_read, blks_hit from pg_stat_database;”
work_mem
Para consultas de ordenamiento, tipo hash entre otras
Entre 32 MB y 64 MB
Detecta una mala configuración
Muchos SWAP: el parametro esta muy alto
Archivos temporales de log: parametro muy bajo

19. Entonación de PostgreSQL
maintenance_work_mem
Usada para los bulks de carga de datos, vacuum, entre otros
Entre 256 MB y 1 GB
Usada para la creación de indices
Permite que el vacuum sea más rapido
Pero cuidado si se estan ejecutando multiples vacuum
wal_buffers
Es la memoria usada por el WAL (Write Ahead Log)
8 MB para los SMP

20. Transacciones
effective_io_concurrency
Solo si el sistema operativo soporta E/S asincronas
Número de discos/canales
synchronous_commit
La velocidad es más importante que la integridad
Coloca el parametro synchronous_commit = off
Puedes perder data en un apagado abrupto del sistema
checkpoint_segment
Cuantos segmentos de log de 8MB se crean antes del
proximo checkpoint
Usa 16, 64, 128 (es cuestion de probar)

21. Consultas
effective_cache_size
Estimado de la memoria disponible para guardar en
shared_buffers y cache del sistema de archivo
2/3 del total de RAM
default_statistics_target
Aumenta entre 200 a 1000 para base de datos grandes
El valor por omisión es de 100
Actualizar las estadísticas pr columnas es mejor
log_statement
Si quieres saber que consultas se ejcutan y el tiempo que
tardan.
log_statement=all
Esto genera una carga adicional de escritura en el log

22. Mantenimientos
Autovacuum
Activalo para aplicaciones con base de datos OLTP
No es recomendable para base de datos OLAP
Asegurate de incluir la opción analyze
Para versiones de 8.2 y menores usar esta configuración:
stats_start_collector = on
stats_block_level = on
stats_row_level = on
Autovacuum = on
Para monitorear los autovacuum
SELECt schemaname, relname, last_autovacuum,
last_autoanalyze FROM pg_stat_all_tables;

23. Mantenimientos
Verificar los disparadores de Autovacuum
Para verificar cuando se ejcutara el autovacuum y cuando se
ejecutó existen un grupo de consultas:
SELECT max(age(datfrozenxid)) FROM pg_database;
SELECT datname,age(datfrozenxid) from pg_database ORDER BY
age(datfrozenxid) DESC;
SELECT relname, age(relfrozenxid) FROM pg_class WHERE
relkind = 'r' ORDE BY age(relfrozenxid) DESC;

24. Mantenimientos
Vacuum
Puedes ejecutar Vacuum manualmente sobre tablas que
tengan un gran número de inserciones o actualizaciones
Si no se mantiene un Vacuum continuo el planner de
consultas puede tomar un camino equivocado
Existen varios tipos de Vacuum
Full: Para obtener mas espacio pero toma mucho mas tiempo
Freeze: Es más agresivo contra las tuplas ya que buscas las que
tengan datos “Freezing”
Verbose: Muestra el detalle de las acciones realizadas
Analyze: Actualiza las estadísticas usadas por el planner para
determinar el mejor camino

25. Recomendaciones
Diseño de los esquemas
No optimice prematuramente
Analiza cuales tablas tendrán mayor volumen de inserciones,
consultas o actualizaciones
Existe una gran variedad de tipos de datos, elige la que mejor
responda a la necesidad
Los tipos de datos BLOB son muy lento, usalos con cuidado
Indices
Indexa las llaves foranes
Indexa los criterios mas comunes para los WHERE
Indexa los criterios agreagados (expresiones)
Verifica los demás metodos de indexación (expressions, full
text, partial) y busca el más adecuado para tu necesidad

26. Recomendaciones
No indexes todo
Los indices significan mayor carga al realizar las inserciones,
el borrado y las actualizaciones
Demasiados indices en la misma tabla pueden ocasionar
problemas al planner
Las tablas pequeñas no necesitan indices, revisa su
cardinalidad
Verifica los indices actuales y cuales se estan usando
Usa el catálogo pg_stat_user_indexes
Verifica las tablas que son hacen SEQUENCIAL SCAN y
hacer muchas actualizaciones y borrados de datos
Usa el catálogo pg_stat_user_tables

27. Recomendaciones
Particiones
Particiona las tablas que son muy grandes
Ubica el campo candidato para realizar la partición
Si tienes muchas consultas donde un campo tiene poca
cardinalidad (valores Sí/No) y este es usado constantemente en el
WHERE particiona la tabla o usa indices particionados
Consultas
Prueba usar NOT IN o NOT EXISTS para consultas lentas
Optimiza para consultas en cache
Aumenta o disminuye el valor de seq_page_cost y
random_page_cost en una sesion de trabajo y verifica el resultado
Deshabilita las opciones de optiomización
En raras ocasiones el planner se equivoca, pero no cuesta nada
probar

28. Recomendaciones
Explain Analize
Verifica como se resuelven tus consultas
Verifica si existe un conteo de registros equivocado
Verifica los sequencial scan que se realizan
Verifica si existe un conteo alto de loops
Trata de re-excribir las consulta con un mal plan de ejecución

29. Optimización de consultas
Revisa pg_stat_statement
Aplica las Ejecuta Explain
Analize en las
correciones
consultas
lentas
Modifica las
consultas lentas o
loas parametros

30. Optimización de procedimientos
Revisa pg_stat_function
Ubica los
Aplica las
procedimientos
correciones mas lentos
Localiza las
operaciones lentas

31. Los catálogos
Nombre del Catalogo Proposito
pg_aggregate funciones de agregado
pg_am índice de acceso a métodos
pg_amop los operadores del método de acceso
pg_amproc procedimientos de acceso método de apoyo
pg_attrdef valores de las columnas por defecto
pg_attribute columnas de la tabla (los "atributos")
pg_authid identificadores de autorización (roles)
pg_auth_members autorización de las relaciones de identificación de miembro
pg_cast moldes (conversiones de tipos de datos)
pg_class tablas, índices, secuencias, vistas ("relaciones")
restricciones de comprobación, restricciones únicas, restricciones de
pg_constraint
clave principal, las claves foráneas
pg_collation colaciones (información local)
pg_conversion conversión de codificación de la información
pg_database bases de datos dentro de este cluster de base de datos
pg_db_role_setting por función y por base de datos configuración
pg_default_acl privilegios por defecto para los tipos de objetos
pg_depend dependencias entre los objetos de base de datos
pg_description descripciones o comentarios sobre los objetos de base de datos
pg_enum enumeración de etiquetas y definiciones de valores
pg_extension extensiones instaladas
pg_foreign_data_wrapper extranjeros-los datos de definiciones de envoltura
pg_foreign_server las definiciones de servidor extranjero

32. Nombre del Catalogo Proposito
pg_foreign_table información adicional tabla externa
pg_index información adicional de índices
pg_inherits tabla de jerarquía de herencia
pg_language idiomas para la escritura de funciones
pg_largeobject páginas de datos de objetos de gran tamaño
pg_largeobject_metadata metadatos para objetos de gran tamaño
pg_namespace esquemas
pg_opclass acceder a las clases método del operador
pg_operator los operadores
pg_opfamily acceso de las familias método del operador
pg_pltemplate datos de la plantilla de las lenguas de procedimiento
pg_proc funciones y procedimientos
pg_rewrite reglas de consulta escribir
pg_seclabel etiquetas de seguridad en los objetos de base de datos
pg_shdepend las dependencias de objetos compartidos
pg_shdescription comentarios sobre los objetos compartidos
pg_statistic estadísticas de planificador
pg_tablespace espacios de tablas dentro de este grupo de base de datos
pg_trigger desencadenantes
pg_ts_config configuraciones de búsqueda de texto
pg_ts_config_map asignaciones de las configuraciones de búsqueda de texto 'token
pg_ts_dict diccionarios de búsqueda de texto
pg_ts_parser analizadores de búsqueda de texto
pg_ts_template plantillas de texto de búsqueda
pg_type los tipos de datos
pg_user_mapping asignaciones de usuarios a los servidores extranjeros

33. Preguntas
Contacto:
lennin.caro@yahoo.com
@lennincaro
+58 412-5826767
Enlaces
http://www.postgresql.org/docs/
PostgreSQL en español
http://archives.postgresql.org/pgsql-es-ayuda/
PostgreSQL Performance
http://archives.postgresql.org/pgsql-performance/
Esta charla es Copyleft 2011 Lennin Caro Pérez, y esta bajo los
atributos de la licencia creative commons

34. Muchas gracias...