Technical Forum
Ask questions. Discover Answers.
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner

TMOS v14.1.2.1


We upgraded our vCMP pairs from v13.1.1.4 to v14.1.2 and got "out of memory" and "tmm reload" issue.

I spent a month with F5 support did not resolve issue. Now we have 2 core and LTM only (we removed AVR) and swap group up to 100% in couple weeks.

F5 recommend use 4 cores for LTM only. Most of pair have less then 10Mbits traffic throughput.  We are losing faith in F5 😞


Does anybody have same issue with v14 code?


F5 Employee
F5 Employee

BigIP v14.1 does use more memory that earlier versions, and in different ways, which can put some memory presssure on some deployments.

The most important figure to monitor on v14.1 is the output of /proc/meminfo, specifically the MemAvailable

# cat /proc/meminfo
MemTotal:       16434864 kB
MemFree:          903316 kB
MemAvailable:    3412708 kB   <<<<<
Buffers:          366688 kB
Cached:          2658380 kB
SwapTotal:       1023996 kB
SwapFree:        1023996 kB

MemAvailable shows the amount of memory the kernel can supply to a process when asked - is a request exceeds this value, then an Out-Of-Memory event will occur, and a process may be killed.

Swap memory is also used more aggressively in 14.1 - idle pages from memory will be moved to swap by the kernel in a way that did not occur in earlier versions, so swap is generally high.

If swap is high and MemAvailable is stable, then there is unlikely to be a problem.

If swap is high and MemAvailable is continually decreasing, then there is likely to be a problem.

If MemAvailable is low (I'd suggest under 300Mb), then I'd suggest looking at the memory allocated to tmm to see if some can be moved back to the linux host via the provisioning settings. However, with a 2-core vCMP guest (3.5Gb memory) this may still be constrained.

K26427018:  Overview of Management provisioning