MySQL Bugs: #46921: Advice for "Connection Usage Excessive" rule needs caveats and more info

Bug #46921	Advice for "Connection Usage Excessive" rule needs caveats and more info
Submitted:	25 Aug 2009 17:05	Modified:	21 Sep 2009 10:47
Reporter:	Andy Bang	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Advisors/Rules	Severity:	S3 (Non-critical)
Version:	2.1.0.1096	OS:	Any
Assigned to:	Andy Bang	CPU Architecture:	Any

Description:
From Shawn Green:

The alert for "Connection Usage Excessive" recommends raising max_connections. However if the users do raise max_connections based only on the advice of this alert, they can leave themselves in a situation where they can exhaust all RAM and SWAP and get themselves into even more trouble. This alert should only make that recommendation if they have sufficient free RAM to tolerate the additional connections. The alert could also offer the advice to ensure that the users and database applications are properly closing their connections or to lower the wait_timeout or interactive_timeout settings.

How to repeat:
1) Run rule
2) View advice

Suggested fix:
Make a note about having sufficient free RAM.  Advise that they ensure that the users and database applications are properly closing their connections or to lower the wait_timeout or interactive_timeout settings.

Andy Bang writes: 
Pushed up to revision 306.

Marcos Palacios writes: 
Patch installed in versions => 2.1.0.1099.

Marcos Palacios writes: 
Verified fixed in advisor bundle 2.1.0.1099.

An entry was added to the 2.1.0 changelog:

The alert for “Connection Usage Excessive” recommended raising max_connections. However, if the users raised max_connections based only on the advice of the alert, they could potentially exhaust all RAM and SWAP.

This alert should have made the proviso that max_connections be increased only if sufficient free RAM is available to support the additional connections. The alert should also have recommended checking that all connections are correctly closed, and suggest lowering the wait_timeout or interactive_timeout settings.