Forum Discussion

Sergi0's avatar
Sergi0
Icon for Nimbostratus rankNimbostratus
Nov 27, 2019

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?

  • 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