How much CPU and memory a Link Agent host needs depends on how many tunnels it serves and how much traffic your tests send through them. Use these recommendations when you choose a host for a new Link Agent, and when an existing agent starts to show capacity warnings in the mabl app. For the baseline system and network requirements, see Link Agent requirements.
Start from a host tier
Pick the tier that matches the tunnels and traffic you expect, then adjust with the guidance in the rest of this article.
| Tier | vCPU | Memory | Disk | Covers |
|---|---|---|---|---|
| Minimum | 2 | 4 GB | 5 GB | One tunnel, a handful of concurrent tests, up to about 150 Mb/s of traffic |
| Recommended | 4 | 8 GB | 10 GB | Several tunnels or a company-scoped tunnel, a few hundred Mb/s of sustained traffic |
| High throughput | 8 | 16 GB | 10 GB | Company-scoped tunnels serving many workspaces, 500 Mb/s and more, hundreds of concurrent connections. Pair it with a 1 Gb network connection. |
The figures in the Disk column cover the agent itself, its logs, and the version the agent was running before its last update, which it keeps in case you need to roll back an update.
Plan memory by the number of tunnels
Each tunnel runs its own process beside the Link Agent, so memory grows with the number of tunnels an agent serves, not with the number of tests. The Link Agent itself needs about 400 MB, and each tunnel needs up to about 500 MB. While an update installs, the agent briefly runs one extra tunnel process until existing connections finish, so plan for one more tunnel than you serve:
| Tunnels on the agent | Memory for the Link Agent |
|---|---|
| 1 | 1.5 GB |
| 2 | 2 GB |
| 4 | 3 GB |
| 8 | 5 GB |
Leave room for the operating system on top of these figures. A 4 GB host covers up to four tunnels. The Link Agent checks the host when it starts and logs a warning if the memory looks short for its tunnels, because the operating system may stop a tunnel process in the middle of a test when the host runs short of memory.
Plan for more memory while you migrate from legacy Link
Until your account moves to the Link 3.0 protocol, the Link Agent also carries the legacy tunnel, which can use up to 2 GB more. During that time, a 4 GB host should serve one tunnel. See Migrating from legacy Link to Link 3.0.
Plan CPU by throughput
Every connection through a tunnel is encrypted, and the encryption cost grows with the amount of traffic rather than the number of tunnels. As a guide, plan for about one CPU core for every 150 to 200 Mb/s of traffic that passes through the agent. For example, an agent that carries 800 Mb/s needs four to five cores for its tunnels.
Keep the host's CPU utilization below 75%. A tunnel that has to wait for CPU adds latency to every connection through it, which shows up as slower tests rather than as an error. The Health column on the networking page, Settings > Networking, shows a warning for an agent once its CPU, memory, or other host resources pass 80%, and a critical status past 90%.
Scale out with more agents on the same tunnel
To handle more traffic than one host can, run additional Link Agents with the same tunnel name on separate machines. mabl spreads new connections across every agent on the tunnel, so each added agent adds capacity, and the tunnel keeps working if one agent goes down.
Add an agent to a tunnel when:
- The agent's Health shows a warning for CPU or memory under normal test load.
- The agent details on Settings > Networking show that the tunnel is close to its capacity.
- Tests slow down during your busiest plan runs and recover when fewer tests run at once.
Scaling out also lets you take one agent out of service at a time, for example to patch its host, while the others keep serving the tunnel.
Raise the host's socket-buffer limits
mabl recommends raising the socket-buffer limits on every Linux and macOS host that runs a Link Agent. The default limits cap how fast a tunnel can move data over a long network path. In mabl's testing, raising them increased tunnel throughput about seven times at 100 to 250 ms of latency, and it doesn't slow down a host that is close to mabl.
The Linux and macOS installer offers to raise the limits for you, and we recommend accepting. You can also run the included script later:
sudo /opt/mabl/link-agent/bin/tuning.sh
The script raises the host-wide net.core.rmem_max and net.core.wmem_max settings on Linux, or kern.ipc.maxsockbuf on macOS, and keeps the change across reboots. Windows doesn't need this change.
These are host kernel settings, so a container can't change them for itself. If you run the Link Agent in Docker or Kubernetes, raise the limits on the container host or node.
Size containers and Kubernetes pods the same way
A containerized Link Agent needs the same CPU and memory as one on a VM. Set container memory limits to cover the tunnels the agent serves, following the memory guidance above, and avoid CPU limits below two cores. See Running mabl Link on Kubernetes for example resource settings.