This section explains the system capacity of the Controller.

Specifying System Capacity of Controller

During deployment of a Controller, you can specify its system capacity based on allocations of its system resources like CPU, memory (RAM) and disk. The amount of these resources allocated have a direct impact on its performance.

The following table lists recommended allocations for each type of deployment:

Deployment Type

Node Count

Recommended Allocations - CPU

Recommended Allocations -Memory

Recommended Allocations - Disk

Demo / Customer Evaluation



32 GB

128 GB



Refer to 'Allocating CPU/Memory' section below

In demonstration and deployments, a single Controller is adequate and is used for all control-plane activities and workflows, and for analytics.

In a production deployment, a three-node cluster is recommended. In a three-node Controller cluster, one Controller is the leader that is used for control-plane activities and workflows while the other two are followers. The follower nodes are used for analytics. They also provide backup in case the leader fails.

The following sections provide specific allocation recommendations that are designed to fit most use cases but might not fit every conceivable deployment scenario.


The avicontroller.service file is not updated automatically whenever CPU and memory allocation on the host is increased. Manual update of the avicontroller.service file is required whenever these values are changed.

The parameter for changing CPU is -cpu-quota.

Allocating CPU/ Memory

NSX Advanced Load Balancer uses the allocations of CPU and memory for 30.1.1 as follows:

CPU/ Memory Allocation

Essentials (4 CPUs/ 24 GB

Small (6 CPUs/ 32 GB)

Medium (10 CPUs/ 32GB

Large (16 CPUs/ 48 GB)

Base processes

15 GB

19 GB

19 GB

24 GB

Log analytics

9 GB

13 GB

13 GB

24 GB

SE Scale





The Controller’s base processes include dynamic processes and metrics collection and processing. The allocations shown here are based on assumptions of no more than 10 percent disk swapping and 25 percent disk margin.

  • The Essentials Controller size is supported starting with NSX Advanced Load Balancer release 20.1.5. But, it can only be used for a Controller deployed in the ESSENTIALS license tier with VMware Tanzu solutions and running on-premises in a VMware environment. For more information, click System Limits.

  • Essential controller can support up to 100 Virtual services. For details on scale limits for other Controller sizes, see VMware Configuration Limits guide.

  • Starting with NSX Advanced Load Balancer version 30.1.1, the minimum requirement for memory of small Controller is increased to 32 GB.

  • There is no capability for vCenter’s hot-add feature to expand the Controller virtual machine’s CPU/ memory.

Allocating Disk Capacity

The amount of disk capacity allocated to the Controller is calculated based on the following parameters:

  • The amount of disk capacity available on the Controller.

  • The number of virtual services to support.


The default Controller OVA template must be increased to 128 GB. The Controllers in the same cluster must all have the same/ similar disk capacity. Allocations of significantly different sizes must not be permitted for a prolonged time.

The following tables show recommended allocations based on each approach.

Allocating Disk based on available Disk Capacity

The disk space allocated to a Controller that is not used for base processes or analytics is used as follows:

  • Logs: 70 percent of the disk that is not used for base processes or analytics.

  • Metrics: the other 30 percent that is not used for base processes or analytics.

Disk Allocation based on Disk Space

128 GB

256 GB

512 GB

1 TB

Log analytics (70%)

56 GB

144 GB

328 GB

672 GB

Metrics (30%)

24 GB

64 GB

128 GB

288 GB

Base Processes

48 GB

48 GB

56 GB

64 GB

Disk drive quality impacts analytics performance and size:
  • Traffic logs are deleted as the disk drive fills up.

  • Metrics tables are deleted based on the archival scheme:

    • Realtime: deleted after 1 hour

    • 5-minute intervals: deleted after 1 day

    • 1-hour intervals: deleted after 1 week

    • 1-day intervals: deleted after 1 year

If the drive fills up, then current metrics tables are deleted to make room for new data.

Allocating Disk based on Number of Virtual Services

Disk allocation based on VS count

Log analytics without full logs

Log analytics with full logs


Base processes

Total (without full logs)

100 VS

16 GB

128 GB

16 GB

48 GB

80 GB

1,000 VS (100k transactions/ year)

128 GB

1 TB

32 GB

56 GB

216 GB

5,000 VS

512 GB

Not supported

160 GB

64 GB

736 GB

Metric DB Calculation in LSC

For the virtual machine form factor, the metrics quota is calculated automatically based on the size of the disk given to the virtual machine. However, for the LSC Container form factor, DISK_GB environment variable is used to calculate the quota for metrics.

The metric DB size auto calculates based on environment variable from file /etc/systemd/system/avicontroller.service where, disk_size = 30 GB (default) which is 8.38 GB allocation for Metric DB size (30%)

To get the correct metric DB size from the Controller container as follows: python3 /opt/avi/python/lib/avi/util/ -m

If Metric_DB is full, increase the disk size from HOST file to /etc/systemd/system/avicontroller.service (DISK_GB=30) and reload the daemon-reload on the HOST to increase metric_db quota.

#systemctl daemon-reload
#systemctl restart avicontroller.service

Assumptions and Sizing Data

The size recommendations shown in the table are based on the following operational assumptions:

  • DDoS attacks are less than one percent of the traffic.

  • Significant logs are no more than 10 percent of total logs. (This means 90 percent of the transactions are good and result only in non-significant logs.)

  • Log analytics require about 10 KB disk space per log entry, that is, 10 GB of disk space for one million log entries.

  • Metrics and other analytics processing require about 32 MB per virtual service. Client insights require additional drive capacity.


A transaction is a single TCP or UDP connection (layer 4) or a single request-response exchange (layer 7). A traffic volume of 100,000 transactions per year is probably low for an e-commerce site but applies to most other types of applications.