Hi,... some advice if possible.
We've recently experienced an issue whereby VERY heaviliy-hit Linux systems are showing excessively high system CPU usage when a prevention policy is included in its Security Group.
Note:
+ This CPU erformance issue is a recent discovery because this is the first time we've hit a linux system quite this hard (we're stress testing currently)
+ There are 6 CPU's in this system so it's a hefty server
+ The prevention policy is disabled (non-blocking mode currenrly)
+ If I replace the baseline policy with a non-edited Symantec "out-of-the-box" policy (such as sym_unix_targeted/_prevention), the CPU issue still exists (so that rules out a config issue).
.... however,
+ If I push the sym_unix_null policy (effectively disabling the IPS capability), the CPU issue goes away and the system runs fine..
what i've done to try and resolve this............
I've stripped the security group down one policy at a time (thereby leaving ONLY the linux baseline) and it 100% looks like any baseline used is the cause of the High system CPU woes. So it seems the IPS baseline is definitely the cause of this.
Stats I'm seeing at the Linux endpoint are (approx);
(With Prevention Policy Pushed) UserCPU=30% ; SystemCPU=70%
(With Null policy pushed) User CPU=60%; System CPU=20%
The application itself is running at approximately half-speed with the prevention policy pushed out (response times double) and the message queue in the application starts to back-up in a queue causing transactions pending issues.
Is this a case of "it is what its is"??..... i.e. the prevention policy is expected to make an impact (although I wasn;t expecting it to have this much of an impact) - does this mean the only option is to throw more resources (CPU, memory etc) at this particular system? - that won't go down well tbh so that's my last resort!!
Is there any tuning to be had? (considering I've tried out-of-the-box policies, this eliminates human error on my part).
Any advice will be very much appreciated.
Best regards,
Kev
