We get a lot of questions about limiting the CPU utilization of the log file agent. While this can be an issue with any monitoring tool (monitoring is not the main job of the system after all, so it shouldn't be hogging the processor), there is a particular issue with something like the log monitoring agent, in that it is event based. For a conventional polled ITM agent like the operating system monitoring agents, the behavior of a query for the data in a certain attribute group is generally predictable; a few system calls are made, the data is collected and returned, and it's done. The amount of work required to collect the data is basically constant, regardless of the values collected. But with the log agent, its behavior is determined by something external-- the log it is monitoring. Any amount of data can be dumped into that log at any time. This is not constrained or constant in the way that, say, checking the available swap space by the UNIX OS agent is. And once the data is received, the agent has to check it against an arbitrary, user-supplied set of regular expressions. Regular expression processing can be CPU intensive. But it is just at these times, when the monitored application itself may be having problems (which caused the burst of log data), that you do not want the monitoring to start consuming excessive CPU. So what to do?
While we are working on some new functionality for a future release to help constrain how much of the CPU the agent will use over a specified time interval, there is in fact already a feature in the existing, available releases of Tivoli Log File Agent to help with this. All operating systems that the Log File Agent runs on support a concept of process priority; some processes can take precedence over others. We can use this to ensure that the Log File Agent is not starving the application that actually matters to your business. Most operating systems do not offer a direct way to permanently assign a priority to a program, however. With systems being rebooted, processes being restarted and so on, it is impractical to keep manually resetting the priority whenever the agent starts. So the Tivoli Log File Agent has a setting of its own whereby you can tell it what priority you want it to run with, and it will set this itself, automatically, whenever it starts.
This is the "ProcessPriorityClass" setting. It goes in your .conf file, and can take values from "A" (very low priority) to "F" (very high priority-- which we most likely don't want), with "C", the default, being normal priority. So simply setting:
in the .conf file ensures that your log monitor will only run when nothing else wants to. So you may at some point see it using a high percentage of the CPU, but with this setting in place, you are assured that nothing else wanted the processor at the time, and so it is not having a negative impact on your business-critical applications. It just uses the scraps that were otherwise wasted. If your system is fairly busy, then "A" might be a bit too low. The agent could end up starved for processor time itself, and fall behind on processing events. So "B" is generally a reasonable setting.
You can ask the operating system to verify that it's working. With the .conf file setting:
If you include "Base Priority" from View->Select Columns (the last column below) the Windows Task Manager will show you:
On a Linux system, the 'N' in the 'ps' command's status column indicates that the process is being "nice", ie., running at lower priority:
# ps aux | grep kloroot 30744 1.6 3.7 176032 28180 pts/0 SNl 15:50 0:00 /opt/IBM/ITM/lx8266/lo/bin/kloagent chapeau_regex1
Other UNIX systems are similar.
So there you have it. A pretty basic, simple way to exploit the operating system's native scheduling priorities to prevent the log file agent from ever starving your actual business application of processor resource!