The most common reasons for seeing high CPU in Policy are:
1. Complex regex policy rules or a high number of regex policy rules are being used
Policy CPL and VPM allows you to use regex expressions to give you greater control of your search criteria. Unfortunately a ProxySG might experience high CPU in Policy depending on the complexity of the regex or the number of regex rules contained in policy. A general rule of thumb is to replace all policy rules containing regex with other rules that do not contain regex when ever possible. In CPL you can easily identify regex rules from the term "regex" in the CPL code. In VPM the terms "Regular Expression Match" or "RegEx" signifies the use of regex.
For example, using VPM if you wanted to watch www.google.com choosing the regex match (url.host.regex="www.google.com") uses more CPU cycles than choosing an exact match (url.host.exact=www.google.com).
2. Slow authentication server
High CPU might be seen if there are a number of user or group checks and the authentication server the ProxySG uses is slow. Looking at the healthcheck response times is one way to verify the response time of the authentication server. The healthchecks can be found in Statistics->Healthchecks.
3. Policy trace enabled globally or in a policy rule without narrow enough conditions set
Policy tracing is a very useful tool for troubleshooting complex policy interaction problems (amongst others), but because of the considerable increase in load it places on CPU resources it should only be enabled for either short periods of time or with conditions set in a rule that limit its application to a small proportion of total traffic.
If you are seeing high CPU in policy and a trace rule is defined or policy tracing is enabled globally, you should disable or modify the rule or disable the global tracing option.
4. Large and complex policies
Large and complex policies have been known to cause high CPU. With these sorts of policies there is no straightforward fix as each policy is going to be vastly different. What is suggested is to better understand how policy works and to do clean-up where needed.
Policy works on first rule, last layer mechanism. In Policy each rule in each layer is checked until a match is found. Then the proceeding layer and its rules are checked. Once the last layer has been checked the result is calculated. What this means is that it is a good idea to have few layers with more rules and to ensure that the most common rule to match is as close to the top as possible. This ensures the least about of policy processing as possible. Also using combined objects to obtain fewer rules will help policy processing. Lastly, if you need to have many layers then using layer guards will ensure that layers that should be checked are checked.
More details can be found in the Content Policy Reference Guide.
5. Excessive groups referenced in policy rules
If there are a great number of directory groups referenced in individual policy rules it adds more work for the CPU as the SGOS has to make additional checks for each group. We recommend minimizing the number of groups referenced per rule by creating a parent group, for example in Active Directory (AD), to include each individual group and referencing only that parent group in ProxySG policy. So for instance, if you have 100+ groups that you want to allow access to the "TV/Video Streams" Blue Coat web filtering category, you should create one group in AD which includes each of the 100+ individual groups and add only this group to the ProxySG policy rule to allow such access.
Changes to the algorithm for evaluating groups was introduced in SGOS 126.96.36.199 to reduce the impact to CPU utilization for group evaluations. You should also enable group caching (enabled by default beginning in SGOS 188.8.131.52) by entering the following CLI commands: