High CPU consumption peaks in SmartEvent

[Matlu]

Hello, everyone.

I have a SmartEvent in version R81.10, which for certain periods of time, is "triggered" in terms of CPU consumption, when I check the "cpview", we observe all CPUs collapsed.

I have checked the processes of the equipment, and what "stands out" is the consumption by processes such as "java", "log_indexer", "lea_session", "cpview", "cp_indexer" and "lea_session".

Can this be considered an "expected behavior"?

Thanks for your comments. 🙂

[HeikoAnkenbrand]

Hi @Matlu,

My first idea would be that the log indexer and the SmartEvent correlation unit are overloaded.
Too many logs are being processed by both processes. I would reduce the logging.

cpsead =           Responsible for Correlation Unit functionality. Only available on servers with SmartEvent enabled.
                           Take a look at the following logs: $RTDIR/log/cpsead.elg

log_indexer =  The Log_Indexer (INDEXER) correlates and stores log data in index files. Responsible for indexing
                           (correlating) log files. Take a look at the following logs: $RTDIR/log_indexer/log/log_indexer.elg

java  =                Here you have to take a closer look at which process it is exactly (could be the CPM or Solr process).
                           (You can find more on this topic in the following sk115557)
                           Take a look at the following logs: $FWDIR/log/cpm.elg*

lea_sessions =  FWD process (Log Server) consumes CPU/memory at high level on SMS when LEA clients are connected to it.
                            FWD daemon might be busy with both writing the information to log file and forwarding this information
                            to SmartEvent/SmartReporter or any other 3rd party LEA client (such as "Arcsight") via LEA session.

[Matlu]

Hello,

Thanks for the details.

It can be considered "normal" that the CPU resource of a SmartEvent, is "intermittent", at times during the day, it is less than 85%, but at other times, the CPU exceeds 85%.

I have the impression that this can be considered "normal"

[HeikoAnkenbrand]

Hi @Matlu,

Yes that is normal but can also have reasons:
1) Too many logs are processed by the log_indexer and the SmartEvent correlation engine.
     -> Reduce the number of log entries in the rulebase if necessary
2) If it is a virtual SMS, you can use more CPU cores if necessary. 
3) On virtual systems, the physical cores can be used by several VM instances. 
    -> Assign fixed cores to the SMS VM instance that are not used by other VMs.
4) Sometimes the file access - logging - on hard disks also generate high I/O rates, that slow down the cores and processes.
    -> Check for virtual systems and open server if the SMS uses fast HD's.

These basic points can increase the performance of the SMS.

[PhoneBoy]

Yes, this is normal.

You will notice that the java and log_indexer processes are priority 39, which is actually the lowest priority.
This means these processes will "back off" if something else needs the CPU.
Which means even though the CPU usage is high, CPU will be made available to other processes that need it.