5.4.6.4. Контроль Сжатия во Времени выполнения

Полная производительность приложения, ЦП и использование ввода-вывода и размер дисковых файлов являются хорошими индикаторами того, как эффективное сжатие для Вашего приложения. Этот раздел основывается на настраивающем совете производительности от Раздела 5.4.6.3, "Настраивая Сжатие для Таблиц InnoDB", и показывает, как найти проблемы, которые не могли бы подняться во время начального тестирования.

Чтобы вырыть глубже в соображения производительности для сжатых таблиц, можно контролировать производительность сжатия во времени выполнения, используя таблицы Информационной схемы, описанные в Примере 14.2, "Используя Таблицы Информационной схемы Сжатия". Эти таблицы отражают внутреннее пользование памяти и уровни сжатия, используемого повсюду.

INNODB_CMP таблица сообщает информацию о действии сжатия для каждого сжатого размера страницы (KEY_BLOCK_SIZE) в использовании. Информация в этих таблицах в масштабе всей системы: это суммирует статистику сжатия через все сжатые таблицы в Вашей базе данных. Можно использовать эти данные, чтобы помочь решить, сжать ли таблицу, исследуя эти таблицы, когда ни к каким другим сжатым таблицам не получают доступ. Это включает относительно низкие издержки на сервере, таким образом, Вы могли бы периодически запрашивать это на производственном сервере, чтобы проверить полную эффективность функции сжатия.

INNODB_CMP_PER_INDEX таблица сообщает информацию о действии сжатия для отдельных таблиц и индексирует. Эта информация более предназначается и более полезна для того, чтобы оценила эффективность сжатия и диагностировала проблемы производительности одна таблица или индексировала за один раз. (Поскольку это каждый InnoDB таблица представляется как кластерный индекс, MySQL не делает большое различие между таблицами и индексирует в этом контексте.) INNODB_CMP_PER_INDEX таблица действительно включает существенные издержки, таким образом, это является более подходящим для серверов разработки, где можно сравнить эффекты различных рабочих нагрузок, данных, и настроек сжатия в изоляции. Чтобы принять меры против наложения этих контрольных издержек случайно, следует включить innodb_cmp_per_index_enabled параметр конфигурации прежде, чем можно будет запросить INNODB_CMP_PER_INDEX таблица.

Ключевые статистические данные, чтобы рассмотреть являются числом, и количество времени потратило выполнение, сжатие и операции несжатия. Так как MySQL разделяет узлы B-дерева, когда они слишком полны, чтобы содержать сжатые данные после модификации, сравнить число "успешных" операций сжатия с числом таких операций повсюду. Основанный на информации в INNODB_CMP и INNODB_CMP_PER_INDEX таблицы и полная производительность приложения и аппаратное использование ресурса, Вы могли бы произвести изменения в своей аппаратной конфигурации, скорректировать размер пула буферов, выбрать различный размер страницы, или выбрать различный набор таблиц, чтобы сжаться.

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

Большое количество операций сжатия повсюду (по сравнению с числом INSERT, UPDATE и DELETE операции в Вашем приложении и размере базы данных), мог указать, что некоторые из Ваших сжатых таблиц обновляются слишком в большой степени для эффективного сжатия. Если так, выберите больший размер страницы, или быть более выборочными, о которых таблицах Вы сжимаетесь.

Если число "успешных" операций сжатия (COMPRESS_OPS_OK) высокий процент общего количества операций сжатия (COMPRESS_OPS), тогда система, вероятно, выполняет хорошо. Если отношение низко, то MySQL реорганизовывает, пересжатие, и разделение узлов B-дерева чаще, чем является требуемым. В этом случае избегите сжимать некоторые таблицы, или увеличение KEY_BLOCK_SIZE для некоторых из сжатых таблиц. Вы могли бы выключить сжатие для таблиц, которые заставляют число "отказов сжатия" в Вашем приложении составлять больше чем 1 % или 2 % общего количества. (Такая частота отказов могла бы быть приемлемой во время временной работы, такой как загрузка данных).