T4.1: Writes Defensive Code

Knowledge Review - InterSystems IRIS Development Professional

1. Selecciona estrategias apropiadas de manejo de error (TRY-CATCH, $ZTRAP)

Puntos Clave

  • TRY-CATCH: Manejo moderno de excepción estructurado con procesamiento de error a nivel de bloque
  • $ZTRAP: Mecanismo legacy de trampa de error redirigiendo control a una ubicación especificada
  • $ETRAP: Mecanismo legacy alternativo ejecutando código de manejo de error in-line
  • Compatibilidad: TRY-CATCH y $ZTRAP pueden coexistir en diferentes niveles de pila
  • Mejor práctica: Usar TRY-CATCH para nuevo desarrollo; $ZTRAP prohibido dentro de bloques TRY
  • Objetos de excepción: TRY-CATCH usa %Exception.AbstractException para información de error rica

Notas Detalladas

Resumen

InterSystems IRIS proporciona múltiples mecanismos de manejo de error, cada uno adecuado para diferentes escenarios.

Mecanismo TRY-CATCH

El mecanismo TRY-CATCH es el enfoque moderno recomendado, proporcionando manejo de excepción estructurado con separación clara entre código protegido y código de manejo de error. Cuando un error ocurre dentro de un bloque TRY, control transfiere al bloque CATCH, que recibe un objeto de excepción conteniendo información de error detallada. El manejador de excepción puede registrar errores, realizar limpieza, re-lanzar excepciones usando THROW, o permitir que ejecución continúe. Bloques TRY no crean nuevos niveles de pila, significando que no afectan alcance de variable con comandos NEW.

Mecanismo Legacy $ZTRAP

El mecanismo legacy $ZTRAP establece una variable especial a una referencia de entrada (label o rutina) donde control transfiere en error. Dentro de una rutina, puede establecer $ZTRAP a un label local, rutina externa, o label dentro de una rutina externa. La forma asterisco (SET $ZTRAP="*location") ejecuta en el contexto de error, mientras la forma estándar desapila a la ubicación de trampa. $ETRAP es una alternativa que ejecuta código de manejo de error in-line en lugar de transferir control. Cuando establece $ZTRAP a un valor no vacío, toma precedencia sobre $ETRAP ejecutando implícitamente NEW $ETRAP y estableciendo $ETRAP a cadena vacía.

Elegir la Estrategia Correcta

Estrategias de manejo de error deberían seleccionarse basadas en estructura de código y requisitos. TRY-CATCH es ideal para métodos de clase modernos y procedimientos requiriendo manejo de excepción estructurado con múltiples tipos de error. Usar $ZTRAP cuando se mantiene código legacy o cuando necesita manejo de error en diferentes niveles de pila. Restricciones importantes: $ZTRAP no puede usarse dentro de sentencias protegidas de bloque TRY; errores definidos por usuario con THROW están limitados solo a TRY-CATCH; sin embargo, el comando ZTRAP puede usarse con cualquier tipo de procesamiento de error. Comprender comportamiento de pila de ejecución es crítico - la variable especial $ESTACK proporciona información sobre niveles de ejecución relativos, y manejadores de error ejecutan en el mismo nivel que el error a menos que sean redirigidos explícitamente.

Referencias de Documentación

2. Diagnostica problemas de rendimiento del sistema

Puntos Clave

  • Management Portal: Página System Operation > Processes muestra información de proceso en tiempo real
  • Métricas de proceso: Tiempo CPU, uso de dispositivo, namespace, y estado de ejecución
  • Utilidades $SYSTEM.Process: Acceso programático a información de proceso y sistema
  • Indicadores de rendimiento: Monitorear ratios de hit de caché de base de datos, esperas de lock, y referencias global
  • System Dashboard: Vista completa de salud de sistema y utilización de recursos
  • Rendimiento de Consulta SQL: Análisis de plan de consulta y estadísticas de ejecución

Notas Detalladas

Resumen

Diagnosticar problemas de rendimiento del sistema en InterSystems IRIS requiere comprender múltiples herramientas de monitoreo e indicadores de rendimiento.

Monitoreo de Proceso del Management Portal

El Management Portal proporciona monitoreo completo de proceso a través de System Operation > Processes, mostrando procesos activos con métricas clave incluyendo número de job, ID de proceso, tiempo total de CPU en milisegundos, nombre de usuario, dispositivo actual, namespace, y ubicación de rutina. La página Process Details proporciona insight más profundo en procesos individuales incluyendo pila de ejecución, estado de lock, y variables específicas de proceso. Esta información ayuda a identificar procesos consumiendo recursos excesivos o experimentando condiciones de bloqueo.

Diagnóstico Programático y System Dashboard

Las clases %SYS.NLS proporcionan acceso programático a datos de tabla de sistema y proceso, habilitando monitoreo automatizado y diagnóstico. Usar ##class(%SYS.NLS.Format).%New() para acceder información de formateo específica de locale y propiedades de sistema. El System Dashboard en el Management Portal (System Operation > System Dashboard) presenta visualización en tiempo real de métricas críticas incluyendo utilización CPU, consumo de memoria, tasas de I/O de disco, y actividad de red. Monitorear eficiencia de caché de base de datos examinando estadísticas de buffer global - ratios de hit de caché pobres indican asignación de memoria insuficiente o patrones de acceso a datos ineficientes.

Cuellos de Botella de Rendimiento Comunes

Cuellos de botella de rendimiento comúnmente se manifiestan en varias áreas: contención de lock excesiva visible a través de la página Locks (System Operation > Locks), consultas SQL ineficientes identificables a través de análisis de plan de consulta, asignación de memoria inadecuada causando I/O de disco frecuente, y problemas a nivel de proceso tales como algoritmos ineficientes o fugas de recursos. Usar el Terminal para ejecutar comandos de diagnóstico como WRITE $SYSTEM.Process.State() para estado de proceso actual y DO ^%SS para estadísticas de sistema. Las páginas System Usage proporcionan desgloses detallados de consumo de recursos incluyendo uso de heap de memoria compartida, actividad de journal, y consumo de unidad de licencia. Monitoreo regular establece líneas base de rendimiento, habilitando identificación rápida de anomalías requiriendo investigación.

Referencias de Documentación

3. Gestiona memoria de proceso efectivamente

Puntos Clave

  • Caché de base de datos: Buffer de memoria compartida para datos; asignar 25%+ de memoria de sistema para producción
  • Caché de rutina: Asignado automáticamente en 10% de caché de base de datos (mín 80MB, máx 1020MB)
  • Memoria máxima por proceso: Configurar vía parámetro bbsiz; recomendar -1 (ilimitado) para la mayoría de casos
  • Memoria privada de proceso: Usada para tablas de símbolos, buffers I/O; asignada según necesidad hasta alcanzar máximo
  • Memoria no desasignada: Memoria privada de proceso persiste hasta que proceso sale
  • Errores : Indican que proceso excedió memoria máxima; incrementar bbsiz u optimizar código

Notas Detalladas

Resumen

Gestión efectiva de memoria de proceso en InterSystems IRIS requiere comprender tres categorías de memoria distintas: caché de base de datos (compartida), caché de rutina (compartida), y memoria privada de proceso (por proceso).

Configuración de Caché de Base de Datos

El caché de base de datos, también llamado pool de buffer global, almacena bloques de datos accedidos frecuentemente en memoria para minimizar I/O de disco. Cuando primero instalado, IRIS asigna 25% de memoria física al caché de base de datos, pero esta configuración inicial es inapropiada para uso de producción. Antes de despliegue a producción o testing de rendimiento, configure manualmente caché de base de datos usando el Management Portal (System Administration > Configuration > System Configuration > Memory and Startup), seleccionando "Specify Amount" e ingresando asignación apropiada de megabyte. Para sistemas con múltiples tamaños de bloque habilitados, asignar memoria separadamente para cada tamaño de bloque.

Configuraciones de Caché de Rutina y Memoria Por Proceso

El caché de rutina almacena código ObjectScript compilado, con asignación automática predeterminada a 10% del caché de base de datos para buffers 8KB, limitado por mínimo 80MB y máximo 1020MB. Para instancias de producción típicas con caché de base de datos apropiadamente configurado, asignación automática de caché de rutina es suficiente, aunque aplicaciones con librerías de código extensas pueden beneficiarse de ajuste manual. La configuración Maximum Per-Process Memory (parámetro bbsiz) controla el límite de memoria para procesos individuales, con rango permitido de 256 KB a 2147483647 KB. InterSystems recomienda establecer esto a -1 (que resuelve a valor máximo) para la mayoría de circunstancias a menos que restricciones de recursos específicas requieran límites de memoria de proceso.

Comportamiento de Memoria Privada de Proceso

Memoria privada de proceso sirve múltiples propósitos incluyendo asignación de tabla de símbolos para variables locales, estructuras de acceso a dispositivo I/O y buffers, y varios requisitos de runtime. Esta memoria asigna en extents crecientes conforme la aplicación demanda hasta alcanzar el máximo bbsiz. Una vez asignada a un proceso, memoria privada nunca es desasignada hasta terminación de proceso - esta decisión de diseño optimiza rendimiento evitando sobrecarga de asignación pero requiere que desarrolladores sean conscientes de acumulación de memoria en procesos de larga ejecución. Cuando procesos exceden memoria máxima, encuentran errores . Resolución involucra incrementar configuración bbsiz u optimizar código para reducir consumo de memoria a través de técnicas como limpiar arrays de variable local grandes, reducir tamaño de tabla de símbolos, o reestructurar algoritmos para procesar datos en fragmentos más pequeños.

Referencias de Documentación

4. Implementa mejores prácticas de gestión de proceso

Puntos Clave

  • Comando JOB: Generar nuevos procesos con parámetros apropiados de dispositivo y namespace
  • Suspensión de proceso: Usar Suspend/Resume para debugging; evitar en producción
  • Terminación limpia: Permitir que procesos completen elegantemente antes de forzar terminación
  • Jobs en segundo plano: Configurar con mecanismos apropiados de trampa de error y logging
  • Monitoreo de proceso: Revisar regularmente lista de proceso para procesos colgados o fuera de control
  • Limpieza de recursos: Asegurar que locks liberados y transacciones confirmadas antes de salida de proceso

Notas Detalladas

Resumen

Gestión de proceso en InterSystems IRIS abarca creación, monitoreo, control, y terminación de procesos de sistema.

Creación de Jobs en Segundo Plano

El comando JOB crea nuevos procesos (jobs en segundo plano) que ejecutan independientemente del proceso padre. Al generar jobs, especificar parámetros apropiados incluyendo dispositivo para redirección I/O, namespace para contexto de ejecución, y prioridad para programación. Jobs heredan ciertas configuraciones ambientales de procesos padre pero ejecutan en espacios de memoria separados con contextos de manejo de error independientes. Diseño apropiado de job incluye establecer trampas de error ($ZTRAP o TRY-CATCH), implementar mecanismos de logging para rastrear ejecución y errores, y asegurar limpieza de recursos en terminación tanto normal como anormal.

Control y Terminación de Proceso

La página Processes del Management Portal (System Operation > Processes) proporciona control de proceso centralizado incluyendo capacidades de display, suspensión, reanudación, y terminación. Suspensión de proceso pausa ejecución para propósitos de debugging pero debería evitarse en entornos de producción ya que consume recursos sin progreso. Al terminar procesos, distinguir entre terminación elegante (permitiendo que código de limpieza ejecute) y terminación forzada con error (alto inmediato). Mejor práctica es intentar terminación elegante primero, monitorear para completitud, y forzar terminación solo si el proceso falla en responder. Este enfoque asegura liberación apropiada de recursos incluyendo locks, transacciones de base de datos, y handles de archivo.

Mejores Prácticas para Procesos de Larga Ejecución

Mejores prácticas de gestión de proceso incluyen monitoreo regular para identificar problemas de rendimiento o fugas de recursos, establecer convenciones para nomenclatura de job en segundo plano y logging, implementar mecanismos de timeout para operaciones esperadas completar dentro de plazos específicos, y documentar interdependencias de proceso para evitar disrupción inadvertida. Para procesos de larga ejecución, implementar mecanismos de heartbeat que periódicamente actualicen indicadores de estado, habilitando a sistemas de monitoreo detectar procesos colgados. Usar capacidades de mensajería broadcast con moderación para comunicarse con procesos de terminal activos. Procesos críticos deberían implementar manejo de error robusto para prevenir fallos en cascada - si un proceso encuentra errores, debería registrar información de diagnóstico completa, limpiar recursos, y salir elegantemente en lugar de permanecer en estado fallido consumiendo recursos.

Referencias de Documentación

5. Comprende límites y restricciones del sistema

Puntos Clave

  • Límite de base de datos: Máximo 15,998 bases de datos por instancia
  • Tamaño de base de datos: Hasta 32 terabytes con tamaño de bloque predeterminado 8KB
  • Memoria de proceso: 256 KB a 2,147,483,647 KB por proceso (parámetro bbsiz)
  • Longitud de cadena: Tamaño máximo de cadena varía por contexto y configuración
  • Recursos de lock: Límites dependientes de sistema en nombres de lock concurrentes
  • Caché de rutina: Mínimo 80 MB a máximo 1,020 MB cuando auto-configurado

Notas Detalladas

Resumen

Comprender límites y restricciones del sistema es esencial para diseñar aplicaciones InterSystems IRIS escalables.

Límites de Base de Datos

El límite absoluto en el número de bases de datos que pueden configurarse dentro de una sola instancia IRIS es 15,998, dado espacio de almacenamiento suficiente. Este límite acomoda incluso los despliegues empresariales más grandes con requisitos extensivos de partición de datos. Límites de tamaño de base de datos individual dependen de tamaño de bloque - con bloques predeterminados de 8KB, bases de datos pueden crecer a 32 terabytes. Tamaños de bloque más grandes (16KB, 32KB, 64KB) incrementan proporcionalmente tamaño máximo de base de datos, aunque también afectan utilización de memoria y patrones I/O. Bases de datos expanden dinámicamente según necesidad cuando almacenamiento libre está disponible, aunque administradores pueden especificar restricciones de tamaño máximo para prevenir crecimiento no controlado.

Restricciones de Proceso y Memoria

Restricciones a nivel de proceso incluyen memoria máxima por proceso configurable de 256 KB a 2,147,483,647 KB a través del parámetro bbsiz. El valor predeterminado y configuración recomendada de -1 (que resuelve a máximo) elimina restricciones de memoria artificiales para la mayoría de aplicaciones. Sin embargo, entornos con restricción de recursos o sistemas multi-tenant pueden beneficiarse de límites explícitos previniendo que procesos individuales consuman memoria excesiva. Límites de longitud de cadena varían por contexto - cadenas almacenadas en globals o variables locales pueden ser muy grandes, pero operaciones o funciones específicas pueden imponer límites prácticos. Desarrolladores deberían consultar documentación para restricciones específicas de contexto cuando trabajan con cadenas extremadamente grandes o datos binarios.

Restricciones de Concurrencia y Caché

Restricciones de concurrencia incluyen límites de recurso de lock, que son dependientes de sistema pero generalmente suficientes para operaciones normales. Solicitudes de lock excesivas dentro de un solo proceso pueden indicar problemas de diseño requiriendo refactorización. El caché de rutina tiene límites mínimos (80 MB) y máximos (1,020 MB) cuando usa asignación automática, aunque configuración manual puede sobrescribir estos límites si aplicaciones requieren cachés de código más grandes. Asignaciones de heap de memoria compartida (gmheap) deben acomodar estructuras de consulta SQL, estructuras de datos ECP, y varias necesidades de sistema - aplicaciones con grandes números de consultas SQL concurrentes o configuraciones ECP extensivas requieren asignación gmheap incrementada. Comprender estos límites durante fase de diseño previene refactorización costosa cuando aplicaciones escalan. La mayoría de restricciones son generosas y raramente alcanzadas en aplicaciones típicas, pero conciencia habilita planificación proactiva para requisitos excepcionales.

Referencias de Documentación

Resumen de Preparación para el Examen

Conceptos Críticos a Dominar:

  1. Manejo de Error: Comprender cuándo usar TRY-CATCH vs $ZTRAP; conocer reglas de compatibilidad
  2. Objetos de Excepción: Familiarizarse con clase %Exception.AbstractException y comando THROW
  3. Monitoreo de Rendimiento: Saber cómo acceder información de proceso vía Management Portal
  4. Configuración de Memoria: Comprender configuraciones de caché de base de datos, caché de rutina, y memoria por proceso
  5. Comportamiento de Memoria de Proceso: Recordar que memoria privada nunca desasigna hasta salida de proceso
  6. Límites de Sistema: Conocer conteo máximo de base de datos (15,998) y tamaño de base de datos (32TB en bloques 8KB)
  7. Solución de Problemas de Memoria: Reconocer errores indican límites bbsiz excedidos
  8. Mejores Prácticas: Usar TRY-CATCH para código nuevo, monitorear procesos regularmente, limpiar recursos

Escenarios Comunes de Examen:

  • Seleccionar mecanismo de manejo de error apropiado para una estructura de código dada
  • Diagnosticar problemas de rendimiento basados en métricas de proceso e indicadores de sistema
  • Calcular asignaciones de memoria apropiadas para cachés de base de datos y rutina
  • Identificar causas de errores y seleccionar estrategias de resolución
  • Determinar si diseño de sistema excede límites arquitecturales
  • Solucionar problemas de procesos colgados o fuera de control
  • Implementar limpieza apropiada de recursos en manejadores de error

Recomendaciones de Práctica Práctica:

  • Escribir código usando manejo de error TRY-CATCH y $ZTRAP
  • Disparar deliberadamente errores y observar comportamiento de manejador de excepción
  • Monitorear procesos vía Management Portal mientras ejecuta aplicaciones de prueba
  • Configurar asignaciones de caché de base de datos y rutina y observar impacto de rendimiento
  • Crear procesos que se aproximan a límites de memoria para observar errores
  • Practicar usando herramientas de diagnóstico como ^%SS y métodos $SYSTEM.Process
  • Experimentar con parámetros de comando JOB y gestión de proceso en segundo plano
  • Revisar documentación de límites de sistema y calcular capacidad para escenarios hipotéticos

Secciones de Documentación Clave para Revisar:

  • GCOS.pdf Capítulo 23: "Using TRY-CATCH" (manejo de error completo)
  • GCOS.pdf Apéndice B: "Traditional Error Processing" ($ZTRAP y $ETRAP)
  • GSA.pdf Capítulo 2: "Memory and Startup Settings" (configuración de memoria)
  • GSA.pdf Capítulo 19: "Controlling InterSystems IRIS Processes" (gestión de proceso)
  • GSA.pdf Capítulo 5: "Configuring Local Databases" (límites y restricciones de sistema)

Referencia de Comando Importante:

  • TRY/CATCH/THROW: Manejo moderno de excepción
  • SET $ZTRAP: Configuración legacy de trampa de error
  • JOB: Generar procesos en segundo plano
  • LOCK: Control de concurrencia (relacionado con evitar deadlock)
  • Métodos $SYSTEM.Process: Gestión de proceso programática
  • ^%SS: Utilidad de estadísticas de sistema

Errores Comunes a Evitar:

  • Usar $ZTRAP dentro de sentencias protegidas de bloque TRY (prohibido)
  • Asumir que memoria privada de proceso será desasignada durante ejecución
  • Establecer caché de base de datos a "Initial" (25%) para uso de producción
  • Fallar en implementar manejo de error en jobs en segundo plano
  • Ignorar límites de sistema al diseñar aplicaciones de gran escala
  • No monitorear para errores en procesos de larga ejecución

Report an Issue