Last Modified: Nov 07, 2022
Affected Product:
See more info
BIG-IP LTM
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2
Fixed In:
13.0.0, 12.1.2 HF1, 11.6.2, 11.5.4 HF3
Opened: Jul 12, 2016
Severity: 3-Major
Related Article:
K83487582
SQL (Oracle) monitor daemon might hang with high monitoring load (hundreds of monitors). DBDaemon debug log contains messages indicating hung connection aborting and that the address in use, unable to connect.
Flapping pool members connected to SQL monitors. Frequent aborts and restarts of SQL monitor daemon.
High number of SQL (Oracle, MSSQL, MySQL, PostgresSQL) monitors. Slow SQL responses might make the condition worse.
You can mitigate this issue in the following ways: -- Reduce number of monitored pool members. -- Reduce frequency of monitor interval. -- Split monitors among multiple devices. -- Run monitors on bladed systems.
This release fixes the address-in-use issue, and contains multiple monitor improvements to handle aborts and restarts of the SQL monitor daemon as well so that the system handles hung connections without aborting.
