Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1
Opened: Feb 28, 2019 Severity: 2-Critical
Tmm may core in rare circumstances
Traffic disrupted while tmm restarts.
The issue is extremely rare. It's usually associated with very low memory on a BIG-IP Virtual Edition (VE). Other and swap memory will likely appear at historic highs as the memory shortage is in Linux (not hypervisor) host 4KB page memory rather than tmm huge page memory. Possibly oom-killer events may be visible in kern logs and there may be high iowait showing on CPU detail graphs.
Try to increase free Linux host memory. If there is just insufficient memory a simple way to mitigate may be shut down VE, add a few GB to VE memory in hypervisor and start up again. The shortage of Linux host memory may possibly be due to a memory leak in process other than tmm. Usually other memory will be seen climbing steadily for some time before if a leak is present, though presentations can vary a lot.
None