Last Modified: Oct 24, 2023
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.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 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, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2, 16.1.0, 16.1.1, 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
Opened: Jan 14, 2020 Severity: 3-Major
Measurements of control-plane CPU usage indicate that the merged daemon is dominating the usage of odd-numbered CPU cores.
-- Heavy CPU use by merged may impair all other control-plane operations, even the mcpd process. -- Slow response of command-line and GUI user interfaces may be observed. -- Timeouts occur in response to REST API invocations. -- Attempts to generate qkview datasets may fail.
-- Large configuration, with thousands of defined config elements. -- Platform with large number of CPU cores (greater than 20) supporting many tmm processes.
-- To lessen the impact of the effect, perform both of the following: + Allocate additional memory for use by the control plane: # tmsh modify sys db provision.extramb value 2048 + Increase the time interval between merges from 1 second to 2. -- To discover the merge interval in use, run this command line from bash: # tmsh list sys db merged.merge.interval + If the output value is '1', you can double it: # tmsh modify sys db merged.merge.interval value 2
None