Download to read offline
![∙ SHOW SLAVE STATUS
∙ SHOW [GLOBAL] STATUS
∙ Производительность замедляется при
параллельном использовании
∙ Bug #42930
исправлен в 5.7.0
Обновляйтесь!
Внутренние блокировки
20](https://image.slidesharecdn.com/svetasmirnovamysqlmonitoringbestpracticesv2-170607203618/75/MySQL-36-2048.jpg)
![∙ SHOW SLAVE STATUS
∙ SHOW [GLOBAL] STATUS
∙ Information Schema
Внутренние блокировки
20](https://image.slidesharecdn.com/svetasmirnovamysqlmonitoringbestpracticesv2-170607203618/75/MySQL-37-2048.jpg)
![∙ SHOW SLAVE STATUS
∙ SHOW [GLOBAL] STATUS
∙ Information Schema
∙ Binary log
Внутренние блокировки
20](https://image.slidesharecdn.com/svetasmirnovamysqlmonitoringbestpracticesv2-170607203618/75/MySQL-38-2048.jpg)
![∙ Таблицы в P_S: statements и stages
∙ Slow query log
# Time: 170429 4:54:55
# User@Host: rit[rit] @ sveta.ritfest.ru [192.168.0.4] Id: 9841
# Schema: rit Last_errno: 0 Killed: 0
# Query_time: 24.104919 Lock_time: 0.000185 Rows_sent: 1844819
Rows_examined: 1844819 Rows_affected: 0
# Bytes_sent: 322273552
SET timestamp=1493438095;
SELECT data FROM usertable WHERE YCSB_KEY = ’user100040185076507112’;
Оптимизация запросов: встроенные инструменты
30](https://image.slidesharecdn.com/svetasmirnovamysqlmonitoringbestpracticesv2-170607203618/75/MySQL-59-2048.jpg)
Uploaded bySveta Smirnova
Мониторинг и отладка MySQL: максимум информации при минимальных потерях
Документ освещает подходы к мониторингу и отладке MySQL, подчеркивая необходимость балансировки между получением максимально возможной информации и минимизацией затрат. Обсуждаются инструменты для диагностики и их влияние на производительность, а также важность настройки логирования. В заключение предлагаются рекомендации по оптимизации мониторинга, включая использование встроенных инструментов и стратегий по управлению логами в зависимости от нагрузки.
More Related Content
Similar to Мониторинг и отладка MySQL: максимум информации при минимальных потерях
![Introduction into MySQL Query Tuning for Dev[Op]s](https://cdn.slidesharecdn.com/ss_thumbnails/qtdevops-210717011329-thumbnail.jpg?width=640&height=640&fit=bounds)
![Introduction to MySQL Query Tuning for Dev[Op]s](https://cdn.slidesharecdn.com/ss_thumbnails/qtdevops-191005204425-thumbnail.jpg?width=640&height=640&fit=bounds)
Мониторинг и отладка MySQL: максимум информации при минимальных потерях
- 1. Мониторинг и отладкаMySQL Максимум информации при минимальных потерях 6 июня 2017 года Света Смирнова
- 2.
- 3. ∙Введение: конфликт желанийи возможностей ∙Почему мониторинг - это дорого? ∙Как найти "золотую середину"? ∙Включаем по требованию ∙Итоги Содержание 3
- 4. Введение: конфликт желанийи возможностей
- 5. ∙ При возникновенияпроблемы нам нужно Желания 5
- 6. ∙ При возникновенияпроблемы нам нужно ∙ Kак можно больше информации Желания 5
- 7. ∙ При возникновенияпроблемы нам нужно ∙ Kак можно больше информации ∙ Для диагностики конкретного случая Желания 5
- 8. ∙ При возникновенияпроблемы нам нужно ∙ Kак можно больше информации ∙ Для диагностики конкретного случая ∙ Сайт не должен замедлиться ни на наносекунду Желания 5
- 9. ∙ Почти любоймониторинг - это дорого Возможности 6
- 10. ∙ Почти любоймониторинг - это дорого ∙ Стоит задуматься о ∙ Памяти ∙ Месте на диске ∙ Процессорном времени ∙ Всём сразу Возможности 6
- 11.
- 12.
- 13. ∙ Instruments: "счётчики" ∙Блокировки ∙ Временные таблицы ∙ Потраченное время ∙ ... Тестируем: Performance Schema 9
- 14. ∙ Instruments: "счётчики" ∙Consumers ∙ Таблицы, хранящие данные ∙ В памяти ∙ Размер настраивается Тестируем: Performance Schema 9
- 15. ∙ Instruments: "счётчики" ∙Consumers ∙ Instruments и Consumers ∙ Можно включать по требованию Тестируем: Performance Schema 9
- 16. ∙ Percona-Server-5.7.17-13 ∙ СтандартныйOLTP SysBench тест: for i in ‘echo 1 2 4 8 16 32 36 64 72 128 144 256 512 1024‘ do echo $i LD_PRELOAD=/data/sveta/5.7.17/lib/mysql/libjemalloc.so /data/sveta/sbkk/bin/sysbench --test=/data/sveta/sysbench/sysbench/tests/db/oltp_prepared.lua --db-driver=mysql --oltp-tables-count=8 --oltp-table-size=10000000 --mysql-table-engine=$engine --mysql-user=msandbox --mysql-password=msandbox --mysql-socket=/tmp/mysql_sandbox5717.sock --num-threads=$i --max-requests=0 --mysql-db=$db --max-time=300 --percentile=0 run >> $engine-oltp-prepared-$suffix.log done Тестируем: встроенные инструменты 10
- 17.
- 18.
- 19.
- 20. Performance Schema: умолчания,MDL и Память 14
- 21. Почему мониторинг -это дорого?
- 22. ∙ General илиbinary query log может занять всё свободное место на диске Логи требуют дискового пространства 16
- 23. ∙ General илиbinary query log может занять всё свободное место на диске ∙ Что делать при нагрузке 40GB/час только на запись? Логи требуют дискового пространства 16
- 24. ∙ General илиbinary query log может занять всё свободное место на диске ∙ Что делать при нагрузке 40GB/час только на запись? ∙ Rotate policy Логи требуют дискового пространства 16
- 25. ∙ Performance Schema ∙ Требуетвыделенной памяти Память 17
- 26. ∙ Performance Schema ∙ Требуетвыделенной памяти ∙ Память выделяется 5.7: При первом использовании 5.6: При старте Не освобождается Память 17
- 27. ∙ Performance Schema ∙ Требуетвыделенной памяти ∙ Память выделяется Не освобождается ∙ Размер таблиц history ограничен Память 17
- 28. ∙ Performance Schema ∙ Требуетвыделенной памяти ∙ Память выделяется Не освобождается ∙ Размер таблиц history ограничен ∙ Information Schema Память 17
- 29. ∙ Performance Schema ∙ Требуетвыделенной памяти ∙ Память выделяется Не освобождается ∙ Размер таблиц history ограничен ∙ Information Schema ∙ Некоторые запросы требуют чересчур много Память 17
- 30. ∙ Performance Schema ∙ Требуетвыделенной памяти ∙ Память выделяется Не освобождается ∙ Размер таблиц history ограничен ∙ Information Schema ∙ Некоторые запросы требуют чересчур много ∙ bug #72322 Исправлен в 5.5.44, 5.6.25, 5.7.8, 8.0 Обновитесь! Память 17
- 31. ∙ Performance Schema ∙ Работаетза счёт кода, срабатывающего при каждом вызове исследуемой функции CPU usage 18
- 32. ∙ Performance Schema ∙ Работаетза счёт кода, срабатывающего при каждом вызове исследуемой функции ∙ Каждый анализируемый участок кода вызывает срабатывание ещё одного вызова CPU usage 18
- 33. ∙ Performance Schema ∙ Работаетза счёт кода, срабатывающего при каждом вызове исследуемой функции ∙ Каждый анализируемый участок кода вызывает срабатывание ещё одного вызова ∙ Binary log ∙ при использовании sync_binlog добавляются дополнительные вызовы fsync CPU usage 18
- 34. ∙ ProxySQL идругие proxy ∙ Дополнительный слой Сеть 19
- 35. ∙ SHOW SLAVESTATUS ∙ 5.6: SHOW SLAVE STATUS NONBLOCKING Только Percona Server! ∙ WL #6402 в 5.7 Внутренние блокировки 20
- 36. ∙ SHOW SLAVESTATUS ∙ SHOW [GLOBAL] STATUS ∙ Производительность замедляется при параллельном использовании ∙ Bug #42930 исправлен в 5.7.0 Обновляйтесь! Внутренние блокировки 20
- 37. ∙ SHOW SLAVESTATUS ∙ SHOW [GLOBAL] STATUS ∙ Information Schema Внутренние блокировки 20
- 38. ∙ SHOW SLAVESTATUS ∙ SHOW [GLOBAL] STATUS ∙ Information Schema ∙ Binary log Внутренние блокировки 20
- 39. ∙ Как правило используютте же инструменты ∙ STATUS Variables ∙ MySQL и системные логи ∙ Performance Schema Приложения с графическим интерфейсом 21
- 40. ∙ Как правило используютте же инструменты ∙ STATUS Variables ∙ MySQL и системные логи ∙ Performance Schema ∙ Имеют те же ограничения Приложения с графическим интерфейсом 21
- 41. Как найти "золотуюсередину"?
- 42. Нельзя взять изапуститься без логов вообще! 23
- 43. ∙ MySQL errorlog Начинаем с минимально неоходимого 24
- 44. ∙ MySQL errorlog ∙ Журналы операционной системы Начинаем с минимально неоходимого 24
- 45. ∙ General, slowquery log файлы Кое-что можно включать по требованию 25
- 46. ∙ General, slowquery log файлы ∙ InnoDB Monitors Кое-что можно включать по требованию 25
- 47. ∙ General, slowquery log файлы ∙ InnoDB Monitors ∙ Consumers в Performance Schema ∙ Performance Schema уже включена Кое-что можно включать по требованию 25
- 48. ∙ General, slowquery log файлы ∙ InnoDB Monitors ∙ Consumers в Performance Schema ∙ Performance Schema уже включена ∙ Data collection при помощи pt-stalk Кое-что можно включать по требованию 25
- 49.
- 50. ∙ General query/Auditlog Динамически 27
- 51. ∙ General query/Auditlog ∙ Slow query log Динамически 27
- 52. ∙ General query/Auditlog ∙ Slow query log ∙ InnoDB Monitors Динамически 27
- 53. ∙ General query/Auditlog ∙ Slow query log ∙ InnoDB Monitors ∙ Performance Schema instruments и consumers Динамически 27
- 54. ∙ Error log Требуетсяперезапуск 28
- 55. ∙ Error log ∙Binary log Требуется перезапуск 28
- 56. ∙ Error log ∙Binary log ∙ Performance Schema Требуется перезапуск 28
- 57. ∙ Оптимизация В зависимостиот задачи 29
- 58. ∙ Таблицы вP_S: statements и stages mysql> SELECT THREAD_ID TID, SUBSTR(SQL_TEXT, 1, 50) SQL_TEXT, ROWS_SENT RS, -> ROWS_EXAMINED RE,CREATED_TMP_TABLES,NO_INDEX_USED,NO_GOOD_INDEX_USED -> FROM performance_schema.events_statements_history -> WHERE NO_INDEX_USED=1 OR NO_GOOD_INDEX_USED=1G ********************** 1. row ********************** TID: 10124 SQL_TEXT: select emp_no, first_name, last_name from employee RS: 97750 RE: 397774 CREATED_TMP_TABLES: 0 NO_INDEX_USED: 1 NO_GOOD_INDEX_USED: 0 ... Оптимизация запросов: встроенные инструменты 30
- 59. ∙ Таблицы вP_S: statements и stages ∙ Slow query log # Time: 170429 4:54:55 # User@Host: rit[rit] @ sveta.ritfest.ru [192.168.0.4] Id: 9841 # Schema: rit Last_errno: 0 Killed: 0 # Query_time: 24.104919 Lock_time: 0.000185 Rows_sent: 1844819 Rows_examined: 1844819 Rows_affected: 0 # Bytes_sent: 322273552 SET timestamp=1493438095; SELECT data FROM usertable WHERE YCSB_KEY = ’user100040185076507112’; Оптимизация запросов: встроенные инструменты 30
- 60. ∙ Query Analyticsв PMM Оптимизация запросов: графические 31
- 61. ∙ Query Analyticsв PMM ∙ Advice for SQL in Solarwinds ∙ Query Analyzer (QUAN) в MEM ∙ Queries in VividCortex ∙ Другие Оптимизация запросов: графические 31
- 62. ∙ InnoDB Monitors Оптимизация приложенияв целом 32
- 63. ∙ InnoDB Monitors ∙ Performance Schema Оптимизацияприложения в целом 32
- 64. ∙ InnoDB Monitors ∙ Performance Schema ∙Сбор данных при необходимости ∙ Запущенные вручную SHOW SELECT ... FROM INFORMATION_SCHEMA ∙ pt-stalk Оптимизация приложения в целом 32
- 65. ∙ InnoDB Monitors ∙ Performance Schema ∙Сбор данных при необходимости ∙ Запущенные вручную SHOW SELECT ... FROM INFORMATION_SCHEMA ∙ pt-stalk ∙ Графические ∙ OpenSource: PMM ∙ Коммерческие Оптимизация приложения в целом 32
- 66. ∙ Оптимизация ∙ Запросов ∙ Приложенияв целом ∙ Блокировки В зависимости от задачи 33
- 67. ∙ P_S MDLtables Блокировки 34
- 68. ∙ P_S MDLtables ∙ InnoDB Monitors Блокировки 34
- 69. ∙ P_S MDLtables ∙ InnoDB Monitors ∙ innodb_print_all_deadlocks Блокировки 34
- 70. ∙ Оптимизация ∙ Запросов ∙ Приложенияв целом ∙ Блокировки ∙ Крэши В зависимости от задачи 35
- 71.
- 72. ∙ Core dumps ∙General query log Крэши 36
- 73. ∙ Core dumps ∙General query log ∙ Audit log Крэши 36
- 74. ∙ Core dumps ∙General query log ∙ Audit log ∙ Binary log ∙ Только команды, изменяющие данные ∙ Крэш может быть вызван и SELECT-ом Крэши 36
- 75. ∙ Оптимизация ∙ Запросов ∙ Приложенияв целом ∙ Блокировки ∙ Крэши ∙ Неожиданное поведение В зависимости от задачи 37
- 76. ∙ General querylog Неожиданное поведение 38
- 77. ∙ General querylog ∙ Binary log ∙ Только для непредвиденных данных в базе Неожиданное поведение 38
- 78.
- 79. ∙ MySQL errorlog ∙ Системные логи Всегда включено 40
- 80. ∙ P_S ∙ InnoDBMonitors ∙ General, slow, binary log Включаем по требованию 41
- 81. ∙ mysqld-option-tables.html ∙ PerconaToolkit ∙ PMM ∙ MySQL Enterprise Monitor ∙ Interactive Demo for SolarWinds ∙ VividCortex ∙ MONYOG Дополнительная информация 42
- 82.
- 83.