F5 BIG-IP TMM High CPU: Separating Data-Plane Load from Control-Plane Bugs
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
F5 BIG-IP tmm high CPU is one of the most common escalations to network security teams managing ADC infrastructure, and one of the most frequently misdiagnosed. The tmm process runs in a CPU-pinned loop handling all forwarding, SSL, and policy decisions; at high load it legitimately consumes all available CPU on its assigned cores. The question is whether that utilization reflects real traffic growth or a software bug that is burning CPU without work to show for it. The diagnostic steps are fast once you know which counters to read. For BIG-IP high-availability issues that often accompany CPU-related incidents, see this BIG-IP DSC cluster out-of-sync troubleshooting guide.
Root Causes: Three Distinct Categories
Category 1: Data-plane traffic load. TMM CPU scales with traffic volume, SSL handshake rate, compression workload, and the complexity of applied policies. If traffic has grown or a new batch of SSL-offloaded virtual servers was added, TMM CPU increases are expected. This is not a bug; it's the system doing its job. The fix is either traffic engineering, offloading, or hardware expansion.
Category 2: iRule or policy CPU overhead. A poorly written iRule -- one that calls HTTP::uri in a STREAM iRule, loops over large tables per connection, or performs expensive string operations in CLIENT_DATA -- adds CPU cycles on every connection that hits the virtual server. The overhead appears as tmm CPU proportional to connection rate but disproportionate to traffic throughput (high CPU with low throughput is the tell).
Category 3: Control-plane bug. Specific BIG-IP software versions contain defects where control-plane operations (trust domain changes, certificate operations, HA state machine updates) drive tmm CPU without increasing data-plane load. F5 K000150524 documents one such defect: control-plane CPU spikes after device trust configuration changes. These show as tmm CPU high with stable or low traffic, and do not resolve with traffic engineering.
Diagnostics: The Right Counters to Read
Step 1: Check per-slot TMM CPU.
On a chassis system, an individual blade failure or memory pressure can produce CPU alarms that look global:
tmsh show sys tmm-info
This shows per-TMM CPU for each slot. If one slot shows 95% while others show 20%, the problem is localized to that blade. If all slots are uniformly high, the load is genuine or the bug is system-wide.
Step 2: Correlate CPU with throughput.
Compare current CPU against baseline throughput:
tmsh show sys performance throughput historical
tmsh show sys performance system historical
If CPU is 95% and throughput matches your historical peak, it's load-driven. If CPU is 95% and throughput is 20% of normal, it's either an iRule or a control-plane defect.
Step 3: Check for iRule CPU contributors.
List iRule statistics to find the top CPU consumer:
tmsh show ltm rule all-stats | grep -E 'Rule Name|CPU|Exec'
Or for a specific virtual server:
tmsh show ltm virtual my-vs detail | grep -A 5 irule
F5 article K16419 covers how to read per-iRule CPU cycles from the stats output.
Step 4: Check software version against known bugs.
If throughput is low but CPU is high and no iRule is the top consumer, search the F5 bug database for your exact version:
tmsh show sys software
Search F5 AskF5 for articles matching your version and the keywords 'tmm high cpu control plane'. K000150524 is specific to device trust changes but the diagnostic method applies broadly.
Step 5: Check SSL offload rates.
SSL handshake processing is CPU-intensive. A sudden spike in new connections (a DDoS, a session timeout flush, or a misconfigured upstream load balancer resetting connections) drives tmm CPU through SSL handshake overhead:
tmsh show sys performance ssl historical
A spike in handshakes-per-second without a corresponding traffic throughput increase indicates connection-rate abuse or a configuration change that is forcing session renegotiation.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixes by Root Cause
Fix for data-plane load: traffic engineering and offload.
If the CPU is legitimately saturated by traffic:
- Distribute load by adding a blade (chassis) or migrating virtual servers to a second appliance.
- Offload SSL to a dedicated SSL accelerator or enable TLS session resumption to reduce handshake CPU per session.
- Add a hardware security module if SSL private-key operations are the bottleneck.
- For compression: disable HTTP compression on virtual servers where the client already sends compressed content (double-compressing already-compressed streams burns CPU for no benefit).
Fix for iRule CPU: profile, rewrite, or scope-limit.
After identifying the high-CPU iRule:
- Check whether the iRule fires on events it doesn't need to. An iRule attached to
HTTP_REQUESTandHTTP_RESPONSEon a virtual server that only needsHTTP_REQUESTlogic runs twice per transaction unnecessarily. - Rewrite expensive string operations as table lookups where possible.
- Scope the iRule to only the virtual servers that actually need it. An iRule applied to 50 virtual servers but needed by 5 multiplies its overhead by 10x.
Fix for control-plane bug: patch or workaround.
For K000150524 and similar defects:
- Review the F5 bug article for the specific fix version.
- If a hotfix is not yet available, the article typically documents a workaround (often: avoiding the specific configuration operation that triggers the bug until a patch is available, or restarting a specific process).
- Open a support case with F5 TAC if no article matches your symptoms; provide the output of
tmsh show sys tmm-infoandtmsh show sys performancefrom both peak and idle periods.
Validation After Applying Fixes
Monitor CPU trend over a full traffic cycle.
Capture tmsh show sys performance system every 60 seconds for a full business day after applying a fix. BIG-IP CPU issues that appear fixed during off-peak hours frequently return at peak unless the root cause is fully resolved.
Verify iRule CPU reduction.
After scoping or rewriting a high-CPU iRule, compare the before/after iRule stats output:
tmsh show ltm rule all-stats
The CPU cycles counter for the modified iRule should be proportionally lower. If it isn't, the iRule change did not take effect (check that you saved the config and the iRule is attached to the right virtual server).
Check for secondary symptoms.
F5 high CPU is often accompanied by latency increases. After fixing the CPU issue, verify that:
- SSL session establishment times return to baseline
- Connection queue depth (shown in
tmsh show net tcpstat) drops - Any downstream application latency alerts (from APMs or APMs monitoring the virtual servers) clear
Known Failure Cases After Applying Common Fixes
Virtualized BIG-IP (VE) on over-committed hypervisor. On a VMware or KVM hypervisor where the BIG-IP VE is sharing physical CPUs with other VMs, CPU steal time appears as tmm high CPU in BIG-IP's own counters but is actually the hypervisor not scheduling the BIG-IP VMs promptly. Fix: reserve CPU resources for BIG-IP VMs using CPU pinning or reservations at the hypervisor level, not at the BIG-IP level.
Layer 4 Virtual Server without iRules still showing high CPU. A fastL4 or performance-L4 virtual server bypasses most of the per-packet processing stack and should show low CPU per-connection. If it doesn't, check whether a network firewall policy or IP intelligence feature is being applied at the virtual server or route domain level, adding per-packet lookup overhead.
CPU drops after restart but returns within hours. If a manual bigstart restart resolves the high CPU temporarily but it returns to the same level within a few hours, a software defect is accumulating state (a memory or connection table leak is a common cause). Capture tmsh show sys memory and tmsh show net connections outputs before and after restart to quantify what is growing.
When to Open an F5 TAC Case
Open a case with F5 TAC when:
- CPU is high with low throughput and no iRule is the top consumer, and you cannot find a matching bug article for your version.
- The issue recurs after a known-bug patch is applied.
- You are on a chassis and CPU is high on one blade with no corresponding traffic.
For a TAC case, collect:
tmsh show sys hardware
tmsh show sys software
tmsh show sys tmm-info
tmsh show sys performance system historical
tmsh show sys performance throughput historical
tmsh show ltm rule all-stats
tmsh show sys connection count
If the system has a qkview tool available, run qkview to generate a support snapshot that includes all of the above in one file. TAC will request this as the first step.
The bottom line
F5 BIG-IP tmm high CPU has three distinct root causes -- data-plane load, iRule or policy overhead, and control-plane bugs -- and each needs a different fix. Reading per-slot CPU with tmsh show sys tmm-info, correlating against throughput with tmsh show sys performance, and checking per-iRule statistics with tmsh show ltm rule all-stats gives you the evidence to tell them apart before applying any fix. For WAF policy tuning that often accompanies BIG-IP ADC deployments, see this WAF deployment and false-positive reduction guide.
Frequently asked questions
What causes F5 BIG-IP tmm high CPU?
BIG-IP tmm high CPU has three distinct root causes: legitimate data-plane traffic growth (the system is processing more connections, SSL handshakes, or compressed content than the hardware can sustain at the current CPU allocation), iRule or policy overhead (a poorly scoped or written iRule is adding per-connection CPU cycles disproportionate to the traffic it handles), or a control-plane software bug (specific BIG-IP versions contain defects where configuration operations drive tmm CPU without increasing data-plane load). The correct fix depends on which cause is producing the symptoms, so the diagnostic steps must be run before applying any remediation.
How do I check which process is causing high CPU on BIG-IP?
Run `tmsh show sys tmm-info` to see per-slot, per-TMM CPU breakdown. For iRule overhead, run `tmsh show ltm rule all-stats` to see CPU cycles consumed per iRule. For SSL handshake overhead, run `tmsh show sys performance ssl historical`. For overall system CPU versus TMM-specific CPU, run `tmsh show sys performance system historical` and compare the tmm line against total CPU. If tmm CPU is high but system CPU is moderate, the overhead is data-plane-specific. If system CPU is high but tmm is proportionally low, a management-plane process (sod, mcpd, tmrouted) may be the actual consumer.
How do I fix F5 BIG-IP high CPU caused by an iRule?
First, identify the specific iRule consuming the most CPU using `tmsh show ltm rule all-stats` -- sort by CPU cycles. Then check whether the iRule is attached to virtual servers that don't need it (unnecessary scope multiplies CPU consumption). Review whether the iRule fires on events it could skip: an iRule that fires on HTTP_REQUEST and HTTP_RESPONSE when only HTTP_REQUEST logic is needed runs twice per transaction. For string-heavy iRules, replace per-connection regex or table lookups with pre-computed class-match lookups where possible. After rewriting or scoping the iRule, re-run the stats to verify the CPU cycles counter decreased proportionally.
What is F5 BIG-IP control-plane high CPU and how is it different from data-plane CPU?
Data-plane CPU is the tmm workload that scales with traffic: processing connections, applying policies, offloading SSL, and forwarding packets. Control-plane CPU refers to management processes (mcpd, sod, tmrouted) that handle configuration, HA state, and routing updates. Some F5 bug articles document defects where control-plane operations, like device trust changes or certificate operations, drive tmm CPU abnormally without increasing data-plane traffic. The diagnostic tell is that control-plane-driven high CPU does not decrease when traffic is load-shed to another device, while data-plane-driven high CPU drops proportionally with the traffic moved.
Will restarting BIG-IP fix high tmm CPU?
A restart may temporarily reduce high tmm CPU if the cause is a software defect that accumulates state over time (a table leak, a runaway log process, or a connection tracking bug). However, if the root cause is not addressed, CPU returns to the same elevated level within hours of restart. A restart is not a diagnostic -- it resets counters and makes the root cause harder to identify afterward. If you need to restart to restore service, capture the full counter output (tmm-info, performance system, ltm rule all-stats) before restarting so the data is available for post-incident analysis.
How do I tell if BIG-IP tmm high CPU is caused by a software bug rather than traffic?
Compare tmm CPU against traffic throughput. Run `tmsh show sys performance throughput historical` and `tmsh show sys performance system historical`. If CPU is at 90% but throughput is at 30% of your historical peak for the same time of day, traffic growth is not the cause. Next, check for a matching F5 bug article: search the F5 AskF5 knowledge base for your exact software version combined with the keywords 'high cpu control plane'. If a matching article exists and describes your symptoms (CPU high after a specific configuration operation, CPU high without traffic), apply the documented fix or workaround. If no article matches, open an F5 TAC case with the counter outputs as evidence.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.