Policy Manager - Java High Memory and CPU Usage
We have upgraded our PM to 12.40 and since we have the Java CPU is running at 96% and 2.2GB of Memory.
I have restarted the server and it has not helped.
Windows Server 2012 R2
2 x CPU
I have same problem since upgrade to 12.40 on 2008 R2
CPU = 4 vCPU
MEM = 4 Gb
I've the problem since the upgrade on 31 May.
After discover the problem i've upgraded java to 1.8.0_131
Just open a support request today.
Thank you for your feedback. R&D guys are investigating provided data and we are trying to reproduce CPU load inhouse. Will update you with results once have any.
As a common notice in provided data, some affected PM instances have huge amount of Application control rules. What we can suggest at the moment is reducing the number of policy rules for unknown apps to keep only those which do not match the default action, or clean "Application Control Rules" table (OID 22.214.171.124.4.1.2126.96.36.199.20) completely. As we see in provided data, most of customers define rules to Allow for Client apps and Deny for Server ones. So, set these actions as default ones and remove all rules with same permission combination. Of course, you can set your defaults to any you prefer. Reducing the number of rules will decrease policy size and improve overall Server performance and Console responsiveness.
Also noticed that some of affected VMs running Policy Manager have a single CPU while we recommend at least two. Please increase CPUs accordingly.
Thank you for the quick answer.
I cleaned up the "Application Control Rules" table. It contained 6100 rows in total, most of then unnecessary.
It helped with the High CPU problem after waiting for a while.
But now Client Security Premium 12.31 has this different line and OID number in the LogFile.log file:
158 2017-06-06 20:51:50+03:00 -- --\-- F-Secure Management Agent 188.8.131.52.4.1.2184.108.40.206
F-Secure Management Agent failed in an internal operation. Setting the policy variable 220.127.116.11.4.1.218.104.22.168.22.214.171.124 (error=-505) was not successful. If the problem persists, please contact the system administrator.
Does this tell anything else for you?
Is this OID in any way related to this problem?
With modern Hypervisors there is no need to define such low limits.
If installed on a Windows Server OS:
2 Cores/vCPUs is ok for a System dedicated to PMS. But as soon as you run the console (PMC) on the same system and/or access it remotely (e.g. via RDS) the system is likely to suffer from CPU usage when signature updates arrive and need to be imported.
Also the additionaly recommended F-Server Security will influence CPU performance.
Finally: the new proxy for SWUP, (and later ORSP) will raise CPU usage.
I promote to raise minimum to 3 cores/vCPUs for Windows based PMS and recommended 4 cores/vCPUs.
I have same problem since upgrade to 12.40 on 2012 R2, Java 8u131
CPU = 4 vCPU
MEM = 8 Gb
Now I've uninstall Java 8u131 and reinstal FSPMS12.40 - it help for 10-20 minutes.
Curently after system start CPU goes to 70-90% Java Platform SEbinary process (no Java installed so its probebly from FSPMS enviroment)
Status Monitor is showing HTTP/HTTP/Webreporting: The operation timeout
Cant login to server, cant delete policies
Janne_M, message "Setting the policy variable 126.96.36.199.4.1.2188.8.131.52.184.108.40.206 (error=-505) was not successful" is caused by "Disallow user changes" checkbox for the specified policy. Seems like UI editor at the client ignores this flag and allows to add exclusions, but as expected can not save the policies with specified error as a side effect.
tomczaki, PM is distributed with java inside so even no need to install it separately.
CPU goes to 100% once client requests policy generation. To avoid that, make sure clients do not reach PM after the service start, for instance stop the network interface or change host module ports. Clean app control rules, distribute policies and revert network changes back. If you stopped the network interface, even no need to restart PM service once network is back, but port changes require restart.
Finally, we succeeded to identify the reason. The root cause was in Spring’s bug with data buffers, which reallocated buffer byte-by-byte if initial capacity (256K) was over. So, if BPF size exceeded this size, it caused constant buffer reallocations.
Hotfixes for PM 12.40 are ready and available at following pages:
aimutch, no, full service release is not planned.
Any chance you coudl re-release the 12.40 installer with the embedded patch. Just to avoid confusion and forcing people to update just freshly released software version.
You can ignore my post, I have not seen your reply to the identical request.
I don't see an option to remove once posted reply