Per-CPU BPF Maps in Tetragon Cause High Memory Usage on Large Nodes

[kyledong-suse]

Is there an existing issue for this?

• [x] I have searched the existing issues

Is your feature request related to a problem?

No response

Describe the feature you would like

During an evaluation of Tetragon’s memory usage, we identified that several internal BPF maps scale linearly with the number of CPU cores. As a result, the overall memory footprint increases significantly on high-CPU nodes (32, 64, 96, 128 CPUs), especially when multiple tracing policies are active. This appears to be an unintended scalability bottleneck.

The following per-CPU maps were observed in our environment, with their corresponding memory usage per CPU core:

process_call_heap -> 25612 bytes * CPU#
ratelimit_heap -> 356 * CPU#
buffer_heap_map -> 4356 * CPU#
heap -> 4108 * CPU#
string_postfix_ -> 136 * CPU#
string_prefix_m -> 264 * CPU#
tg_ipv6_ext_heap -> 16 * CPU#
string_maps_heap -> 16388 * CPU#
data_heap -> 32772 * CPU#

The per-CPU incremental memory cost is: ~84,008 bytes per CPU

• 16 CPUs: 84,008 × 16 ≈ 1.3 MB
• 96 CPUs: 84,008 × 96 ≈ 7.7 MB

To which we need to add 0,5 MB for our policy map + probably 0.1 MB for other tetragon maps (socktrack map and ovveride map are not considered in this computation)

• 16 CPUs -> ~1.9 MB for each policy
• 96 CPUs -> ~8.3 MB for each policy

This scaling behavior can become expensive on:

• Bare-metal machines with 64–128 CPUs
• High-end EKS/AKS/GKE instance types
• Nodes running multiple policies/watchers
• Environments with dynamic or ephemeral policy usage

In these setups, a single policy can consume 5–10 MB of BPF memory, and multiple policies can push usage significantly higher.

Describe your proposed solution

No response

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[kyledong-suse]

This per-CPU map memory growth issue is also a scalability concern and should be considered part of the broader work tracked in #4191.