The Cloud Secure agent is a Java service. The JVM's memory allocation is set to a fixed range at startup. The range is determined by the install script based on the VM's memory size at install time. Lately, our acquisition unit type software has used a fixed range, meaning that the -Xmx and -Xms parameters are set to the same value. From the OS perspective, the JVM will malloc that much memory when it starts, and neither malloc nor free memory until it exits. And it will allocate itself the same amount of memory regardless of how many SVMs are being monitored. Within the JVM, Java memory management will take care of distributing that pool of memory among the various tasks that the service is performing. As that memory pool comes under pressure, Java garbage collection will use an increasing amount of CPU as it tries to find available memory blocks within that pool.
By running the installer, then subsequently increasing the VM's memory size, you're guaranteeing that the added VM memory will not be used. If you have a management policy of ensuring that VM memory utilization remains below some low threshold (and it sounds like you do), this may be appropriate. If you don't have such a policy, you would raise the amount of work that VM could do before coming under memory pressure by finding and increasing the -Xmx and -Xms parameters for the agent service. (On Windows, this is in the registry; on Linux it's in a file somewhere.) Or, you could reduce the cost of the VM by returning it to the memory configuration it had at installation time.
Monitor the VM's CPU utilization to know whether you're approaching the maximum amount of work it can do.
