
Cuando un entorno IBM i experimenta un consumo rápido de CPU u otras condiciones que comienzan a impactar en la memoria, hay ciertos tipos de trabajos que entran en la lista de sospechosos con más frecuencia que otros. Si bien los trabajos QZDASOINIT (conexiones JDBC/ODBC) casi siempre entran en juego aquí, rara vez son los únicos responsables.
A menudo, tan solo son culpables de estar mal acompañados: generalmente, es el código SQL mal escrito que se ejecuta en ellos lo que causa estos problemas, y provoca que los trabajos QZDASOINIT consuman la mayor cantidad de CPU posible, hasta que son detectados y detenidos
Entonces, ¿cuál es la verdadera naturaleza de los trabajos QZDASOINIT y cómo es posible evitar que se ejecuten de forma descontrolada en el sistema?
QZDASONIT es el nombre que se le asigna a los trabajos SQL de servicio de base de datos. Estos trabajos dan servicio a las solicitudes SQL provenientes de aplicaciones cliente JDBC y/o ODBC y, normalmente, se ejecutan en el subsistema QUSRWRK. Los trabajos de System i Navigator también usan este nombre de trabajo cuando ejecutan una consulta a través de la ventana SQL.
Cuando hay un pico de uso de CPU en el sistema puede ser muy difícil determinar qué trabajo (o serie de trabajos) son los que contribuyen al problema, ya que todos comparten el mismo nombre. Potencialmente podría haber cientos de trabajos QZDASOINIT impactando en el consumo de CPU en conjunto, en lugar de un único culpable.
Obtenga visibilidad de los trabajos QZDASOINIT
Para empezar, los administradores necesitan tener visibilidad sobre este problema. Lo pueden conseguir al ejecutar un comando WRKACTJOB seguido de una investigación manual por lote y resolución a nivel de trabajo (y repetir el proceso para cada sistema). La información devuelta por este comando todavía deja preguntas importantes sin respuesta: ¿Quién está ejecutando esos trabajos? ¿Qué proporción de CPU total están consumiendo?
Responder a estas preguntas requiere un grado mayor de conocimiento, que le dará una comprensión y un contexto más significativos a cualquier problema, para poder resolverlo más rápidamente. Después de todo, cuanto más demore en investigar qué pasa, más CPU se consumirá. Claramente, está en el interés financiero de todos resolver este tipo de incidentes cuanto antes.
Con la solución de monitoreo en tiempo real adecuada, los administradores son capaces de responder a todas estas preguntas.
Considere la visibilidad de la actividad JDBC/ODBC, especialmente aquellos trabajos que ejecutan comandos SQL. Robot Monitor le ofrece acceso detallado a los administradores que se ocupan de los problemas con trabajos QZDASOINIT.
En este caso, los administradores tienen visión en tiempo real del uso de CPU de los trabajos QZDASOINIT y acceso inmediato a los trabajos abusivos para su resolución. Para acomodar las particularidades del entorno y recursos, también pueden crear niveles de umbrales para una detección temprana, con el fin de poder atender los problemas antes de que crezcan y se conviertan en incidentes mayores.
Los administradores pueden configurar este tipo de monitoreo creando primero una definición de datos que será calificada por uno o todos los sistemas, y por un nombre de trabajo específico. Luego, pueden optar por agregar umbrales personalizados a cada monitor y alertas proactivas cuando los trabajos exceden estos umbrales. Dentro de las definiciones de datos, los administradores también pueden seleccionar grupos para agregar a estos parámetros de monitoreo.
Pensemos en un ejemplo con un grupo de analistas de datos de Negocio. Este nivel de monitoreo granular puede extenderse hasta incluir el subsistema, código de contabilidad, usuario, usuario actual, trabajo y función. Con este monitor configurado, gana visibilidad proactiva sobre este grupo y su umbral, en el contexto de consumo total de CPU por parte de los trabajos QZDASOINIT y el consumo total de CPU del sistema.
QZDASOINIT y problemas de memoria
Los trabajos QZDASOINIT también pueden ser traicioneros cuando se trata de problemas de memoria. Un escenario típico es cuando la memoria de un trabajo por lotes se vacía por trabajos interactivos, y el proceso por lotes queda intentando acceder permanentemente a los trabajos en una memoria que ya no está disponible. Este proceso problemático se conoce como "thrashing". El desafío clave para resolverlo radica en su identificación, ya que el proceso fuera de control es más visible por su síntoma de un aumento en las faltas de página.
Como en nuestros ejemplos previos de CPU, la investigación necesaria para determinar qué subsistema o trabajos están siendo impactados por faltas de página que no son de base de datos puede ser larga y costosa si no se cuenta con monitoreo en tiempo real. En primer lugar, los administradores pueden acceder al Estado de Sistema (System Status) para ver el número de faltas de página en cada pool de memoria, pero podrían quedar sin saber qué trabajos son los responsables de causar problemas en esos pools de memoria y qué subsistemas usan estos pools de memoria.
Para abordar el problema, Robot Monitor emplea las mismas métricas de definición de datos para crear un monitor apropiado. Ofrece visibilidad en tiempo real a través de una barra NDB dedicada, que muestra las fallas generales del sistema por segundo y proporciona acceso inmediato al trabajo infractor para su resolución. Este monitor tiene el mismo umbral y capacidades de alerta que mantendrán a los administradores proactivos y un paso por delante de los problemas relacionados a recursos que escalen.
La práctica de administrar por excepción significa que los trabajos que son culpables de mal comportamiento no tienen oportunidad de esconderse bajo un nombre genérico compartido por miles de personas (y de permanecer desapercibidos hasta que se descubren). En cambio, a la primera señal de problemas, se envía una alerta directamente al administrador que tiene toda la información necesaria para resolver el problema, y ayudar a su empresa a evitar un error que podría costarle muchísimo dinero.
Este artículo forma parte de la guía "¿Por qué mi trabajo QZDASOINIT en IBM i no termina de una vez?" que puede descargar aquí.
Vea Robot Monitor en acción
Robot Monitor le provee información de detalle para identificar qué sentencia SQL exacta afecta su IBM i, realiza monitoreo proactivo de trabajos QZDASOINIT fuera de control y mucho más.