Last Modified: Jul 21, 2021
See more info
Known Affected Versions:
Opened: Oct 26, 2016
Related AskF5 Article: K50524736
The bigd process grows in size until one of two things happens: -- The Linux kernel runs out of memory and OOM kills the bigd process (or potentially some other large process) a few hours after the system starts up. -- On high-end platforms, the bigd process grows to just under 4GB in virtual size (vsize) and starts failing in unexpected ways, for example marking targets down that are not actually down, or failing to detect targets that are down.
A memory leak occurs. Depending on the platform, process daemons might restart or fail. Monitored targets may be incorrectly marked down. Although restarting bigd is not traffic-impacting, it is possible that other daemon processes restart due to low memory conditions, and could disrupt traffic while they restart.
-- You are running specifically BIG-IP 188.8.131.52. -- You have HTTPS monitors configured.
There is an engineering hotfix available HotFix-BIGIP-184.108.40.206.0.16.5-EHF16 :: https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=big-ip_v12.x&ver=12.1.5 To work around this, you can switch to non-HTTPS monitors until the engineering hotfix can be applied. Once you switch to non-HTTPS, restart bigd to release the leaked memory (restarting bigd should not be service impacting).
Bigd memory leak no longer occurs under these conditions.