Allocating Resources for Wallarm Node¶
The amount of memory and CPU resources allocated for the filtering node determines the quality and speed of request processing. These instructions describe the recommendations for filtering node memory allocation.
In a filtering node there are two main memory and CPU consumers:
-
Tarantool, also called postanalytics module. This is the local data analytics backend and the primary memory consumer in a filtering node.
-
NGINX is the main filtering node and reverse proxy component.
NGINX CPU utilization depends on many factors like RPS level, average size of request and response, number of custom ruleset rules handled by the node, types and layers of employed data encodings like Base64 or data compression, etc.
On average, one CPU core can handle about 500 RPS. When running in production mode, it is recommended to allocate at least one CPU core for the NGINX process and one core for the Tarantool process. In the majority of cases it is recommended to initially over-provision a filtering node, see the actual CPU and memory usage for real production traffic levels, and gradually reduce allocated resources to a reasonable level (with at least 2x headroom for traffic spikes and node redundancy).
Tarantool¶
Postanalytics uses the in-memory storage Tarantool. The Tarantool database is used to keep in a circular buffer a local copy of the data stream processed by a filtering node, including request/response headers and request bodies (but not response bodies).
To make a filtering node efficient, the database should keep at least 15 minutes of transmitted data with about 2x overhead for data serialization. Following these points, the amount of memory can be estimated by the formula:
For example, if a filtering node is handling at peak 50 Mbps of end user requests, the required Tarantool database memory consumption can be estimated as the following:
Allocating Resources in Kubernetes Ingress Controller¶
Tarantool memory is configured for the ingress-controller-wallarm-tarantool
pod using the following sections in the values.yaml
file:
-
To set up memory in GB:
-
To set up memory in CPU:
Listed parameters are set by using the --set
option of the commands helm install
and helm upgrade
, for example:
helm install --set controller.wallarm.tarantool.arena='1.0' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>
There are also other parameters required for correct Ingress controller installation. Please pass them in the --set
option too.
Allocating Resources if Using All-in-One Installer¶
The sizing of Tarantool memory is controlled using the SLAB_ALLOC_ARENA
attribute in the /opt/wallarm/env.list
configuration file. To allocate memory:
-
Open for editing the
/opt/wallarm/env.list
file: -
Set the
SLAB_ALLOC_ARENA
attribute to memory size. The value can be an integer or a float (a dot.
is a decimal separator). For example: -
Restart the Wallarm services:
Allocating Resources in Other Deployment Options¶
The sizing of Tarantool memory is controlled using the SLAB_ALLOC_ARENA
attribute in the /etc/default/wallarm-tarantool
configuration file. To allocate memory:
- Open for editing the configuration file of Tarantool:
- Set the
SLAB_ALLOC_ARENA
attribute to memory size. The value can be an integer or a float (a dot.
is a decimal separator). For example:
- Restart Tarantool:
To learn how long a Tarantool instance is capable of keeping traffic details with the current level of filtering node load, you can use the wallarm-tarantool/gauge-timeframe_size
monitoring metric.
NGINX¶
NGINX memory consumption depends on many factors. On average it can be estimated as the following:
For example:
-
Filtering node is processing at peak 10000 concurrent requests,
-
average request size is 5 kB.
The NGINX memory consumption can be estimated as follows:
To allocate the amount of memory:
-
for the NGINX Ingress controller pod (
ingress-controller
), configure the following sections in thevalues.yaml
file by using the--set
option ofhelm install
orhelm upgrade
:
Example of commands changing the parameters:
helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>
There are also other parameters required for correct Ingress controller installation. Please pass them in the
--set
option too. -
for other deployment options, use the NGINX configuration files.
Troubleshooting¶
If a Wallarm node consumes more memory and CPU than it was expected, to reduce resource usage, get familiar with the recommendations from the CPU high usage troubleshooting article and follow them.