Google Cloud MySQL управлял Instance, используя 100% процессора в течение нескольких часовЧто это использует?

Question

В нашем экземпляре MySQL, управляемом Google Cloud, у нас есть следующая проблема:

... Как видно из рисунка, загрузка ЦП была на 100% большечем 5 часов.Это не нормально.

Пробовал - Подключен к экземпляру MySQL через Google Cloud Shell.Для выполнения show full processlist; & show processlist ... ничего интересного там нет.- Выполнено SHOW ENGINE INNODB STATUS\G;.Я не вижу проблем.- Google Stackdriver Monitoring не дает мне никакой дополнительной информации, которую я могу использовать.Точно такой же график использования процессора.

В общем, я не вижу самого экземпляра MySQL, не все в порядке.Службы, имеющие данные на экземпляре MySQL, работают как обычно.

---

Итак, как мне получить информацию о том, что на самом деле использует ЦП на нашем управляемом экземпляре MySQL?

КонечноЯ мог бы перезапустить экземпляр, и проблема, вероятно, снова исчезнет, ​​но я хотел бы углубиться в то, что здесь происходит.

---

Информация: - MySQL v5.7

---

Большое спасибо.

---

Обновление 181206

• Выполнение SHOW GLOBAL STATUS;, найти здесь -> https://pastebin.com/M67FD5Vk
• Выполнение SHOW GLOBAL VARIABLES;, найдите его здесь -> https://pastebin.com/cvsytBMY
• Используемым продуктом является решение Cloud Cloud Google Cloud, которое является управляемым экземпляром MySQL.Более подробная информация здесь -> https://cloud.google.com/sql/docs/mysql/ (кажется, я уже говорил, что это и оригинальный вопрос. Однако теперь есть ссылка и на документацию по продукту).
• Экземпляр db-n1-standard-1.Подробнее здесь -> https://cloud.google.com/sql/docs/mysql/pricing#2nd-gen-instance-pricing
• Выполнение SHOW FULL PROCESSLIST;, найти здесь -> https://pastebin.com/XNPgcBms

Answer 1

Скорость в секунду = RPS - Предложения, которые следует учитывать для ваших флагов базы данных Google Cloud

log_error=/mysql/logs/error.log  # from default of stderr will allow you to view your entries and take corrective action
max_connections=512  # from 4000 to conserve RAM and your max_used_connections was 110 in 6 days
thread_cache_size=100  # from 48 to reduce threads_created of 204 (for CPU busy reduction)
innodb_flush_neighbors=0  # from 2  you have SSD and should be using 0 per refman
innodb_lru_scan_depth=100  # from 2048 to reduce CPU busy every second
innodb_page_cleaners=4  # from 1 to expedite cleaning and reduce innodb_buffer_pool_pages_dirty of 791
open_files_limit=10000  # from 1,048,576 will conserve RAM and be adequate
query_cache_size=0  # from 1M to conserve RAM - you are NOT using QC
query_cache_limit=0  # from 1M to conserve RAM - you are NOT using QC

Требуется исследование, чтобы выяснить ПОЧЕМУ A) 56 133 aborted_clients за 6 дней B) com_stmt_prepare на 213 больше, чем com_stmt_close, то есть ресурсы былине выпускается 213 раз за 6 дней после завершения C) необходимо ли включать innodb_log_compressed_pages в свои флаги?Это приводит к тому, что часть 1 ГБ журналирования в течение 1/2 часа через файлы журнала, которые вращаются каждые 14 минут в вашей системе.

Использование нашего служебного скрипта с именем findfragtables.sql поможет вам подтвердить сжатие таблиц.и, следовательно, используя ЦП для распаковки / сжатия с каждым действием.При innodb_compression_level = 6 вы тратите много времени на процессорное сжатие.Удаление, вставка, обновление со средней скоростью 6,538 в секунду в течение 6 дней кажется чрезвычайно загруженным.

Вы можете найти мою контактную информацию в моем профиле, Сетевой профиль.

Answer 2

Попробуйте перезапустить экземпляр и посмотрите, поможет ли это.