There are several questions people ask when as a Consultant/Architect you visit them to provide services. There are environment which are adequately staffed in terms of hardware wherein there are those which are not. Sizing concerns occur in both. The local administration teams need a way out in both the cases. Of Couse, the answer is simple if you do not have enough hardware resources, part of the existing resources and workforce as a whole. The answer certainly is, buy more and better hardware which would be the key to a happy life, all in all.
However this article is specifically for environments which already have the required hardware in place. In other words, the RAM, the CPU cores, the hard disk space and everything is pretty much fallen in line. Even in that case, there are performance concerns. Ofcouse there is another known category here which is 'misconfiguration'. Yes, I'm certainly talking about environments that inspect GET traffic instead of just post and places that have policies implemented to look for all traffic irrespective of content going to certain destinations. Not to forget the inappropriate/excessive usage of wildcards. However this article is not even to cover those types.
Here's what I wish to cover under this article - Enough hardware available physically however the DLP Enforce Application/Services not configure to utilize the same effectively.
Lets start with the Signs of Symptoms of this category as a whole:
(a) Takes a long time for Enforce to load
(b) Report generation timing out or taking long
(c) Certain operations/edits timing out or taking long
(d) RSOD (Red screen of death) while performing certain operations/configuration changes
(e) Below log entries in the VontuManager.log (under debug)
•INFO | jvm 1 | 2017/01/010 07:07:27 | Exception in thread "HeartbeatCheckerTimer" com.vontu.model.DatabaseConnectionException: org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager instance could not obtain a connection
•INFO | jvm 1 | 2017/01/05 06:13:42 | line 1:71: unexpected token: null
•INFO | jvm 1 | 2017/01/05 06:57:17 | line 1:71: unexpected token: null
•INFO | jvm 1 | 2017/01/05 06:57:23 | line 1:71: unexpected token: null
•INFO | jvm 1 | 2017/01/05 07:09:27 | Caused by: org.apache.ojb.broker.PersistenceBrokerException: Used ConnectionManager instance could not obtain a connection
•INFO | jvm 1 | 2017/01/05 07:09:27 | Caused by: org.apache.ojb.broker.accesslayer.LookupException: Could not get connection from DBCP DataSource
•INFO | jvm 1 | 2017/02/04 22:40:29 | [org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl] WARN: Connection close failed
•INFO | jvm 1 | 2017/02/04 22:40:29 | Already closed.
•INFO | jvm 1 | 2017/02/04 22:40:29 | java.sql.SQLException: Already closed.
Now lets look at what seems like the Solution, that would enable us to allow more memory (heap size) for JVM in order to resolve all the above Compliants/Symptoms
Now, under Vontu\Protect\Config there is a configuration file for each service which marks the amount of RAM the heap size could use. Extend the below value to leverage some of the existing/unused hardware on the server to improve/tune performance for enforce as a whole:
# Initial Java Heap Size (in MB)
wrapper.java.initmemory = 4096
wrapper.java.maxmemory = 8192