Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 11.6.0 HF5, 11.5.2, 11.4.1 HF9
Opened: May 05, 2014 Severity: 2-Critical Related Article:
K16395
When executing a chunked query (such as "show sys connection") that returns a lot of data, the primary MCP can get overwhelmed by the amount of data it is receiving from both its blade's TMMs and the secondary MCPs. It gives the data from its own TMMs priority, which eventually causes the secondary MCPs to run out of memory. At this point the MCP memory safeguards kick in and the secondary MCPs stop receiving data from their TMMs. The TMMs wait 20 seconds under these conditions, and if they have been unable to send data to MCP during that time, they exit and restart.
TMM restarts and the system is unusable during that time.
System must have multiple blades and execute a chunked query (for connection data or persistence records, for example) that returns a lot of data.
This issue has no workaround at this time.
Increased MCP's throughput by limiting the amount of data sent in a given chunk.