MySQL Bugs: #69992: Conflict betwee P_S and max-connections inplementations

Bug #69992	Conflict betwee P_S and max-connections inplementations
Submitted:	12 Aug 2013 9:30	Modified:	12 Aug 2013 13:15
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Performance Schema	Severity:	S3 (Non-critical)
Version:	5.5, 5.6, 5.7	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
In my understanding there is a conflict between

1) P_S implementaion
http://bugs.mysql.com/bug.php?id=68514
Marc Alf: "The performance schema allocates memory once at server start-up based on server sizing, and does not allocate memory later during the server
execution."

and
2) max-connections variable being implemented as a dynamic variable (explained at 
http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_max_connections) 

How to repeat:
Start MySQl 5.6 with --max-connections=10. 
On my system the mysqld process uses aproximately 510 MB or memory

Next execute "SET @@global.max_connections = 100000;"
Except for this single query no other queries are executed and no other clints are connected to the server.

There is no (not a single byte) additional memory allocated for the mysqld process. 

Suggested fix:
If P_S needs a fixed amount of memory for every connection that may be created, P_S memory allocation should change when max-connections change at runtime.

I am not sure though what problems it may create (if any) though. Anywax max-connection was incremented with a factor 1000 in this example. As per explanations already given it looks inconsistent to me that you can increase max-connections like this and memory stays constant.

The 'perf%lost' global status counters will just increase faster. You might say similar for table cache?  This is working as designed.

http://marcalff.blogspot.com/2013/04/on-configuring-performance-schema.html
"Monitor sizing problems"