Введення у PERFORMANCE_SCHEMA
Для початку трохи теорії
Щоб уникнути наступу на граблі, які чекають вас на шляху роботи з даною схемою, зроблю невеликий екскурс у теорію. Якщо ви вже знаєте як влаштована дана схема, але поки не розумієте, як це можна застосувати, можете перейти відразу до практичної частини. По-перше.PERFORMANCE_SCHEMAє статичною. Що це означає для нас? і чому так сталося? MySQL потроху навчається на своїх помилках і після робіт наINFORMATION_SCHEMA, зокрема над поданнямINFORMATION_SCHEMA.PROCESSLIST, вони змінили схему роботи з системними уявленнями. Використання командиSHOW PROCESSLIST(і подібних до неї) може викликати зависання сервера #56299, #61186. Причина цього непорозуміння у базі #42930, у якому чітко написано, що запуск цієї команди викликає встановлення блокуванняLOCK_thread_count. Це призводить до того, що MySQL не може: підключити нову сесію, відключити відпрацював, створити новий бінарний лог і т.д. оскільки блокування даного мьютексу, є критичним для всього двигуна. Це було зроблено через можливість динамічного виділення пам'яті потоками. Для того, щоб одного разу при запиті параметрів сесій уявлення не звернулося до звільненої ділянки пам'яті, отримавши помилку і заваливши весь сервер. У вихідному кодіPERFORMANCE_SCHEMAне використовуються команди динамічного виділення пам'яті типу malloc. Виділення пам'яті здійснюється лише один раз, під час старту сервера. Тому всі параметри даної схеми неможливо змінити в runtime. З одного боку це дає можливість роботи даної схеми без блокувань, з іншого деякі проблеми з її конфігуруванням, частина з яких обходиться інструментами, включеними в самPERFORMANCE_SCHEMA ENGINE. Післязапуску ви не зможете повністю відключити цей двигун, без перезавантаження сервера. По-друге. Оскільки ця функціональність виробляє моніторинг всієї БД, природно вона споживає деякі ресурси. Обсяг споживаних ресурсів залежить від конфігурації схеми, яку можна подивитися, виконавши запит.
Перші параметри -instancesє найважливішими, саме достатня їх кількість дозволить повністю моніторити все, що відбувається з БД. Однак тут головне не перестаратися, бо пара mutex + rwlock створюється на кожен 16-ти кілобайтний блок в buffer_pool. Тобто якщо на БД виділено досить великий обсяг оперативної пам'яті, то ви вижере дофіга ресурсів, а якщо ви поставите ці параметри занадто маленькими, то ви не зможете відстежувати всі системні процеси. Як зрозуміти, що ви виставили їх коректно скажу трохи нижче. За параметрамиhandleдумаю все зрозуміло з назви. Це максимальна кількість відкритих таблиць та файлів, які ви зможете відмоніторити. Розмір параметрівsizeзалежить від навантаження на вашу БД. Її вам доведеться підбирати самостійно. Наприклад, якщо ви, запускаючи запит, не встигаєте побачити його статистику вevents_waits_history_long, то вам варто задуматися над збільшенням цього параметра. Параметриclassesза ідеєю не дуже важливі, оскільки вони показують максимальну кількість типів об'єктів, що відстежуються. Тут треба описатися на розробників плагінів. Якщо вони вважали за потрібне, включити якісь м'ютекси в моніторинг, вони зазвичай вказують їх кількість. Наприклад для движкаInnoBDтаких класів всього 35. Важливо помітити, що не треба скупитися при виставленні цих параметрів, тому що якщо ви виставите їх впритул, то при пошуку порожніх елементів масивуPERFORMANCE_SCHEMAбуде моторошногальмувати. Що за ідеєю логічно, бо знайти порожній елемент у масиві який на 90% порожній простіше ніж знайти його в масиві який на 90% повний. Отже після включенняPERFORMANCE_SCHEMAвона починає жерти ресурси … іноді дуже сильно. Наприклад, ось результат з однієї з промислових БД.
Якщо у вас є вільні 400Mb оперативної пам'яті - включайте! Повз витрати оперативної пам'яті, дана схема так само знижує швидкість виконання запитів. За деякими з оцінок, з усіма передплатниками (що розповім нижче) деградація продуктивності досягає близько 25% на читання і 19% на запис, а просто виставлення параметраperformance_schema=ONбез моніторингу будь-якої діяльності 8% на читання . А зважаючи на те, що просто так вимкнути ви її не зможете — будьте пильні. Третє, на що слід звернути увагу - це якість моніторингу. Як я вже писав вище, якщо у вас велика база даних, то ряд параметрів виставлених за замовчуванням, вам може не підійти. Дізнатися про це прикрі непорозуміння ви зможете виконавши команду
Якщо один із лічильників набуває значення вище нуля, треба збільшувати відповідний параметр. Четверте. Якщо ви вже зрозуміли, що саме вам слід моніторити, і які саме параметри за це відповідають, можна заощадити частину ресурсів системи. Сміливо запускайте update цієї таблиці.
П'яте. Якщо ви змінили параметри конфігурації, запити або провели інші оптимізації, і хочете оцінити результат – не обов'язково перезапускати сервер. Можна просто дивитись усі сумарні таблиці вPERFORMANCE_SCHEMA, для отримання свіжих результатів і годинок почекати, для накопичення статистики та очищення всіх поточних та історичних таблиць. Останнє на що хотілося б звернути увагу. При аналізі продуктивності частовиникає бажання подивитися очікування на всі події не просто в якихось абстрактних одиницях, а в живих і відчутних секундах. Це легко зробити.
З одним лише застереженням. Якщо ви працюєте в циклах процесора - то у вас максимально можливі точні значення, якщо ви перемикаєтеся на секунди, то отримаєте нехилу похибку, величина якої унікальна для кожної машини і може бути виявлена з таблиці.
З практики можу сказати, що такі (
500) оверхеди на конвертацію циклів в наносекунди, зжеруть близько 5% від часу виконання тестів. Однак я бачив машини, на яких ці оверхеди становлять більше 12%. Отже, при інтерпретації результатів у реальному часі будьте обережні.
І так із налаштуванням ми начебто розібралися. Тепер приступимо до того, де нам можна подивитися дані по навантаженню і головне як?
threads— містить посилання на процеси, які, як і раніше, живуть уINFORMATION_SCHEMA.PROCESLIST, якщо процес помер — то тред все одно буде жити, деякий час, тому якщо будете джойнитися, використовуйте зовнішнє з'єднання.events_waits_current(history,hisotry_long) — містить останні події очікування, розмір таблиць задається параметрами. Це найпотрібніша таблиця, для тих хто зіткнувся з незрозумілими блокуваннями або намагається зрозуміти яку ділянку коду гальмує, бо вона містить посилання на рядок вихідного коду.events_waits_summary- містять інформацію, що дозволяє отримати середню температуру по лікарні. Найцікавіші таблиці для адміністратора БД.file_summary— статистика щодо введення висновку, що дозволяє отримати найгарячіші таблиці. Тут необхідно розуміти, що якщо ви не виставилиinnodb_file_per_table=1при створенні БД, то нічого путнього для двигунаInnoDBвам тут побачити не вдасться. У всіх таблицях евентів, міститься так само вся інформація про введення висновку. Так як швидше за все вона буде продубльована в file_summary у більш зрозумілому вигляді - то при запитах з них краще ігнорувати event_name like 'wait/io/file/%' . З теорією начебто закінчили, перейдемо до практики. Для чого все це треба і які корисності можна отримати з цієї схеми.
Найгарячіші таблиці
На що варто звернути увагу:proc.MYD— довідник, який містить коди процедур, нічого не пишемо, багато читаємо. Варто налаштувати драйвер, щоб процедури кешувалися та увімкнути пул з'єднань.ib_logfile1- ну тут ми безсилі, це все-такиInnoDB.innodb1— або ми створювалиInnoDBтаблиці до виставленняinnodb_file_per_table=1або чекаємо MySQL 5.6 для більш детальних роз'яснень, що він туди пише.event.MYD,event.MYI— ну про якість цього продукту я вже висловлювався.tmp/#sql149f_301db7_b.frmі що з ними — ну хтось активно використовує тимчасові таблиці — треба шукати більш детальну інформацію в евентах. За подіями можна заджойниться наprocesslistі якщо вам пощастить ви зловите їх на місці злочину.job_events#P#job_events_201108.ibd— одна з найгарячіших таблиць innodb. Багато пишемо нічого не читаємо, варто подумати про архітектуру, чи всі ми правильно зробили.olap_transactions_hourly_amount.par— ну тут начебто все чесно, щогодини змінюємо партицію, рівень читань приблизно відповідає рівню запису.Це просто приклад аналізу, у вас звичайно ряду таблиць може і не бути, але на те ви і адміністратор, щоб знати що у вас робиться з кожною таблицею.
Найгарячі блокування
(інформація у цій таблиці наживий БД дуже швидко оновлюється, тому для обчислення саме середньої температури по лікарні краще використовуватиevents_waits_summary_by_thread_by_event_name, там немає конкретного рядка коду, проте там інформація більш об'єктивна, приклад наведений саме для того, щоб показати — качайте вихідники) Розрив між першим та другим місцем лякає. Ідемо у вихідники.
Висновок
Даний механізм звичайно ж не замінить нам таких улюблених трейсів у Oracle і потужності stats pack, проте вже зараз там є на що подивитися. Якщо у вас підвисає БД і ви не знаєте, з чого почати — почніть зPERFORMANCE_SCHEMA. Там завжди знайдеться купа корисної інформації, тим більше, що вже зараз Oracle не стоїть на місці і в релізі 5.6.X нам обіцяли два офіційні уявлення, які показують статистику з використання всіх таблиць та індексів (я вже зацінив, що там видається і особисто мені ця інформація здалася вкрай корисною, шукати з її допомогою відсутні або навпаки не використовуються індекси просто чудово). Що ж сподіваємось і чекаємо.
А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»