Есть несколько переменных состояния, связанных со Схемой Производительности:

mysql> SHOW STATUS LIKE 'perf%';+------------------------------------------+-------+| Variable_name                            | Value |+------------------------------------------+-------+| Performance_schema_cond_classes_lost     | 0     || Performance_schema_cond_instances_lost   | 0     || Performance_schema_file_classes_lost     | 0     || Performance_schema_file_handles_lost     | 0     || Performance_schema_file_instances_lost   | 0     || Performance_schema_locker_lost           | 0     || Performance_schema_mutex_classes_lost    | 0     || Performance_schema_mutex_instances_lost  | 0     || Performance_schema_rwlock_classes_lost   | 0     || Performance_schema_rwlock_instances_lost | 0     || Performance_schema_table_handles_lost    | 0     || Performance_schema_table_instances_lost  | 0     || Performance_schema_thread_classes_lost   | 0     || Performance_schema_thread_instances_lost | 0     |+------------------------------------------+-------+

Переменные состояния Схемы Производительности предоставляют информацию об инструментарии, который не мог быть загружен или создан из-за ограничений памяти. У имен для этих переменных есть несколько форм:

Например, если взаимное исключение инструментуется в источнике сервера, но сервер не может выделить память для инструментария во времени выполнения, это постепенно увеличивается Performance_schema_mutex_classes_lost. Взаимное исключение все еще функционирует как объект синхронизации (то есть, сервер продолжает функционировать обычно), но данные о производительности для этого не будут собраны. Если инструмент может быть выделен, он может использоваться для того, чтобы инициализировать инструментованные взаимоисключающие экземпляры. Для одноэлементного взаимного исключения, такого как глобальное взаимное исключение, будет только один экземпляр. У других взаимных исключений есть экземпляр для каждого подключения, или на страницу в различных кэшах и буферах данных, таким образом, число экземпляров изменяется в течение долгого времени. Увеличение максимального количества соединений или максимального размера некоторых буферов увеличит максимальное количество экземпляров, которые могли бы быть выделены сразу. Если сервер не может создать приведенный инструментованный взаимоисключающий пример, он постепенно увеличивается Performance_schema_mutex_instances_lost.

Предположите, что следующие условия содержат:

Сервер выделяет взаимоисключающие инструменты для плагинов в зависимости от того, в скольких они нуждаются и сколько доступно, как иллюстрировано следующей последовательностью операторов:

INSTALL PLUGIN plugin_a

Сервер теперь имеет 150+40 = 190 взаимоисключающих инструментов.

UNINSTALL PLUGIN plugin_a;

У сервера все еще есть 190 инструментов. Все исторические данные, сгенерированные сменным кодом, являются все еще доступными, но новыми событиями для инструментов, не собираются.

INSTALL PLUGIN plugin_a;

Сервер обнаруживает, что эти 40 инструментов уже определяются, таким образом, никакие новые инструменты не создаются, и ранее присвоенные буферы внутренней памяти снова используются. У сервера все еще есть 190 инструментов.

INSTALL PLUGIN plugin_b;

Сервер имеет пространство для 200-190 = 10 инструментов (в этом случае, взаимоисключающие классы), и видит, что плагин содержит 20 новых инструментов. 10 инструментов загружаются, и 10 отбрасываются или "теряются". Performance_schema_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)

Инструментарий все еще работает и собирает (частичные) данные для plugin_b.

Когда сервер не может создать взаимоисключающий инструмент, эти результаты происходят:

Образец, только описанный, применяется ко всем типам инструментов, не только взаимным исключениям.

Значение Performance_schema_mutex_classes_lost больше чем 0 может произойти в двух случаях:

Если значение, выбранное для performance_schema_max_mutex_classes является слишком маленьким, ни о какой ошибке не сообщают в журнале ошибок и нет никакого отказа во времени выполнения. Однако, контент таблиц в performance_schema база данных пропустит события. Performance_schema_mutex_classes_lost переменная состояния является единственным видимым знаком указать, что некоторые события были отброшены внутренне из-за отказа создать инструменты.

Если инструмент не теряется, он известен Схеме Производительности, и используется, инструментуя экземпляры. Например, wait/synch/mutex/sql/LOCK_delete имя взаимоисключающего инструмента в setup_instruments таблица. Этот единственный инструмент используется, создавая взаимное исключение в коде (в THD::LOCK_delete) однако много экземпляров взаимного исключения необходимы, поскольку сервер работает. В этом случае, LOCK_delete взаимное исключение, которое для каждого подключения (THD), так, если у сервера есть 1000 соединений, есть 1000 потоков, и 1000 инструментованы LOCK_delete взаимоисключающие экземпляры (THD::LOCK_delete).

Если сервер не имеет пространство для всех этих 1000 инструментованных взаимных исключений (экземпляры), некоторые взаимные исключения создаются с инструментарием, и некоторые создаются без инструментария. Если сервер может создать только 800 экземпляров, 200 экземпляров теряются. Сервер продолжает работать, но инкременты Performance_schema_mutex_instances_lost 200, чтобы указать, что экземпляры не могли быть созданы.

Значение Performance_schema_mutex_instances_lost больше чем 0 может произойти, когда код инициализирует больше взаимных исключений во времени выполнения, чем было выделено для --performance_schema_max_mutex_instances=N.

Нижняя строка - это если SHOW STATUS LIKE 'perf%' говорит, что ничто не было потеряно (все значения являются нулем), данные Схемы Производительности точны и могут быть положены. Если что-то было потеряно, данные неполные, и Схема Производительности не могла бы записать все данное недостаточный объем памяти, который это было дано использованию. В этом случае, определенное Performance_schema_xxx_lost переменная указывает на проблемную область.

Могло бы быть уместно в некоторых случаях вызвать преднамеренное инструментальное исчерпание ресурсов. Например, если Вы не заботитесь о данных о производительности о файловом вводе-выводе, можно запустить сервер со всех параметров Схемы Производительности, связанных с набором файлового ввода-вывода к 0. Никакая память не будет выделена для связанных с файлом классов, экземпляров, или дескрипторов, и все события файла будут потеряны.

Использовать SHOW ENGINE PERFORMANCE_SCHEMA STATUS осмотреть внутреннюю операцию кода Схемы Производительности:

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G...*************************** 3. row ***************************  Type: performance_schema  Name: events_waits_history.sizeStatus: 76*************************** 4. row ***************************  Type: performance_schema  Name: events_waits_history.countStatus: 10000*************************** 5. row ***************************  Type: performance_schema  Name: events_waits_history.memoryStatus: 760000...*************************** 57. row ***************************  Type: performance_schema  Name: performance_schema.memoryStatus: 26459600...

Этот оператор предназначается, чтобы помочь DBA понять эффекты, которые различные опции Performance Schema имеют на требования к памяти. Для описания полевых значений см. Раздел 13.7.5.14,"SHOW ENGINE Синтаксис".