Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porPurificación Robles Ortiz Modificado hace 9 años
1
Utilización de memoria del O3 Server Caché de cubos
2
Idea: aprovechar información del cubo (hechos y dimensiones) que queda en memoria No es como la redundancia en cuanto a que el resultado se ve en la segunda consulta Controla qué cubos permanecen abiertos (pero sin conexiones) y cuáles se sacan de la caché si es necesario. Se utilizan 4 parámetros: máxima cantidad de cubos en caché (admserver) tamaño de la caché (en bloques de 4096 bytes) en gserver.properties: ideasoft.o3.pool.totalMaxCache (en bloques, por defecto 25000) máx y mín caché del cubo (en bloques, definido en el Designer ó Admserver) ›Valores por defecto MAX=2000, MIN=1000
3
Estrategia se mantienen cubos en memoria mientras la suma de las min caché sea inferior al máximo si no alcanza y hay cubos sin conexiones, entonces éstos se cierran y se recalcula la caché disponible. si no alcanza y no hay cubos sin conexiones, entonces no se permite abrir el cubo y se da aviso max caché es utilizado para distribuir la memoria disponible entre los cubos abiertos. El criterio utilizado para esta distribución es que mayor máximo significa más memoria con respecto a los otros cubos abiertos
4
Abriendo cubos al iniciar el Servidor Idea: definir qué cubos se abren cuando inicia el servidor El propósito es que cuando el primer usuario se conecte a cualquiera de esos cubos, el proceso de carga inicial ya fue hecho, por lo cual la consulta inicial es más rápida. Prioridades: Ninguna…. Muy Alta Se utilizan en el caso de que la capacidad de caché no sea suficiente
5
Redundancia Posibles pasos para optimizar un cubo con redundancia Optimizar el cubo a nivel de diseño para bajar todo lo posible tiempos construcción (ver recomendaciones básicas diseño) Construir el cubo solo con redundancia top most Agregar niveles de redundancia bajos subiendo un nivel en las dimensiones conocidas pesadas (Ej. [1,0,0,0,1,0,0…]) ›saber qué tipos de consultas se hacen ›dimensión fecha es gran candidata siempre (nivel mes o trimestre) En cada caso comprobar con RedunMgr si hay mejora Si se necesita mucho tiempo de pruebas entonces hacer un cubo representativo mas pequeño Una vez que el cubo entra en producción, usar datos estadísticos para analizar tiempos de consultas
6
Recomendaciones básicas de diseño Evitar doble recorrida tabla de hechos no crear dimensiones a partir de tablas de hechos, usar catálogos. (modelo estrella, snowflake) crear dimensión fecha con un catálogo y no desde la tabla de hechos (dos formas: catálogo con un día por cada año o campo virtual y append) Almacenamiento optimizado de medidas y dimensiones utilizar el soporte de datos adecuado, byte, short, int, double Partir el cubo en varios
7
Parámetros de redundancia Momento de la construcción de la redundancia Al momento de construir el cubo ›Mejor si hay poca agregación a nivel base Al final ›Se debe levantar todo el cubo
8
Optimizacion de JBoss Memoria Cache de cubos Apertura de cubos al levantar Optimización de los cubos: Redundancia Los cubos deben funcionar bien standalone Para monitorear performance: Monitoreo memoria Jboss Monitoreo de O3Server: sessiones abiertas Monitoreo de cubos: análisis de cubos de monitoreo -stats -debug
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.