3.2.1.1.4 Race Condition Template

The race condition template imposes the highest CPU and memory overhead on the system. Use this template with care if concerned about CPU utilization.

3.2.1.2 Tuning Process Priority

The HIDS idscor process performs the CPU and memory intensive operation of executing the detection templates that process the events. For potentially better event processing throughput, one can allow the idscor process to run with a higher system priority by adjusting the process nice value (see the nice(2) man page).

3.2.1.3 Tuning the HIDS System Manager (GUI)

Because the HIDS System Manager is a Java application that can be memory and CPU intensive, it is recommended to run the HIDS System Manager on a dedicated management server. The JVM can, for example, consume over 50% CPU when a user performs operations as simple as opening a new window.

Under certain loads, such as when receiving thousands of alerts, the Java Virtual Machine (JVM)

running the GUI might log “out-of-memory” errors in /var/opt/ids/gui/guiError.log or /var/opt/ids/gui/logs/Trace.log. The fix is to increase the maximum heap size of JVM (default is 64MB) in the /opt/ids/bin/idsgui file by adding, for example, “-Xmx256m \” after the line "$JAVA_RUN \". In this example, the max heap size is set to 256MB.

3.2.2 Kernel Tuning

3.2.2.1 Tuning the Kernel Audit System (IDDS)

HIDS monitors kernel audit data, specifically system call audit records. The rate of audit data generated on a system can vary dramatically depending on the system load. On a lightly loaded system that is idle, there may be a dozen system calls a second. However on a heavily loaded system that rate can increase to thousands of system calls per second. As the number of processors on the system increases, the rate of audit data generation also increases.

The HIDS agent processes operate in user space and must read data from the kernel audit data source called IDDS. The kernel stores audit data records in a buffer until the agent process is ready to read them. If the HIDS agent process is not yet ready to read and the kernel buffer has no space left for an audit record, the kernel must make a choice: discard the data or block the process which generated the audit data until space becomes available in the buffer.

The "non-blocking mode" defines the situation where the kernel discards the data before HIDS has a chance to read it. The name "non-blocking" refers to the fact that a process executing a system call will never block if no space is available in the kernel audit buffer.

The "blocking mode" defines the situation where the kernel will suspend the process executing a system call until space becomes available in the kernel audit buffer. In blocking mode, a system call will not return until space is available in the buffer for the audit record.

HP Company Internal

Page 8 of 20