Лошата производителност на заявките е най-често срещаният проблем, с който трябва да се справят DBA. Има много начини за събиране, обработване и анализиране на данните, свързани с ефективността на заявката - ние разгледахме един от най-популярните инструменти, pt-query-digest, в някои от предишните ни публикации в блога:
Станете серия блогове на MySQL DBA
- Анализиране на вашето SQL работно натоварване с помощта на pt-query-digest
- Анализ на натоварването на SQL задълбочено с помощта на pt-query-digest
Когато използвате ClusterControl обаче, това не винаги е необходимо. Можете да използвате наличните данни в ClusterControl, за да разрешите проблема си. В тази публикация в блога ще разгледаме как ClusterControl може да ви помогне да решите проблеми, свързани с производителността на заявките.
Може да се случи, че една заявка не може да бъде изпълнена навреме. Заявката може да е заседнала поради някои проблеми със заключване, може да не е оптимална или да не е индексирана правилно или може да е твърде тежка за завършване за разумен период от време. Имайте предвид, че няколко неиндексирани обединения могат лесно да сканират милиарди редове, ако имате голяма производствена база данни. Каквото и да се случи, заявката вероятно използва някои от ресурсите - било то CPU или I/O за неоптимизирана заявка или дори само заключване на редове. Тези ресурси са необходими и за други заявки и това може сериозно да забави нещата. Една от много прости, но важни задачи би била точно да се определи виновната заявка и да се спре.
Това се прави доста лесно от интерфейса на ClusterControl. Отидете в раздела Монитор на заявки -> секцията Изпълняващи заявки - трябва да видите изход, подобен на екранната снимка по-долу.
Както можете да видите, имаме купчина запитвания. Обикновено обидната заявка е тази, която отнема много време, може да искате да я убиете. Може също да искате да го проучите допълнително, за да сте сигурни, че сте избрали правилния. В нашия случай ясно виждаме SELECT ... FOR UPDATE, което свързва няколко таблици и което е в състояние „Изпращане на данни“, което означава, че обработва данните за последните 90 секунди.
Друг тип въпроси, на които DBA може да се наложи да отговори, е - кои заявки отнемат най-много време за изпълнение? Това е често срещан въпрос, тъй като такива заявки могат да бъдат ниско висящи плодове - те могат да бъдат оптимизирани и колкото повече време за изпълнение отговаря дадена заявка в целия микс от заявки, толкова по-голяма е печалбата от нейната оптимизация. Това е просто уравнение – ако една заявка е отговорна за 50% от общото време за изпълнение, правенето й 10 пъти по-бързо ще даде много по-добър резултат от оптимизирането на заявка, която е отговорна само за 1% от общото време за изпълнение.
ClusterControl може да ви помогне да отговорите на такива въпроси, но първо трябва да се уверим, че мониторът на заявките е активиран. Можете да превключите Монитора на заявките на ВКЛЮЧЕНО под страницата Монитор на заявки. Освен това можете да конфигурирате опцията „Дълго време на заявка“ и „Заявки в регистрационни файлове, които не използват индекси“ в Настройки, за да отговарят на вашето работно натоварване:
Мониторът на заявки в ClusterControl работи в два режима, в зависимост от това дали имате налична схема на производителност с необходимите данни за изпълняваните заявки или не. Ако е налична (и това е вярно по подразбиране в MySQL 5.6 и по-нови), схемата за изпълнение ще се използва за събиране на данни от заявка, като се минимизира въздействието върху системата. В противен случай ще се използва бавният дневник на заявките и се използват всички настройки, видими на горната екранна снимка. Те са доста добре обяснени в потребителския интерфейс, така че няма нужда да го правите тук. Когато Мониторът на заявки използва схема на производителност, тези настройки не се използват (с изключение на включване/изключване на Монитора на заявки за активиране/деактивиране на събирането на данни).
Когато потвърдите, че Query Monitor е активиран в ClusterControl, можете да отидете на Query Monitor -> Top Queries, където ще ви бъде представен екран, подобен на следния:
Това, което можете да видите тук, е списък с най-скъпите заявки (по отношение на времето за изпълнение), които удрят нашия клъстер. Всеки от тях има някои допълнителни подробности - колко пъти е било изпълнено, колко реда са били проверени или изпратени на клиента, колко е варирало времето за изпълнение, колко време клъстерът е прекарал за изпълнение на даден тип заявка. Заявките са групирани по тип заявка и схема.
Може да се изненадате да разберете, че основното място, където се изразходва времето за изпълнение, е заявка „COMMIT“. Всъщност това е доста типично за бързи OLTP заявки, изпълнявани в клъстер Galera. Извършването на транзакция е скъп процес, защото трябва да се случи сертифициране. Това води до това, че COMMIT е една от най-отнемащите време заявки в микса от заявки.
Когато щракнете върху заявка, можете да видите пълната заявка, максимално време за изпълнение, брой събития, някои общи съвети за оптимизация и изход EXPLAIN за нея – доста полезно, за да идентифицирате дали нещо не е наред с нея. В нашия пример проверихме SELECT ... FOR UPDATE с голям брой проверени редове. Както се очаква, тази заявка е пример за ужасен SQL - JOIN, който не използва никакъв индекс. Можете да видите на изхода на EXPLAIN, че не се използва индекс, нито един от тях не се счита за възможен за използване. Нищо чудно, че тази заявка сериозно повлия на производителността на нашия клъстер.
Друг начин да получите известна представа за ефективността на заявката е да погледнете Монитор на заявки -> Отклонения на заявките. Това основно е списък със заявки, чиято производителност значително се различава от средната им.
Както можете да видите на горната екранна снимка, втората заявка отне 0,01116 s (времето е показано в милисекунди), където средното време за изпълнение за тази заявка е много по-малко (0,000142 s). Имаме също така допълнителна статистическа информация за стандартното отклонение и максималното време за изпълнение на заявката. Такъв списък със заявки може да изглежда не особено полезен - всъщност не е вярно. Когато видите заявка в този списък, това означава, че нещо е било различно от обичайното - заявката не е изпълнена в редовното време. Това може да е индикация за някои проблеми с производителността на вашата система и сигнал, че трябва да проучите други показатели и да проверите дали нещо друго се е случило по това време.
Хората са склонни да се фокусират върху постигането на максимална производителност, като забравят, че не е достатъчно да имате висока пропускателна способност - тя също трябва да бъде последователна. Потребителите обичат производителността да е стабилна – може да сте в състояние да изстискате повече транзакции в секунда от вашата система, но ако това означава, че някои транзакции ще започнат да спират за секунди, това не си струва. Разглеждането на хистограмата на заявките в ClusterControl ви помага да идентифицирате такива проблеми с последователността във вашия микс от заявки.
Приятно наблюдение на заявките!
PS.:За да започнете с ClusterControl, щракнете тук!
