T41.2: Configures Namespaces, Databases, Memory

Tipos de Mapeo y Casos de Uso

Mapeos de Globals: Permiten que múltiples namespaces compartan datos mapeando globals a bases de datos distintas de la predeterminada del namespace. Puede mapear globals completos o rangos específicos de subscripts. Ejemplo: `^Orders(2020):(2023)` mapea los años 2020-2022 (límite superior exclusivo) a una base de datos ARCHIVE mientras que los datos actuales permanecen en producción.

Usos comunes: Datos de configuración compartidos, datos de referencia multi-tenant, particionamiento de datos por fecha/región.

Mapeos de Routines: Comparte routines ObjectScript individuales (MAC/INT/INC) entre namespaces sin duplicación. Debe mapear las dependencias: si una routine usa macros $$$, los archivos include también deben estar mapeados.

Usos comunes: Routines de utilidad compartidas, lógica de negocio centralizada, acceso a routines del sistema.

Mapeos de Packages (Recomendado para Clases): Hace que packages ObjectScript completos sean visibles entre namespaces. Jerárquico - mapear `MyApp` proporciona acceso a todas las clases `MyApp.*` y sub-packages. Los packages del sistema (%Library, %SYS) se mapean automáticamente a todos los namespaces.

Usos comunes: Bibliotecas de clases compartidas, componentes de framework, acceso a packages del sistema.

Configuración y Mantenimiento

Creación de Mapeos:

• Mediante Management Portal: Navegar a la configuración del namespace, seleccionar la pestaña de mapeo apropiada (Global/Routine/Package), agregar mapeo con base de datos destino
• Programáticamente: Usar las clases Config.MapGlobals, Config.MapRoutines o Config.MapPackages en ObjectScript

Gestión de Mapeos:

• Los mapeos tienen efecto inmediato (no se requiere reinicio)
• Se puede ver, modificar o eliminar a través del Management Portal o clases Config.*
• Almacenados en el archivo de configuración iris.cpf

Reglas Importantes:

• El contenido mapeado oculta el contenido local con el mismo nombre
• El mapeo más específico tiene precedencia cuando ocurren solapamientos
• Los mapeos remotos (ECP) agregan latencia de red a los tiempos de acceso
• Las dependencias deben mapearse juntas (routines con sus archivos INC, etc.)

Fundamentos de Archivos de Base de Datos

Las bases de datos de InterSystems IRIS se almacenan en archivos IRIS.DAT que se expanden dinámicamente según sea necesario, asumiendo que hay espacio libre en disco disponible. Durante la creación de la base de datos, los administradores especifican el tamaño inicial en megabytes. El tamaño inicial predeterminado es 1 MB, pero los administradores deben dimensionar las bases de datos apropiadamente para los volúmenes de datos esperados. Las bases de datos pueden crecer hasta 32 terabytes cuando se usa el tamaño de bloque predeterminado de 8KB.

Parámetros de Expansión

• Parámetro de expansión: Determina cuánto agregar cuando se necesita crecimiento. El predeterminado de 0 indica cálculo automático como 12% del tamaño actual o 10 MB, el que sea mayor. Cuando se usa el cálculo del 12%, el tamaño de expansión tiene un límite de 1GB.
• Parámetro máximo: Especifica el tamaño máximo que puede alcanzar la base de datos. El predeterminado de 0 indica sin máximo. Los administradores deben establecer máximos apropiados para evitar que las bases de datos consuman todo el espacio disponible en disco.

Consideraciones de Configuración de Base de Datos

• Mantener tamaños de base de datos manejables basados en la infraestructura disponible para backup, restauración y verificaciones de integridad
• InterSystems IRIS soporta bases de datos multivolumen para distribuir datos entre múltiples archivos IRIS.DAT cuando sea necesario
• Los globals de stream deben mapearse globalmente a bases de datos separadas configuradas con tamaños de bloque de 64KB para rendimiento óptimo
• Los administradores pueden modificar tamaños de base de datos a través del Management Portal sin reiniciar IRIS
• El portal advierte a los administradores cuando un tamaño especificado está dentro del 90% del espacio disponible en disco y requiere confirmación

Límites de Base de Datos

• Límite absoluto: 15,998 bases de datos por instancia (los límites prácticos son menores)
• La información de directorio no puede exceder 256KB: máximo_BDs = 258048/(longitud_promedio_ruta_BD + 3)
• Las bases de datos con mirror cuentan dos veces hacia el límite, limitando efectivamente el conteo de bases de datos con mirror a 7,499
• Las restricciones del sistema operativo en archivos abiertos también limitan las bases de datos activas simultáneas

Resumen

La asignación de memoria es una de las tareas de configuración más críticas después de instalar InterSystems IRIS. El sistema predetermina a asignación automática del 25% de la memoria física total para el database cache, pero esto está explícitamente documentado como no apropiado para uso en producción. Los administradores deben configurar manualmente las asignaciones de memoria antes de desplegar a producción o realizar pruebas de rendimiento.

La configuración de memoria se gestiona a través de la página Memory and Startup en System Administration > Configuration > System Configuration > Memory and Startup.

Database Cache (Global Buffer Pool)

• Memoria del sistema asignada para buffering de datos recuperados de bases de datos físicas
• Reduce operaciones costosas de I/O y proporciona gran parte de los beneficios de rendimiento de IRIS
• Para sistemas de producción, seleccionar "Specify Amount" en lugar de "Automatically" e ingresar una asignación apropiada en megabytes
• Si múltiples tamaños de bloque están habilitados a través de la configuración DBSizesAllowed, asignar memoria para cada tamaño de bloque habilitado por separado
• El número de global buffers creados para cada tamaño de bloque es igual a la asignación dividida por el tamaño del bloque
• Para sistemas ECP, asignar al menos 50MB de buffers de 8KB para estructuras de control ECP

Routine Cache

• Almacena routines compiladas en memoria
• La configuración "Automatic" predeterminada asigna 10% del database cache para el tamaño de buffer de 8KB predeterminado
• Mínimo: 80MB; Máximo: 1020MB
• Para instancias de producción típicas con database caches dimensionados apropiadamente, la asignación automática de routine cache es suficiente

Shared Memory Heap (gmheap)

• Proporciona memoria para operaciones IRIS distintas de cachés de routine y base de datos
• Configurado en la página Advanced Memory en System Administration > Configuration > Additional Settings > Advanced Memory
• Aplicaciones que usan muchas consultas SQL o habilitan dejournaling paralelo requieren asignación adicional de gmheap
• Monitorear uso a través de la página Shared Memory Heap Usage en System Operation > System Usage

Memoria por Proceso (bbsiz)

• Especifica la memoria máxima asignable a un nuevo proceso IRIS
• Rango permitido: 256KB a 2,147,483,647KB
• InterSystems recomienda establecer en -1 (resuelve al valor máximo) para la mayoría de las circunstancias
• Usado para tablas de símbolos, estructuras y buffers de dispositivos I/O
• Asignado en extensiones crecientes según se requiera hasta que se alcance el máximo
• Si los procesos reciben errores , aumentar este valor y reiniciar el proceso afectado

Propósito de la Tabla de Locks

La tabla de locks en InterSystems IRIS gestiona locks que controlan el acceso concurrente a recursos. Cuando múltiples procesos necesitan acceso coordinado a datos, IRIS usa la tabla de locks para rastrear qué procesos mantienen locks y cuáles están esperando.

Consideraciones de Dimensionamiento

• El tamaño de la tabla de locks determina cuántos locks concurrentes puede mantener el sistema
• Si las aplicaciones solicitan más locks de los que la tabla puede contener, las operaciones pueden fallar o bloquearse inesperadamente
• Dimensionar basado en la carga de trabajo concurrente esperada y los patrones de bloqueo de las aplicaciones
• Aplicaciones que usan bloqueo de grano fino (muchos locks pequeños) requieren tablas de locks más grandes que aplicaciones que usan bloqueo de grano grueso (menos locks más grandes)

Métodos de Configuración

La configuración de la tabla de locks típicamente se realiza a través de:

• Archivo de configuración CPF
• Configuraciones del Management Portal para parámetros avanzados del sistema

Monitoreo

Monitorear el uso de la tabla de locks ayuda a los administradores a determinar si la asignación actual es suficiente o si se necesita ajuste.

Signos de Agotamiento de la Tabla de Locks

• Timeouts de lock inesperados
• Procesos bloqueados
• Rendimiento degradado de aplicaciones durante operaciones concurrentes

Resumen de Journaling

El journaling es una característica crítica en InterSystems IRIS que registra todos los cambios realizados a bases de datos en archivos de journal secuenciales.

Propiedad Journal de Base de Datos

Cada base de datos tiene una propiedad de journaling que determina si los cambios a esa base de datos se registran en journal. Al crear o editar bases de datos a través del Management Portal, los administradores pueden establecer la propiedad "Journal globals?" a Yes o No.

Impacto del Estado de Journaling

• Bases de datos con journaling habilitado: Proporcionan la capacidad de restaurar a cualquier punto en el tiempo y replay de transacciones después de fallos, pero incurren en el overhead de escribir cambios a archivos de journal.
• Bases de datos sin journaling: No pueden recuperarse a puntos específicos en el tiempo si ocurre corrupción o fallos.

Mejores Prácticas

• Los datos temporales deben usar bases de datos dedicadas configuradas para no registrar globals en journal, en lugar de la base de datos IRISTEMP predeterminada
• El estado de journaling es visible en la página Local Databases del Management Portal (columna Journal)
• Asegurar que todas las bases de datos que contienen datos críticos de aplicación o estado persistente estén con journal
• Las bases de datos que almacenan solo datos transitorios o fácilmente reconstruibles pueden ejecutarse sin journaling para mejorar rendimiento
• Las bases de datos del sistema como IRISLIB e IRISSYS tienen configuraciones de journaling específicas que soportan operaciones del sistema

Propósito

Configuration merge es una característica poderosa en InterSystems IRIS que permite a los administradores personalizar el archivo de parámetros de configuración (CPF) durante el despliegue especificando un archivo de merge de configuración. En sistemas UNIX y Linux, los administradores pueden proporcionar un archivo merge que IRIS usa para actualizar el CPF predeterminado antes de que la instancia se inicie por primera vez.

Casos de Uso

Esta capacidad es esencial para:

• Despliegues automatizados
• Implementaciones de infraestructura como código
• Mantener configuraciones consistentes entre múltiples instancias

Estructura del Archivo Merge

El archivo merge contiene parámetros de configuración organizados en la misma estructura que el archivo CPF, con secciones como [Startup], [config], [Namespaces], etc.

Cómo Funciona

Durante la instalación, IRIS lee el archivo merge y aplica las configuraciones especificadas al CPF predeterminado, sobrescribiendo valores predeterminados con los valores del archivo merge. Esto permite a los administradores pre-configurar:

• Asignaciones de memoria
• Definiciones de namespace
• Configuraciones de base de datos
• Parámetros de seguridad
• Otras configuraciones del sistema

Toda la configuración ocurre sin intervención manual a través del Management Portal.

Beneficios

• Soporta control de versiones de configuraciones
• Habilita despliegues repetibles
• Reduce errores de configuración manual
• Ideal para despliegues en contenedores, sistemas de aprovisionamiento automatizado e instalaciones a gran escala

Después del merge inicial y el arranque, el CPF resultante refleja todas las configuraciones merged y puede modificarse adicionalmente a través del Management Portal o programáticamente según sea necesario.

Resumen

El dimensionamiento apropiado de recursos de disco y memoria es esencial para el rendimiento y confiabilidad de InterSystems IRIS. Los administradores deben calcular requisitos basándose en características de carga de trabajo, proyecciones de crecimiento y objetivos de rendimiento. Los sistemas subdimensionados experimentan bajo rendimiento y problemas operacionales, mientras que los sistemas significativamente sobredimensionados desperdician recursos y presupuesto.

Requisitos de Espacio en Disco

Almacenamiento de Base de Datos: Cada base de datos se almacena en archivos IRIS.DAT que crecen dinámicamente. Consideraciones clave:

• Tamaño máximo de base de datos: 32 TB con bloques de 8KB (predeterminado)
• Tamaño inicial: Establecido durante la creación de la base de datos basado en volumen de datos esperado
• Patrón de crecimiento: Las bases de datos se expanden en 12% del tamaño actual o 10 MB (el que sea mayor), limitado a 1 GB por expansión
• Regla de planificación: Asignar 2-3x el tamaño inicial de datos para acomodar crecimiento sin expansiones frecuentes
• Ejemplo: Para 100 GB de datos iniciales, aprovisionar 200-300 GB de espacio en disco

Almacenamiento de Journals: Los archivos de journal registran todos los cambios de base de datos cronológicamente:

• Planificación de tamaño: Asignar espacio en disco para 2x el volumen de transacciones diarias como línea base
• Período de retención: Factorizar políticas de purga de journals y requisitos de recuperación ante desastres
• Ejemplo: Si el sistema genera 50 GB de datos de journal diariamente, asignar al menos 100 GB para almacenamiento de journals
• Las configuraciones de mirror requieren espacio adicional de journal tanto en primario como en backup

Almacenamiento de Backups: Planificar áreas de staging de backup si se usan backups locales:

• Backups completos: Espacio igual al tamaño total de la base de datos
• Backups incrementales: Espacio adicional basado en tasa de cambio diaria
• Retención: Múltiples generaciones de backups multiplican los requisitos de espacio

Almacenamiento de Sistema y Temporal:

• Directorio de instalación: 2-5 GB dependiendo de plataforma y componentes
• Base de datos IRISTEMP: Tamaño basado en operaciones de ordenamiento, agrupación y temporales de aplicación
• Rango típico: 10-50 GB para sistemas de producción con uso moderado de SQL

Ejemplo de Cálculo Total de Disco: Para un sistema con 500 GB de datos de producción:

• Bases de datos: 500 GB × 2.5 (factor de crecimiento) = 1,250 GB
• Journals: 100 GB diarios × 2 = 200 GB
• Backups: 500 GB (completo) + 50 GB (incrementales) = 550 GB
• Sistema/temp: 20 GB
• Total: ~2,020 GB (2 TB)

Requisitos de Memoria

Database Cache (Global Buffer Pool): La asignación de memoria más crítica para el rendimiento de IRIS:

• Predeterminado: Asignación automática al 25% de RAM física explícitamente NO está lista para producción
• Recomendación de producción: Asignar 50-80% de RAM disponible para database cache
• Fórmula de conteo de buffers: (MB asignados × 1024) ÷ Tamaño de bloque en KB
• Ejemplo: 8,192 MB con bloques de 8KB = (8192 × 1024) ÷ 8 = 1,048,576 buffers
• Múltiples tamaños de bloque: Cada tamaño de bloque requiere asignación separada
• 8KB: Datos e índices estándar (asignación primaria)
• 64KB: Globals de stream y objetos grandes (típicamente 5-10% de asignación de 8KB)
• Consideración ECP: Asignar al menos 50 MB de buffers de 8KB para estructuras de control ECP

Routine Cache: Almacena routines compiladas en memoria:

• Configuración automática: 10% del database cache (para buffers de 8KB)
• Rango: Mínimo 80 MB, Máximo 1,020 MB
• Para la mayoría de sistemas de producción con database caches dimensionados apropiadamente, la asignación automática es suficiente
• Excepción: Sistemas con bases de código muy grandes pueden beneficiarse de ajuste manual

Shared Memory Heap (gmheap): Memoria para operaciones del sistema más allá del caché:

• La asignación predeterminada es típicamente suficiente para operaciones básicas
• Aumentar para: Procesamiento pesado de consultas SQL, dejournaling paralelo, configuraciones ECP
• Monitorear mediante: System Operation > System Usage > página Shared Memory Heap Usage
• Síntoma de insuficiencia: Errores relacionados con asignación de memoria compartida o fallos de consultas SQL

Memoria por Proceso (bbsiz): Memoria máxima por proceso IRIS:

• Configuración recomendada: -1 (resuelve al valor máximo: 2,147,483,647 KB)
• Usado para: Tablas de símbolos, estructuras y buffers de dispositivos I/O, variables locales
• Asignado dinámicamente según los procesos requieren memoria adicional
• Síntoma de insuficiencia: Errores en procesos

Ejemplo de Cálculo Total de Memoria: Para un servidor con 64 GB de RAM física:

• Database cache: 64 GB × 65% = 41.6 GB (~42 GB)
• Routine cache: 42 GB × 10% = 4.2 GB (limitado a 1020 MB = 1 GB)
• Gmheap: 256 MB (línea base)
• Sistema operativo: 64 GB × 20% = 12.8 GB
• Overhead de aplicación: ~8 GB
• Total asignado: ~42 GB a IRIS + ~21 GB a SO/overhead

Resumen de Fórmulas de Cálculo

Conteo de Buffers: ``` Global Buffers = (Memoria_Asignada_MB × 1024) ÷ Tamaño_Bloque_KB ``` Ejemplo: (16384 MB × 1024) ÷ 8 KB = 2,097,152 buffers

Tamaño de Expansión de Base de Datos (automático): ``` Tamaño_Expansión = MAX(Tamaño_Actual × 0.12, 10 MB), limitado a 1 GB ``` Ejemplo: Base de datos de 5 GB → MAX(5120 × 0.12, 10) = MAX(614.4, 10) = 614.4 MB

Tamaño de Routine Cache (automático): ``` Routine_Cache = Database_Cache_8KB × 0.10 Delimitado por: MIN(MAX(80 MB, valor_calculado), 1020 MB) ``` Ejemplo: 40 GB database cache → 4 GB × 10% = 409.6 MB (dentro de los límites)

Consideraciones de Planificación

Análisis de Carga de Trabajo:

• Volumen de transacciones: Mayor throughput requiere más database cache
• Usuarios concurrentes: Más usuarios aumentan requisitos de memoria y I/O de disco
• Complejidad de consultas: Cargas de trabajo intensivas en SQL necesitan asignaciones más grandes de gmheap
• Características de datos: Objetos grandes (streams, PDFs) se benefician de buffers de 64KB

Proyecciones de Crecimiento:

• Tasa de crecimiento histórico: Analizar últimos 6-12 meses de crecimiento
• Proyecciones de negocio: Factorizar expansión empresarial esperada
• Patrones estacionales: Considerar períodos pico en retail, salud, etc.
• Políticas de retención: Considerar cómo las reglas de retención de datos afectan almacenamiento a largo plazo

Objetivos de Rendimiento:

• SLAs de tiempo de respuesta: Pueden requerir cachés más grandes para mantener consultas sub-segundo
• Ventanas de procesamiento batch: Cachés más grandes pueden acelerar significativamente operaciones masivas
• Requisitos de alta disponibilidad: Las configuraciones de mirror necesitan capacidad suficiente en ambos nodos

Mejores Prácticas:

• Comenzar con recomendaciones documentadas y ajustar basándose en métricas de rendimiento reales
• Monitorear ratios de hit de caché; objetivo >95% para eficiencia de database cache
• Revisar espacio en disco mensualmente; establecer alertas al 80% de capacidad
• Probar asignaciones de recursos en pre-producción antes de desplegar a producción
• Documentar supuestos y cálculos de dimensionamiento para planificación futura de capacidad

Resumen del CPF

El archivo de parámetros de configuración (iris.cpf) es el repositorio central para información de configuración a nivel de sistema en InterSystems IRIS. Ubicado en el directorio manager (install-dir/mgr/), este archivo contiene la mayoría de las configuraciones configurables para una instancia IRIS.

Organización del CPF

El CPF está organizado en secciones que agrupan parámetros relacionados:

• [Startup]: Configuraciones de inicialización
• [config]: Configuración general
• [Namespaces]: Definiciones de namespace
• [Map.namespace]: Mapeos de namespace

Un CPF predeterminado se despliega con cada instancia y sirve como la configuración de línea base.

Métodos de Modificación

Los administradores pueden modificar el CPF a través de tres métodos primarios:

1. Management Portal: Interfaz amigable para cambios de configuración más comunes, actualizando automáticamente el CPF cuando los administradores guardan cambios a través de varias páginas de configuración.

2. Terminal: Acceso programático a configuraciones a través de clases del sistema y utilidades, habilitando cambios de configuración scripteados.

3. Edición directa de texto: Para escenarios avanzados o cambios masivos, los administradores pueden editar directamente el archivo CPF usando un editor de texto mientras IRIS está detenido. Este método requiere atención cuidadosa a la sintaxis y validez de parámetros.

Parámetros Críticos del CPF

• Asignaciones de memoria (globals, routines, gmheap)
• Rutas de directorio de base de datos
• Definiciones y mapeos de namespace
• Configuraciones de seguridad
• Configuración de red (puerto de superserver)
• Comportamiento de inicio

Requisitos de Reinicio

Al realizar cambios que requieren reinicio de IRIS, el Management Portal muestra un mensaje de advertencia indicando que las modificaciones no tendrán efecto hasta el reinicio. Algunos cambios tienen efecto inmediato sin reinicio, pero si se hace cualquier cambio que requiera reinicio, todos los cambios se retienen hasta que ocurra el reinicio.

Mejores Prácticas

• Siempre respaldar el CPF antes de realizar cambios significativos
• Documentar el propósito de las personalizaciones para referencia futura
• Incluir el CPF en procedimientos de backup y sistemas de control de versiones para preservar la configuración junto con el código de aplicación

Resumen

El Management Portal de InterSystems IRIS muestra numerosos valores calculados que ayudan a los administradores a comprender el estado del sistema y el rendimiento. Estos valores calculados se derivan de métricas del sistema raw y proporcionan insights significativos que los números raw solos no pueden transmitir.

Valores Calculados Relacionados con Memoria

• Conteos de buffer: Número de buffers creados para cada tamaño de bloque (calculado como memoria asignada dividida por tamaño de bloque)
• Tamaño de routine cache (automático): 10% del database cache para buffers de 8KB, mínimo 80MB, máximo 1020MB
• Memoria gmheap disponible: Total gmheap menos memoria asignada para varios subsistemas

El Management Portal muestra estos cálculos en la página Memory and Startup y la página Shared Memory Heap Usage.

Valores Calculados Relacionados con Base de Datos

• Utilización de tamaño: Tamaño actual de base de datos como porcentaje del máximo (cuando se establece un máximo)
• Umbral multivolumen: Tamaño al cual se crean nuevos volúmenes
• Tamaño de expansión (automático): 12% del tamaño actual o 10MB, el que sea mayor, limitado a 1GB

La página Local Databases muestra estas métricas calculadas junto con información raw de base de datos.

Valores Hash de Base de Datos

El método GetNamespace del Management Portal retorna valores hash de base de datos (crhash) para cada base de datos mapeada a un namespace:

• Los hashes son checksums calculados desde la configuración de base de datos y el estado del contenido
• Los clientes pueden usar estos hashes para detectar cambios de configuración sin recuperar información completa de la base de datos
• Cuando la configuración o contenido de una base de datos cambia, su valor hash cambia
• Útil para herramientas de desarrollo que mantienen cachés locales de información de base de datos

Valores Calculados Relacionados con Rendimiento

• Ratios de hit de global buffer cache: Porcentaje de solicitudes de base de datos servidas desde memoria sin I/O de disco
• Métricas de eficiencia de routine cache
• Porcentajes de utilización de tabla de locks

Estos valores calculados aparecen en varias páginas de monitoreo bajo System Operation y ayudan a los administradores a identificar cuellos de botella de rendimiento y ajustar parámetros del sistema.