nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cloud Secure - max number of monitored SVMs

kombayn

Hello

I've got one agent host with 16GB of memory and 12 SVMs added to Data Collectors. Memory usage on agent is all the time above 90% so I'm wondering how many SVMs should be monitored by one agent. Is it better in my situation to add memory to the existing host or to create another agent VM and split SVMs between them?

Find more posts tagged with

Accepted answers

Ontapforrum

I couldn't find any specific number per agent, but I guess unless 'Memory utilization 'is causing any manageability issues, it should be ok.

Troubleshooting:
https://docs.netapp.com/us-en/cloudinsights/task_add_collector_svm.html#configure-the-data-collector

https://docs.netapp.com/us-en/cloudinsights/concept_cs_agent_requirements.html#additional-recommendations

All comments

Ontapforrum

I couldn't find any specific number per agent, but I guess unless 'Memory utilization 'is causing any manageability issues, it should be ok.

Troubleshooting:
https://docs.netapp.com/us-en/cloudinsights/task_add_collector_svm.html#configure-the-data-collector

https://docs.netapp.com/us-en/cloudinsights/concept_cs_agent_requirements.html#additional-recommendations

kombayn

Thanks for your answer. Although we have only twelve data collectors, the same VM is also a User Directory Collector for two domains and that might be the reason for lack of memory. After expanding RAM to 32GB memory usage felt to stable 30%

moechnig

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.