INSTALL PLUGIN plugin_a; 

The server detects that the 40 instruments are already defined, so no new instruments are created, and previously assigned internal memory buffers are reused. The server still has 190 instruments. 

INSTALL PLUGIN plugin_b; 

The server has room for 200-190 = 10 instruments (in this case, mutex classes), and sees that the plugin contains 20 new instruments. 10 instruments are loaded, and 10 are discarded or “lost.”  The Performance_schema_mutex_classes_lost  indicates the number of instruments (mutex classes) lost: 

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost"; +---------------------------------------+-------+ | Variable_name | Value | +---------------------------------------+-------+ | Performance_schema_mutex_classes_lost | 10 | +---------------------------------------+-------+ 1 row in set (0.10 sec) 

The instrumentation still works and collects (partial) data for plugin_b . 

When the server cannot create a mutex instrument, these results occur: 

•No row for the instrument is inserted into the setup_instruments  table. 

• Performance_schema_mutex_classes_lost  increases by 1. 

• Performance_schema_mutex_instances_lost  does not change. (When the mutex instrument is not created, it cannot be used to create instrumented mutex instances later.) 

The pattern just described applies to all types of instruments, not just mutexes. 

A value of Performance_schema_mutex_classes_lost  greater than 0 can happen in two cases: 

•To save a few bytes of memory, you start the server with -- performance_schema_max_mutex_classes= N , where N  is less than the default value. The default value is chosen to be sufficient to load all the plugins provided in the MySQL distribution, but this can be reduced if some plugins are never loaded. For example, you might choose not to load some of the storage engines in the distribution. 

•You load a third-party plugin that is instrumented for the Performance Schema but do not allow for the plugin’s instrumentation memory requirements when you start the server. Because it comes from a third party, the instrument memory consumption of this engine is not accounted for in the default value chosen for performance_schema_max_mutex_classes . 

If the server has insufficient resources for the plugin’s instruments and you do not explicitly allocate more using --performance_schema_max_mutex_classes= N , loading the plugin leads to starvation of instruments. 

If the value chosen for performance_schema_max_mutex_classes  is too small, no error is reported in the error log and there is no failure at runtime. However, the content of the tables in the performance_schema  database misses events. The Performance_schema_mutex_classes_lost status variable is the only visible sign to indicate that some events were dropped internally due to failure to create instruments. 

If an instrument is not lost, it is known to the Performance Schema, and is used when instrumenting instances. For example, wait/synch/mutex/sql/LOCK_delete  is the name of a mutex instrument in the setup_instruments  table. This single instrument is used when creating a mutex in the code (in THD::LOCK_delete ) however many instances of the mutex are needed as the server runs. In this case, 

