Description:
The MEM 3.0 documentation states in section 4.8 InnoDB Buffer Pool Usage Graphs link http://dev.mysql.com/doc/mysql-monitor/3.0/en/mem-graphs-innodb-buffer-pool.html
Caution On instances with very large buffer pools, this may take a long time to run on the MySQL Instance. It will timeout after two minutes, and prompt to retry.
Based on MEM behavior, this should be changed to something like: Caution On instances with very large buffer pools (over approximately 32 GB), this graph may not be rendered as the timeout (after two minutes) will occur before the entire buffer pool can be read. After the timeout, it will prompt to retry. However, multiple attempts may still not be successful on a busy server with a very large buffer pool.
Background:
In MEM what seems to happen when you have a large innodb buffer pool, and you try to display the Innodb buffer pool usage graph, you get a message "Unable to generate InnoDB Buffer Pool Usage report for selected MySQL Server (U0396) Please click Reload button". No matter how many times you retry, the graph never displays and you get the same error message over and over. Since we don't indicate what the innodb buffer pool approximate size limit is for successful display of the graph, users retry many times, and do not know if their buffer pool is actually too large for display or not. It would be help to be somewhat quantifiable in the docs. ( Other factors can also be in play here, for example how busy the monitored system is. )
How to repeat:
Monitor a server with a large buffer pool. In this case the buffer pool was 40 GB .Go to Reports and Graphs / InnoDB Buffer Pool Usage. Now select the MySQL Server from the Asset Selector to generate the graph.
Suggested fix:
Change documentation
Caution On instances with very large buffer pools (over approximately 32 GB), this graph may not be rendered as the timeout (after two minutes) will occur before the entire buffer pool can be read. After the timeout, it will prompt to retry. However, multiple attempts may still not be successful on a busy server with a very large buffer pool.
