Guía

¿Por qué mi trabajo QZDASOINIT no termina de una vez?

Introducción

Cuando uno trabajo o proceso -como un trabajo de servicio de base de datos- se sale fuera de control, lo más probable es que el consumo de recursos se dispare y el rendimiento del sistema se degrade frente a sus ojos.

Con todas las consultas enviadas por los usuarios, las aplicaciones externas y los trabajos por lotes e interactivos que impactan constantemente en su sistema, ¿cómo es posible anticiparse a estos grandes consumidores de CPU?

En esta guía encontrará todas las respuestas que necesita.

Los cinco artículos que la componen son de lectura rápida y poseen mucha información que ilustrarán el valor (tanto en términos de tiempo como de dinero) del monitoreo proactivo de trabajos y las notificaciones automatizadas. Siga leyendo para aprender:

  • Cómo las tareas de LIC (Licensed Internal Code) impactan en la CPU, sin hacerse notar
  • Cómo detener trabajos QZDAONIT que entraron en un bucle
  • Cómo un puñado de problemas relacionados al monitoreo puede costarle más de un millón de dólares

No permita por más tiempo que los trabajos abusivos y ocultos dominen los recursos del sistema. Esta guía le mostrará cómo es posible tener visibilidad de cualquier incidente relacionado a trabajos, y cómo resolverlos más rápidamente, gracias al uso de herramientas sofisticadas de monitoreo, desarrolladas especialmente para gestionar incluso las cargas de trabajo más exigentes.

¡Esperamos que le resulte de utilidad!

 

¿Dónde está la capacidad de CPU que falta?

¿Alguna vez ha notado que la cantidad de CPU utilizada por trabajos individuales no suma el 100%? Sucede que sus trabajos y subsistemas son solo una parte de la historia. Para conocer el resto, necesitamos hablar sobre el Licensed Internal Code (LIC).

Los fanáticos de la ciencia ficción (y los datos científicos) están familiarizados con el concepto de universos o mundos paralelos, que existen al lado del nuestro, pero están separados de éste. Muy a menudo, las personas, los lugares y los eventos en estos mundos paralelos son similares a los del nuestro, pero presentan diferencias fundamentales.

Si bien los universos paralelos son un elemento básico en la ciencia ficción y la física avanzada, no es necesario investigar intensamente para verlos en acción. De hecho, no hace falta buscar más allá de su confiable IBM i para presenciar un caso real de universos paralelos.

En su IBM i coexisten dos universos:

  • El mundo del Sistema Operativo IBM i
  • El mundo del LIC (Licensed International Code)

A pesar de que estos "universos" comparten las mismas bases físicas (servidores Power Systems, etc.), el mundo del Sistema Operativo (con el que nos podemos comunicar) y el mundo del LIC son bastante diferentes.

Gestión del trabajo: Jobs y threads

Un gran ejemplo de esto se da con la gestión del trabajo. La gestión del trabajo en el Sistema Operativo IBM i incluye trabajos, subsistemas, pools de memoria, colas de trabajo, y mucho más. Si usted es un administrador u operador, seguramente interactúa con este mundo todo el tiempo.

En este universo los trabajos usan CPU. Si usted desea saber dónde se produce gran parte del consumo de la CPU, usará su herramienta preferida para ver los trabajos. Cada trabajo está compuesto por una o muchas hebras (threads). Las hebras son porciones de trabajos de máquina que puede ejecutarse de forma independiente pero que también están unidas por un trabajo único.

Esto permite que las hebras dentro de un trabajo compartan recursos de forma más eficiente de lo que harían si fueran trabajos individuales. Piense en ellos como subdivisiones dentro de un trabajo.

Trabajos y hebras: ese es el mundo familiar del Sistema Operativo.

Gestión del trabajo con tareas

Ahora veamos el mundo paralelo del LIC (Licensed Internal Code). No se puede acceder a este mundo a menos que se esté equipado con un software de servicio IBM o se tengan conocimientos avanzados de SST (System Service Tools).

En el extraño e inusual mundo de LIC, el concepto principal de gestión del trabajo no es el trabajo (job), sino la tarea. En términos de gestión del trabajo, realmente no se vuelve más atómico que esto, a menos que se llegue directamente a los núcleos del procesador. No hay subtareas.

Hay cuatro tipos de tareas:

Tareas iniciales

Las tareas iniciales son las tareas equivalentes al trabajo SCPF en IBM i. Durante un IPL, se empieza una tarea inicial, que luego inicia las otras tareas. Tiene el mismo trabajo que el proceso de inicio en Linux y AIX o el Subsistema Administrador de Sesiones (smss.exe o Session Manager Subsystem) en Windows.

Tareas residentes y tareas no residentes

Las tareas residentes y las tareas no residentes son usadas para algunas funciones específicas de LIC. Estas tareas no tienen una contraparte directa en el mundo del Sistema Operativo. Se utilizan para gestionar cosas como operaciones de base de datos, comunicaciones y paginación. (Las tareas residentes residen en la memoria, permanecen en el almacenamiento principal siempre y cuando estén activas).

Tareas de procesamiento liviano

Las tareas de procesamiento liviano son la contrapartida de LIC a las hebras de IBM i. Cada tarea de procesamiento liviano corresponde a una hebra de IBM i, y viceversa. El hecho de que se denominen "de procesamiento liviano" es poco apropiado, ya que representan todo el trabajo que las aplicaciones llevan a cabo en el sistema.

Esta doble distinción entre Sistema Operativo y gestión del trabajo de LIC, y de las tareas de LIC en cuatro tipos diferentes, por supuesto, lo llevará a una conclusión única e ineludible...

¡El LIC es el lugar a dónde va su CPU cuando escasea!

Uso de CPU y tareas de sistema

¿Ha notado alguna vez que la cantidad de CPU que consumen los trabajos individuales no llega a sumar el 100%? No es una cuestión de redondeo (que solo contribuiría con muy poco porcentaje como máximo). No, la cantidad de CPU que usan los trabajos (o, realmente, las tareas LIC que utilizan las hebras que constituyen esos trabajos) es solo una parte de lo que más CPU consume en su sistema.

Los otros consumidores de CPU son las tareas LIC residentes y no residentes (la tarea inicial realmente no es significativo en el uso de CPU después de IPL). Estas tareas, llamadas en conjunto “tareas de sistema”, representan trabajo encubierto y son la mecánica del universo LIC.

En algunos casos, las tareas de sistema consumen una porción mayor de CPU que los trabajos en sí mismos. Un ejemplo clásico de esto es la restauración de un alto número de objetos. Durante la ejecución de una operación de restauración dentro de un trabajo, el Sistema Operativo delega la actividad de restauración en tareas especializadas tipo LIC.

Como resultado, cuando se ejecuta un trabajo RSTOBJ o RSTLIB pesado, puede ver la CPU total del sistema aumentar (algunas veces hasta más del 50%) pero no verá un aumento notable de consumo de CPU en ningún trabajo. Al contrario, sus trabajos de aplicación bien podrían usar menos CPU, porque están siendo desplazados temporalmente por las tareas asistentes.

Si alguna vez nota lo que parece ser el consumo de una gran cantidad inusual de CPU en comparación con la CPU que usan sus trabajos, el mejor lugar para mirar son las tareas de sistema.

Algunas tareas de sistema y sus funciones

Es importante conocer qué tareas de sistema son las que más consumen su CPU, porque eso abre una ventana a un mundo (LIC) que normalmente está cerrado a usted, pero puede impactar muy concretamente en la forma en que las aplicaciones trabajan en el universo IBM i. Por suerte, Robot Monitor le proporciona una pantalla que muestra exactamente eso: el uso de CPU de las tareas LIC que más CPU consumen.

¿Qué tipo de tareas podrá ver? Desafortunadamente, la documentación que proporciona IBM sobre este tema es, en el mejor de los casos, fragmentada y difícil de conseguir. Una de las fuentes es un viejo Redbook de IBM que contiene una lista parcial de estas tareas en un apéndice. Esa lista contiene algunas de las tareas de sistema más importantes, pero aún así faltan muchas. Sin embargo, es mejor que no tener ninguna documentación en absoluto.

Gracias a IBM, fuimos capaces de descubrir la función detrás de algunas tareas de sistema adicionales. Aquí le compartimos la lista:

Nombre tarea Función de la tarea

DBIO01, DBIO02, …

Gestión de almacenamiento de base de datos, una por unidad DASD
DbpmServer Base de datos; pre-trae campos de longitud-variable al almacenamiento general
LDFX01, LDFX02, ...
LDIOM
LDLOIM
Tareas de carga/vuelco (por ejemplo, guardado/restauración)
RM* Tareas RM* relacionadas a Collection Services o extensión de almacenamiento/archivos
RMTMSAFETA Una tarea de temporización que resuelve solicitudes de servicios LIC que no son manejadas por el gestor de interrupciones en el almacenamiento general, normalmente relacionados con actividades de comunicación.
SMMIRRORMC Gestión de almacenamiento, gestión de replicación de ASP
SMPOLnnn Gestión de almacenamiento, tareas de falta de página
SMXCAGER01, SMXCAGER02, ...

Gestión de caché, gestión de storage pool compartidos configurados con *CALC

SMXCSPRVSR Supervisor expert de caché
VIO-WORKER Trabajos de VIOS y HEA (virtual Ethernet card), SCSI, virtual fibre channel y virtual Ethernet activity

Esta información puede ser de utilidad la próxima vez que tenga que determinar por qué el consumo de su CPU está aumentando.

 

Un análisis a fondo de los trabajos QZDASOINIT

Cuando los trabajos QZDASOINIT provocan un pico de consumo de la CPU, generalmente el problema se debe a código SQL mal escrito. ¿Pero cómo es posible saber qué trabajo de servicio de base de datos o qué sentencia SQL es la culpable?

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.

¿Cuánto puede costar un trabajo abusivo?

En una red muy ocupada, que soporta una gran comunidad de usuarios, un único trabajo abusivo es capaz de hacer que la productividad caiga en picada (entre otros problemas) hasta hacerle perder la impresionante suma de US$ 1.000.000, como muestra este mini caso de estudio de monitoreo de trabajos.

Cualquier máquina, partición o red IBM i tiene el potencial de sufrir a causa de un trabajo abusivo, independientemente de qué tan bien se gestione ese sistema o red. Cuando los trabajos no rinden como deberían y, en cambio, pasan su tiempo en bucle, devorando CPU, o simplemente se quedan inactivos, las consecuencias son inmediatas y medibles: considere la comunidad de usuarios improductivos, las sanciones financieras y los gastos adicionales de recursos, incluidas las horas de trabajo desperdiciadas en buscar en el sistema.

Los cambios repentinos en el estado o el desempeño de un trabajo son indicadores claves de que podría haber problemas si estas condiciones persisten sin ser detectadas ni atendidas. No es raro que un trabajo abusivo ponga en marcha una serie de incidentes cada vez más dañinos y costosos, que pueden llevar a los gerentes de IT a ir de un lado al otro para resolver múltiples problemas de sistema, que derivan todos de un único trabajo abusivo.

En una red que soporta una gran comunidad de usuarios, el efecto acumulativo de estos problemas y su impacto en la productividad del usuario significa que la falta de un monitoreo de trabajos puede convertirse en un problema de un millón de dólares muy rápidamente.

Un mini caso de estudio de monitoreo de trabajos

Digamos que la compañía XYZ es una gran organización de servicios financieros que está luchando con problemas de trabajos en su red IBM i, la cual gestiona en forma centralizada. La red soporta 21.000 usuarios en todo el país y la compañía genera US$ 4.200 millones en ingresos anuales. En una revisión para delinear el alcance de este problema, calcularon el impacto financiero asociado sobre las operaciones del año anterior. El costo total fue mucho más de lo que habían pensado en un principio.

Área Problema

Consecuencia

Costo
Rendimiento del trabajo Consistentemente alto uso de la CPU, dado que varios trabajos QZDASOINIT consumen más CPU de la que deberían

        • Pérdida de tiempo

        • Todos los trabajos tienen el mismo nombre difícil saber cuáles son los causantes del problema

        • La productividad del usuario se ralentiza

US$ 112.500  
Estimación anual: US$ 900.000
Rendimiento del trabajo Un trabajo en bucle consume grandes cantidades de almacenamiento temporal
  • Investigación que consume mucho tiempo
  • Se requiere un disco adicional para evitar el bloqueo del sistema
US$ 2.700  
Estimación anual: $13.700
Rendimiento del trabajo Bajo rendimiento de ciertos trabajos debido a una alta tasa de faltas de página en un pool específico, lo que indica demasiados trabajos o memoria insuficiente en el pool
  • Pérdida de tiempo
  • Se debe determinar qué trabajos están ejecutando dentro de cada pool de memoria
  • Debe determinar cuántos trabajos hay en el pool
US$ 24.000 
Estimación anual: US$ 96.000
Rendimiento del trabajo Un trabajo importante para la empresa se vuelve inactivo, pero no se detecta inmediatamente
  • Los usuarios deben esperar a que un trabajo muy pesado se procese
  • El trabajo se retrasa
US$ 1.800 
Estimación anual: US$ 9.000
Total Annual Cost of Job Performance and Status Issues US$1.018.700

El cuadro ilustra cómo una solución efectiva de monitoreo de trabajos podría haber prevenido que esta compañía pague más de US$ 1.000.000 como resultado de problemas relacionados con trabajos de sistema. La compañía y las circunstancias son hipotéticas, pero los costos asociados son demasiado reales, como lo sabrá cualquier gerente de IT que haya tenido problemas con este tipo de procesos.

Proteger el presupuesto de IT de problemas de trabajos

Cuando se enfrenta al desafío de identificar y resolver trabajos problemáticos, usted debe estar equipado con los recursos que le permiten abordar el incidente de forma proactiva, como por ejemplo:

  • Información en tiempo real sobre qué trabajos causan problemas
  • Los medios para reducir el tiempo de investigación
  • Un sistema de respuesta automática para resultados conocidos o esperados
  • La capacidad de identificar trabajos en un escenario de bloqueo-espera
  • Conocimiento de trabajos que han excedido su tiempo máximo de espera en colas y trabajos que tienen un registro de históricamente causar problemas

Armado con estos recursos, puede detectar problemas de trabajos cuando aparecen por primera vez en el sistema y reducir radicalmente su impacto financiero. El truco consiste en aislar el incidente en una etapa temprana, antes de que tenga la oportunidad de crear problemas secundarios, como interferir con la productividad del usuario (una de las mayores fuentes de costos).

Del mismo modo, la detección en tiempo real (que proporciona información detallada sobre el trabajo cuestionable) elimina el tiempo requerido de investigación para buscarlo en todo el sistema o la red; una tarea que también conlleva una carga financiera sustancial.

Cómo encontrar (y arreglar) trabajos abusivos en IBM i

Resolver trabajos ofensivos en el sistema requiere más que simplemente saber qué trabajo tiene la culpa: también debe conocer la naturaleza del incidente. Si monitorea trabajos para encontrar una ruptura en los patrones de comportamiento típicos, puede ser fácil establecer la causa y resolver el problema rápidamente, en especial, si su herramienta de monitoreo le permite establecer umbrales basados en sus niveles preferidos, y notificarlo de forma automática cuando un umbral se supera, como lo hace Robot Monitor.

El monitoreo proactivo significa que los trabajos que son culpables de tener un mal comportamiento (como por ejemplo los trabajos de servicio de base de datos QZDASOINIT) no pueden esconderse bajo un nombre genérico compartido por miles como él... y permanecer desapercibidos hasta que sean descubiertos. En cambio, a la primera señal de problemas, se recibe una alerta de inmediato y se puede resolver el incidente antes de que afecte a los usuarios.

Los trabajos QZDASOINIT abusivos típicamente demuestran condiciones excepcionales que afectan al desempeño del trabajo o el estado del trabajo. Robot Monitor monitorea en tiempo real todos estos parámetros, y cientos más, para ayudarlo a identificar qué trabajos son problemáticos y por qué.

Rendimiento del trabajo

  • Tiempo de respuesta
  • Transacciones CPU
  • Uso CPU
  • Uso interactivo CPU
  • Uso base de datos CPU
  • Faltas por segundo
  • Tiempo cerrar-esperar
  • Almacenamiento temporal por trabajo
  • Disco I/O
  • Máximo tiempo de espero en cola de trabajo
  • Tiempo promedio de espero en cola de trabajo
  • Cantidad de hebras de cada trabajo

Estado del trabajo

  • Cantidad de trabajos interactivos
  • Cantidad de trabajos
  • Cola de trabajos activa
  • Cantidad de trabajos
  • Cantidad de colas de trabajo
  • Estado del trabajo

Robot Monitor proporciona una funcionalidad integral de monitoreo de trabajos en tiempo real. Gracias a ello, es posible reducir drásticamente el riesgo de trabajos abusivos que afecten el entorno más amplio del sistema, así como los gastos posteriores que acarrean.

Robot Monitor también mejora la visibilidad y ofrece a los equipos de IT control sobre problemas en los trabajos a medida que ocurren, con alertas, escalamientos y comandos en tiempo real.

Con un control centralizado y proactivo, con Robot Monitor se puede asegurar que los trabajos de toda la red se ejecuten correctamente, controlando sus diversos componentes, creando restricciones de uso de CPU definibles por el usuario, y con información sobre los trabajos que experimentan cambios de estado repentinos o infringen los tiempos de ejecución previstos.

Detención de trabajos para hacer más productiva la vida de los usuarios

¿Lo sabía? Robot Monitor le permite controlar la prioridad de ejecución de un trabajo basándose en su uso de CPU, para que usted pueda asegurar que los recursos de su IBM i se utilizan para ejecutar los trabajos adecuados en el momento adecuado.

Debajo de una aparente calma en la superficie de un sistema IBM i, está sucediendo una especie de revuelta. Más precisamente, es una lucha por los recursos… y es inevitable. En este escenario de “supervivencia del trabajo más fuerte” hay poco espacio para el sentimentalismo.

Verá, al sistema no le importa que un trabajo de pago de nóminas sea más importante que un trabajo de impresión (pesado y rutinario). Con mucho gusto le dará a ese trabajo de impresión toda la CPU que demande, y dejará que el trabajo de pago de nóminas espere a que los recursos se encuentren disponibles, independientemente de cuánto tiempo esto pueda demorar.

Afortunadamente, Robot Monitor posee un comando que puede poner este tipo de situaciones en orden: MONCHKJCP.

Ejecutar este comando no solo le proporciona información valiosa sobre los trabajos que utilizan CPU y E/S de disco de forma excesiva, sino que también le permite obstaculizar estos trabajos cuando exceden los parámetros establecidos alrededor de su uso de CPU o espacio en disco, para despejar el camino y permitir que otros trabajos más importantes se ejecuten.

Controle el consumo de CPU

La interfaz gráfica de usuario de Robot Monitor permite configurar parámetros en la PC del usuario para gestionar cuándo deberían suceder estas acciones. Eso se hace estableciendo un límite porcentual para el uso de CPU general del sistema y el uso de CPU de ciertos trabajos seleccionados en un número definido de muestras consecutivas.

Las opciones de acciones incluyen Retener (Hold), Prioridad Inferior (Lower Priority) o Sin Acción (No Action). Los mensajes de advertencia de que han sucedido estas condiciones se pueden enviar a la cola de mensajes QSYSOPR para mantener a los operadores informados, y también pueden ser interceptados por Robot Console y escalados.

Además de poder configurar los trabajos en una PC, Robot Monitor también permite al usuario ver los detalles del monitor cuando los trabajos violan el umbral y comienzan a verse obstaculizados. En el ejemplo anterior (ejecutado en trabajos QZD * definidos que se ejecutan en el subsistema QSYSWRK), la pantalla central muestra los 10 trabajos QZDASOINIT que consumen más CPU. La prioridad de ejecución se ha cambiado a 70 en el consumidor más grande, según los parámetros del comando MONCHKJCP.

QZDASOINIT Priority Change in Robot Monitor

La configuración de Robot Monitor cuenta con muchas opciones para personalizar el comando según sus necesidades. Además del porcentaje de CPU del sistema, por ejemplo, se pueden asignar especificaciones con estas mismas condiciones antes de que se invoque a un comando, previo a que un trabajo sea liberado de su estado de detenido. Se pueden personalizar otros parámetros relacionados a programas, usuarios, subsistemas, y trabajos a incluir o excluir.

El poder y la precisión de MONCHKJCP permiten ahorrar una cantidad sustancial de tiempo que de otra manera se requeriría para investigar los problemas que surjan de estos trabajos. ¡Y eso no es todo! MONCHKJCP también le ahorrará dinero, al ayudarlo a mantener a sus usuarios productivos y felices.

Una solución rápida para resolver problemas en sus trabajos ZDASOINIT

¿Cómo hace actualmente para ver qué usuarios o procesos afectan a su entorno IBM i? ¿Qué tan rápido puede su equipo identificar posibles consultas fuera de control? ¿Cuánto costará, en términos de tiempo, pérdida de productividad y Seguridad, si un trabajo de servicio de base de datos descontrolado hace que su sistema se detenga debido a la falta de recursos?

Para las compañías usuarias de IBM i, una frustración frecuente de los equipos de IT son los trabajos de base de datos que se salen de control, y que son causados por consultas de herramientas externas de Business Intelligence (BI), o usuarios que envían y reenvían queries. Cuando estos trabajos no se detectan a tiempo, representan un riesgo significativo de pérdida total de disponibilidad del sistema, incluso en los equipos más nuevos.

QZDASOINIT no tiene por qué ser una mala palabra

Con tantos trabajos que comparten el mismo nombre, cientos de trabajos pueden contribuir a escalar el consumo de CPU. Cuanto más se demore en identificar el trabajo que tiene problemas, más CPU se consumirá y mayores serán los riesgos y el impacto en los recursos.

Los grupos monitoreados por Robot Monitor muestran el total de uso de CPU por QZDASOINIT y el uso total de CPU del sistema. Los administradores del sistema ganan visibilidad proactiva sobre este grupo, su umbral e información de contexto para hacer comparaciones. Y si usted no está frente a la pantalla de Robot Monitor, el software le enviará una notificación cuando estas cargas de trabajo se comporten de forma indebida.

Con un solo click puede acceder a una vista más detallada de los trabajos que consumen la mayor cantidad de CPU, para identificar aquellos trabajos más problemáticos al instante, sin necesidad de ejecutar búsquedas manuales en el subsistema QUSRWRK (que consumen mucho tiempo) o ejecutar WRKACTJOB.

También puede hacer click en la pestaña Sentencia SQL (SQL Statement) para ver la sentencia SQL exacta que causa que el rendimiento del sistema o aplicación caiga en picada.

Conozca todo lo que puede hacer con Robot Monitor

  • Monitoreo proactivo de trabajos QZDASOINIT fuera de control
  • Información de detalle para identificar la sentencia SQL exacta que afecta su IBM i
  • Reducción del tiempo de investigación y ahorro de recursos asociados a estas tareas
  • Protección del consumo innecesario de recursos
  • Configuración de umbrales para alertas tempranas de problemas que pueden empeorar
  • Monitoreo de QTEMP, almacenamiento temporal, CPU, y disco

¿Cuánto tiempo demoró en localizar el último trabajo QZDASOINIT que se salió fuera de control en su IBM i? Vea Robot Monitor en acción para entender cómo y por qué identificar de forma proactiva estas posibles amenazas a la disponibilidad del sistema lo puede hacer ahorrar tiempo y dinero. Conozca más sobre Robot Monitor.

Sobre HelpSystems

Más de 13.000 organizaciones de todo el mundo confían en HelpSystems para hacer más fácil la vida de los departamentos de IT y mantener sus negocios funcionando sin problemas. Nuestros productos y servicios monitorean y automatizan procesos, encriptan y protegen datos, y proporcionan un fácil acceso a la información que las personas necesitan. Conozca más en www.helpsystems.com/es.

Productos relacionados

Soluciones Relacionadas

Manténgase informado de nuestras novedades