Ефективно наблюдение на MySQL с табла за управление на SCUMM:част 3

В предишните си блогове обсъдихме свързаните с MySQL табла за управление. Подчертахме нещата, от които DBA може да се възползва, като изучава графиките, особено когато изпълнява ежедневните си процедури от диагностика, отчитане на показателите и планиране на капацитета. В този блог ще обсъдим InnoDB Metrics и MySQL Performance Schema, което е много важно, особено за наблюдение на InnoDB транзакции, диск/процесор/памет I/O, оптимизиране на вашите заявки или настройка на производителността на сървъра.

Този блог засяга дълбоката тема за производителността, като се има предвид, че InnoDB ще изисква широко покритие, ако се заемем с неговите вътрешни елементи. Схемата за производителност също е обширна, тъй като обхваща ядрото и основните части на MySQL и двигателите за съхранение.

Нека започнем да се разхождаме през графиките.

MySQL InnoDB метрики

Това табло за управление е страхотно за всеки MySQL DBA или ops човек, тъй като предлага много добър изглед към механизма за съхранение на InnoDB. Тук има определени графики, които потребителят трябва да вземе предвид за активиране, тъй като не във всички ситуации променливите са зададени правилно в конфигурацията на MySQL.

Innodb Checkpoint Age

Според ръководството контролната точка се дефинира по следния начин:„Тъй като се правят промени в страниците с данни, които се кешират в буферния пул , тези промени се записват във файловете с данни малко по-късно, процес, известен като зачервяване . Контролната точка е запис на последните промени (представен от LSN стойност), които са били успешно записани във файловете с данни “. Тази графика е полезна, когато искате да определите как вашият сървър изпълнява данни за контролни точки към вашия диск. Това може да бъде добра справка, ако вашият регистър на транзакциите (redo log или ib_logfile0) е твърде голям. Тази графика също е добър индикатор, ако трябва да коригирате променливи като innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct или innodb_adaptive_flushing_method. Колкото по-близо е възрастта на контролната точка до максималната възраст на контролната точка, толкова по-пълни са регистрационните файлове и InnoDB ще прави повече I/O, за да поддържа малко свободно място в регистрационните файлове. Механизмът за контролна точка се различава в фини детайли между базираните на Percona XtraDB аромати, MariaDB и версията на Oracle, можете също да намерите разлики в изпълнението му между версиите на MySQL.
Транзакции в InnoDB

Всеки път, когато във вашия MySQL сървър се извършва голяма транзакция, тази графика е добра справка. Той ще брои транзакциите, които са били създадени в определен момент, а дължината на историята (или всъщност е дължината на списъка с история, намерена в SHOW ENGINE INNODB STATUS) е броят на страниците в дневника за отмяна. Тенденциите, които ще видите тук, са добър ресурс, за да проверите дали това може да означава например, че изчистването е забавено поради много висока скорост на вмъкване на презареждане на данните или поради продължителна транзакция, или ако изчистването просто може Не продължете поради високо ниво на I/O на диска в обема, където се намира вашият $DATADIR.
Операции с редове в Innodb

За определени задачи на DBA може да искате да определите броя на изтриванията, вмъкванията, четенията и актуализираните редове. Тогава тази графика е това, което можете да използвате, за да ги проверите.
Време за заключване на ред в Innodb

Тази графика е добър ресурс за разглеждане, когато забележите, че приложението ви среща много събития за „Превишено е изчакването на заключване; опитайте да рестартирате транзакцията “. Това също може да ви помогне да определите дали може да имате индикация за използване на лоши заявки при обработка на ключалки. Това също е добра справка, която трябва да обърнете внимание, когато оптимизирате заявките си, което включва заключване на редове. Ако времето за чакане е твърде голямо, трябва да проверите бавния регистър на заявките или да изпълните pt-query-digest и да видите кои са тези подозрителни заявки, които причиняват това раздуване в графиката.
InnoDB I/O

Всеки път, когато искате да определите количеството четене на InnoDB данни, изтриване на диск, запис и запис в дневник, тази графика има това, което трябва да разгледате. Можете да използвате тази графика, за да определите дали вашите InnoDB променливи са добре настроени да се справят с вашите специфични изисквания. Например, ако имате кеш на модула за резервно копиране на батерията, но не постигате голяма част от оптималната му производителност, можете да разчитате на тази графика, за да определите дали вашите fsync() са по-високи от очакваното. След това промяната на променливата innodb_flush_method и използването на O_DSYNC може да разреши проблема.
Използване на регистрационния файл на InnoDB на час

Тази графика показва само броя байтове, записани в регистрационните файлове на InnoDB за повторно изпълнение, и растежа на вашите регистрационни файлове на InnoDB въз основа на 24-часовия диапазон от текущата дата.
Ефективност на регистриране на InnoDB

Тази графика е тясно свързана с почасовата графика за използване на лог файл на InnoDB. Трябва да използвате тази графика винаги, когато трябва да определите колко голям трябва да бъде вашият innodb_log_file_size. Можете да определите броя на байтовете, записани в регистрационните файлове за повторно изпълнение на InnoDB и колко ефективно вашият MySQL изтрива данни от памет на диск. Всеки път, когато изпитвате нужда от малко време да използвате пространството на вашия дневник за повторно изпълнение, това би означавало, че трябва да увеличите размера на вашия innodb_log_file. В този случай тази графика ще ви каже, че трябва да го направите. Въпреки това, за да разберете повече за това колко ви трябва за вашия innodb_log_file, може да има повече смисъл да проверите LSN (последователен номер на регистрационния номер) в SHOW ENGINE INNODB STATUS. Percona има добър блог, свързан с това, който е добър източник за разглеждане.
Западни блокировки на InnoDB

В определени ситуации, когато клиентът на приложението ви често изпитва блокиране или трябва да погледнете колко много вашият MySQL изпитва застой, тази графика служи за целта. Блокировките показват, че имате лош дизайн на SQL, което води до това, че транзакциите ви създават състояние на състезание, което причинява блокиране.
Избутване на състоянието на индекс

Малко предупреждение, когато гледате тази графика. Първо, трябва да определите дали вашата глобална променлива на MySQL innodb_monitor_enable е зададена на правилната стойност, която е module_icp. В противен случай ще изпитате „Без точки от данни“, както е показано по-долу:

Целта на графиката, ако има точки от данни, дефинирани като това, което имам в изходните извадки на извадката, ще предостави на DBA да пренебрегне колко добре вашите заявки се възползват с Index Condition Pushdown или ICP за кратко. ICP е страхотна функция в MySQL, която предлага оптимизация на вашите заявки. Вместо MySQL да чете пълните редове, филтрирани във вашите WHERE заявки при извличане, той ще добави повече проверки след вашите вторични индекси. Това добавя повече детайлност и спестява време, в противен случай машината трябва да чете редовете на пълната таблица, когато се базира само на филтрирания индекс и не се използва ICP. Това избягва четенето на пълните редове, съответстващи на вашите индексни кортежи, които съвпадат с вашите вторични индекси.

Позволете ми да разясня малко за тази графика, да кажем, че имам таблица с име:
```
mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
```
И има малко данни:
```
mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)
```
Когато ICP е активиран, резултатите са по-ефективни и осъществими:
```
mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)
```
отколкото без ICP,
```
mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)
```
Това е прост пример за ICP и как тази графика може да бъде от полза за DBA.
Съдържание на буферния пул на InnoDB

Когато работите с MySQL и използвате машината InnoDB, тази графика е една от най-често срещаните стойности (innodb_buffer_pool*), които трябва да настроите, за да оптимизирате производителността на MySQL. По-конкретно за съдържанието на буферния пул, той показва тенденциите за мръсни страници спрямо общото съдържание на буферния пул. Общото съдържание на буферния пул включва чистите страници освен мръсните страници. Определяйки колко ефективно вашият MySQL се справя с буферния пул, тази графика служи на своята цел.
Страници на InnoDB Buffer Pool

Тази графика е полезна, когато искате да проверите колко ефективно MySQL използва вашия InnoDB буферен пул. Можете да използвате тази графика, например, ако дневният ви трафик не запълва присвоения innodb_buffer_pool_size, това може да означава, че определени части от приложението не са полезни или не служат за никаква цел или ако зададете innodb_buffer_pool_size много високо което може да е добре, за да намалите стойността и да възстановите място в паметта си.
InnoDB Buffer Pool I/O

Когато трябва да проверите броя на страниците, създадени и записани в InnoDB таблици или четене на страници в InnoDB буферен пул чрез операции върху InnoDB таблици.
Заявки за буферен пул на InnoDB

Когато искате да определите колко ефективно вашите заявки имат достъп до буферния пул на InnoDB, тази графика служи за целта. Тази графика ще покаже тенденциите въз основа на точките от данни за това как се представя вашият MySQL сървър, когато машината InnoDB трябва често да осъществява достъп до диска (индикацията за буферния пул все още не е загрял), колко често заявките на буферния пул са обработвали заявки за четене и запис заявки.
InnoDB Read-Ahead

Когато променливата innodb_random_read_ahead е зададена на ON, тогава добавете тази графика като ценна тенденция, която да разгледате като част от вашата DBA рутина. Той показва тенденциите за това как вашата система за съхранение на MySQL InnoDB управлява буферния пул чрез фоновата нишка за четене напред, как управлява тези, които впоследствие са изгонени, без да са били достъпни от заявки, и как InnoDB инициира произволното четене напред при сканиране на заявка голяма част от таблицата, но в произволен ред.
Буфер за промяна на InnoDB

Когато работите с Percona Server 5.7, тази графика е полезна, когато наблюдавате колко добре InnoDB е разпределил буферирането на промените. Тези промени включват онези вмъквания, актуализации и изтривания, които са посочени от променлива innodb_change_buffering. Буферирането на промените помага за ускоряване на заявките, като се избягва значителен I/O произволен достъп, който би бил необходим за четене на вторични индексни страници от диска.
InnoDB промяна на буферната активност

Това е свързано с графиката на буфера за промяна на InnoDB, но разделя информацията на по-жизнеспособни точки от данни. Те предоставят повече информация за наблюдение как InnoDB обработва буферирането на промените. Това е полезно при конкретна DBA задача, за да се определи дали вашият innodb_change_buffer_max_size е настроен на твърде висока стойност, тъй като буферирането на промените споделя същата памет на буферния пул InnoDB, намалявайки паметта, налична за кеширане на страници с данни. Може да се наложи да обмислите да деактивирате буферирането на промените, ако работният набор почти се вписва в буферния пул или ако вашите таблици имат сравнително малко вторични индекси. Не забравяйте, че буферирането на промени не налага допълнителни разходи, защото се прилага само за страници, които не са в буферния пул. Тази графика е полезна и ако трябва да определите колко полезни са сливанията, ако трябва да сравните приложението си въз основа на определени заявки за конкретни сценарии. Да речем, че имате групови вмъквания, трябва да зададете innodb_change_buffering=insert и да определите дали стойностите, зададени във вашия буферен пул и innodb_change_buffer_max_size, не оказват влияние върху дисковия вход/изход, особено по време на възстановяване или бавно изключване (необходимо, ако искате да направите отказ с изискване за ниско време на престой). Освен това тази графика може да послужи за вашата цел за оценка на определени сценарии, тъй като сливането на буфера за промени може да отнеме няколко часа, когато има множество вторични индекси за актуализиране и много засегнати редове. През това време дисковият I/O се увеличава, което може да причини значително забавяне на свързаните с диск заявки.

Схема за производителност на MySQL

Схемата за производителност на MySQL е сложна тема. Това е дълго и трудно, но ще обсъдя само информация, която е специфична за графиките, които имаме в SCUMM. Има и определени променливи, които трябва да вземете предвид и да се уверите, че са зададени правилно. Уверете се, че имате вашата променлива innodb_monitor_enable =all и userstat=1, за да видите точки от данни във вашите графики. Като забележка, когато използвам думата „събитие“ тук, това не означава, че това е свързано с MySQL Event Scheduler. Говоря за конкретни събития, като например MySQL анализира заявка, MySQL чете или записва в релейния/двоичен регистрационен файл и т.н.

Тогава нека продължим с графиките.

Файл IO със схема на производителност (събития)

Тази графика извлича точки от данни, свързани с всякакви събития, възникнали в MySQL, които може да са били инструментирани за създаване на множество екземпляри на инструментирания обект (например четене на двоичен дневник или четене на файл с данни InnoDB). Всеки ред обобщава събитията за дадено име на събитие. Например, ако има инструмент за мютекс, който е създаден за всяка връзка, тогава може да има много екземпляри на това инструментирано събитие, тъй като има множество връзки. Резюменият ред за инструмента обобщава всички тези случаи. Можете да проверите тези събития в ръководството на MySQL за обобщени таблици на схемата на производителност за повече информация.
Файл със схема за изпълнение (зареждане)

Тази графика е същата като графиката „Файл IO на схемата за изпълнение (събития)“, с изключение на това, че е инструментирана въз основа на натоварването.
Файл IO със схема на производителност (байтове)

Тази графика е същата като графиката „Файл IO на схемата на производителността (събития)“, с изключение на това, че е инструментирана въз основа на размера в байтове. Например колко време е отнело конкретно събитие, когато MySQL задейства събитие wait/io/file/innodb/innodb_data_file.
Изчакване на схемата за изпълнение (събития)

Тази графика съдържа графиката с данни за всички чакания, изразходвани за конкретно събитие. Можете да проверите обобщените таблици на събитията за чакане в ръководството за повече информация.
Схема за изпълнение изчаква (зареждане)

Същото като графиката „Схема на производителността чака (събития)“, но този път показва тенденциите за натоварването.
Операции за достъп до индекс (зареждане)

Тази графика е съвкупност от всички събития за изчакване на I/O на таблицата, групирани по индекс(и) на таблица, генерирани от инструмента wait/io/table/sql/handler. Можете да проверите ръководството на MySQL относно таблицата на схемата за изпълнение table_io_waits_summary_by_index_usage за повече информация.
Операции за достъп до таблица (зареждане)

„Също като операциите за достъп до индекс (зареждане)“ графиката, това е сбор от всички събития за изчакване на вход/изход на таблицата група по таблица, генерирани от инструмента wait/io/table/sql/handler. Това е много полезно за администраторите на база данни. Например, бихте искали да проследите колко бързо е необходимо за достъп (извличане) или актуализиране (вмъкване, изтриване, актуализиране) на конкретна таблица. Можете да проверите в ръководството на MySQL относно таблицата със схемата на производителност table_io_waits_summary_by_table за повече информация.
Схема за изпълнение на SQL и външни заключвания (събития)

Тази графика е агрегиране (брои колко пъти се е случило) от всички събития за изчакване на заключване на таблицата, генерирани от инструмента за чакане/заключване/таблица/sql/ манипулатор, който е група по таблица. SQL заключването тук в графиката означава вътрешни ключалки. Тези вътрешни заключвания се четат нормално, четат се със споделени заключвания, четат с висок приоритет, четат без вмъкване, записват разрешават запис, записват едновременно вмъкване, записват отложено, записват с нисък приоритет, записват нормално. Докато външните ключалки се четат външни и записват външни. Във всяка задача на DBA това е много полезно, ако трябва да проследите и проучвате заключване на определена таблица, независимо от нейния тип. Можете да проверите таблицата table_lock_waits_summary_by_table за повече информация.
Схема за изпълнение на SQL и външни заключвания (секунди)

Същото като графиката „Схема на производителност SQL и външни заключвания (събития)“, но посочена в секунди. Ако искате да потърсите заключванията на вашата таблица въз основа на секундите, в които е задържала ключалките, тогава тази графика е вашият добър ресурс.

Заключение

InnoDB Metrics и MySQL Performance Schema са едни от най-задълбочените и сложни части в MySQL домейна, особено когато няма визуализация, която да подпомогне интерпретацията. По този начин преминаването към ръчно проследяване и разследвания може да отнеме известно време и упорита работа. Таблата за управление на SCUMM предлагат много ефективен и осъществим начин за справяне с тях и намаляване на допълнителното натоварване върху всяка рутинна задача на DBA.

В този блог научихте как да използвате таблата за InnoDB и Performance Schema, за да подобрите производителността на базата данни. Тези табла могат да ви направят по-ефективни при анализиране на ефективността.