QSystem Monitor Now Flags I/O Hungry Jobs

System Administration
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

An enhancement to its MONCHKJCP command reduces the risk of important jobs being delayed, or users affected, by jobs running at high I/O levels.

QSystem Monitor (QSM), CCSS' leading performance monitoring and reporting solution, now allows users to take action against jobs that are using excessive amounts of I/O on IBM i and Power Systems platforms. QSM’s existing MONCHKJCP command provides a powerful means for users to instantly identify and work with jobs consuming excessive amounts of CPU, the company says. The new enhancement for MONCHKJCP extends the benefits of this command and reduces the risk that important jobs may be delayed or users impacted as a direct consequence of jobs running at excessively high I/O levels. 

Jobs that could consume high I/O but not necessarily high CPU could include SQL database queries from PC to iSeries or the generic QZDASOINIT jobs. Running at a high I/O level, these types of jobs could have a detrimental impact on interactive system jobs and the process of manually identifying them individually on the system would be a considerably time consuming job for operators. Now if a job starts to exceed an acceptably defined I/O level, the MONCHKJCP command can exercise the option to hold that job, lower its priority, or send a message out to the message queues to alert operators of the potential problem before it escalates in severity. 

Configuring MONCHKJCP is now a simple PC-based task that users can carry out via QSM’s online module. As this is fully supported within the monitor, there is no longer a need for users to schedule this command. Configuration metrics for including or excluding specified programs, users, subsystems, and jobs extend to the automated response users require when these jobs are identified. In the case of high I/O jobs, users can set up the preferred course of action to be taken automatically by selecting whether to hold that job, lower its priority (again by a configurable number) and define the message queues for urgent messages and Activity Log. Users can also use the command to check for jobs that are running both high CPU and I/O levels. In this case, a user can specify both CPU and I/O values (or alternatively select any number for a broader search) and once both metrics are exceeded, the defined action will run, for example, the job in question could be hindered. 

As well as being able to set up the jobs on the PC, QSM also allows the user to show the details of the monitor when jobs start to be hindered. For example, The On-line monitor would show a bar that flashes red to alert operators to its importance. When clicked on, the bar opens up into a table showing the jobs that exceed the rules set up by the user with all the typical detailed job information and the changed run priority. Working with any one of these jobs directly is possible with a simple right-click. 

“The ease with which users can work with jobs is an area we’re always refining,” says CCSS Product Manager Paul Ratchford. "The more configurable the solution is, the more value and relevance it brings to a customer’s systems environment,” he says. A small adaptation of the High CPU Jobs window suggests that no detail has been overlooked in giving QSM users configurable monitoring and viewing capabilities. For those users that heavily rely on the High CPU data and therefore have the High CPU windows consistently active, they can now choose whether or not to view these results with a corresponding pie chart or simply the list of jobs alone. 

In complex systems environments where more than one administrator may be responsible for managing the performance of the machines, there can be instances where one person removes data definitions leaving a group within a PC configuration empty but forgets to delete the group or inform his colleague of the change. In this case, his colleague might be unaware that he is monitoring an empty group as it would resemble the standard non-threshold color (green). Typically this issue stems from a benevolent user mistake as indicated in the example above but potentially, it could also indicate a more serious security violation and as such, users should be alert to any empty group status. QSM now resolves these situations by identifying empty groups with a new value (N/A) and a new color (gray) so they can be instantly recognized and resolved.

For more information on CCSS and QSystem Monitor, visit: http://www.ccssltd.com/products/qsystem-monitor/features.php

QSystem Monitor (QSM), CCSS' leading performance monitoring and reporting solution, now allows users to take action against jobs that are using excessive amounts of I/O on IBM i and Power Systems platforms. QSM’s existing MONCHKJCP command provides a powerful means for users to instantly identify and work with jobs consuming excessive amounts of CPU, the company says. The new enhancement for MONCHKJCP extends the benefits of this command and reduces the risk that important jobs may be delayed or users impacted as a direct consequence of jobs running at excessively high I/O levels. 

Jobs that could consume high I/O but not necessarily high CPU could include SQL database queries from PC to iSeries or the generic QZDASOINIT jobs. Running at a high I/O level, these types of jobs could have a detrimental impact on interactive system jobs and the process of manually identifying them individually on the system would be a considerably time consuming job for operators. Now if a job starts to exceed an acceptably defined I/O level, the MONCHKJCP command can exercise the option to hold that job, lower its priority, or send a message out to the message queues to alert operators of the potential problem before it escalates in severity. 

Configuring MONCHKJCP is now a simple PC-based task that users can carry out via QSM’s online module. As this is fully supported within the monitor, there is no longer a need for users to schedule this command. Configuration metrics for including or excluding specified programs, users, subsystems, and jobs extend to the automated response users require when these jobs are identified. In the case of high I/O jobs, users can set up the preferred course of action to be taken automatically by selecting whether to hold that job, lower its priority (again by a configurable number) and define the message queues for urgent messages and Activity Log. Users can also use the command to check for jobs that are running both high CPU and I/O levels. In this case, a user can specify both CPU and I/O values (or alternatively select any number for a broader search) and once both metrics are exceeded, the defined action will run, for example, the job in question could be hindered. 

As well as being able to set up the jobs on the PC, QSM also allows the user to show the details of the monitor when jobs start to be hindered. For example, The On-line monitor would show a bar that flashes red to alert operators to its importance. When clicked on, the bar opens up into a table showing the jobs that exceed the rules set up by the user with all the typical detailed job information and the changed run priority. Working with any one of these jobs directly is possible with a simple right-click. 

“The ease with which users can work with jobs is an area we’re always refining,” says CCSS Product Manager Paul Ratchford. "The more configurable the solution is, the more value and relevance it brings to a customer’s systems environment,” he says. A small adaptation of the High CPU Jobs window suggests that no detail has been overlooked in giving QSM users configurable monitoring and viewing capabilities. For those users that heavily rely on the High CPU data and therefore have the High CPU windows consistently active, they can now choose whether or not to view these results with a corresponding pie chart or simply the list of jobs alone. 

In complex systems environments where more than one administrator may be responsible for managing the performance of the machines, there can be instances where one person removes data definitions leaving a group within a PC configuration empty but forgets to delete the group or inform his colleague of the change. In this case, his colleague might be unaware that he is monitoring an empty group as it would resemble the standard non-threshold color (green). Typically this issue stems from a benevolent user mistake as indicated in the example above but potentially, it could also indicate a more serious security violation and as such, users should be alert to any empty group status. QSM now resolves these situations by identifying empty groups with a new value (N/A) and a new color (gray) so they can be instantly recognized and resolved.

For more information on CCSS and QSystem Monitor, visit: http://www.ccssltd.com/products/qsystem-monitor/features.php

BLOG COMMENTS POWERED BY DISQUS