Какво да проверите дали използването на паметта на MySQL е високо

Един от ключовите фактори за производителния MySQL сървър на база данни е добро разпределение и използване на паметта, особено когато се изпълнява в производствена среда. Но как можете да определите дали използването на MySQL е оптимизирано? Разумно ли е да има високо използване на паметта или изисква фина настройка? Ами ако се сблъскам с изтичане на памет?

Нека да покрием тези теми и да покажем нещата, които можете да проверите в MySQL, за да определите следи от високо използване на паметта.

Разпределение на паметта в MySQL

Преди да се задълбочим в конкретното заглавие на темата, ще дам кратка информация за това как MySQL използва паметта. Паметта играе значителен ресурс за скорост и ефективност при обработка на едновременни транзакции и изпълнение на големи заявки. Всяка нишка в MySQL изисква памет, която се използва за управление на клиентски връзки и тези нишки споделят една и съща основна памет. Променливи като thread_stack (стек за нишки), net_buffer_length (за буфер за връзка и буфер за резултати) или с max_allowed_packet, където връзката и резултатът ще се увеличават динамично до тази стойност, когато е необходимо, са променливи, които влияят върху използването на паметта. Когато нишката вече не е необходима, паметта, разпределена за нея, се освобождава и се връща в системата, освен ако нишката не се върне обратно в кеша на нишката. В този случай паметта остава разпределена. Обединяването на заявки, кеширането на заявките, сортирането, кеша на таблици, дефинициите на таблици изискват памет в MySQL, но те се приписват със системни променливи, които можете да конфигурирате и задавате.

В повечето случаи специфичните за паметта променливи, зададени за конфигурация, са насочени към специфична конфигурация, базирана на съхранение, като MyISAM или InnoDB. Когато екземпляр на mysqld се появи в хост системата, MySQL разпределя буфери и кешове, за да подобри производителността на операциите на базата данни въз основа на зададените стойности, зададени в конкретна конфигурация. Например, най-често срещаните променливи, които всеки DBA ще зададе в InnoDB, са променливи innodb_buffer_pool_size и innodb_buffer_pool_instances, които и двете са свързани с разпределението на паметта на буферния пул, който съдържа кеширани данни за InnoDB таблици. Желателно е, ако имате голяма памет и очаквате да обработвате големи транзакции, като зададете innodb_buffer_pool_instances за подобряване на едновременността чрез разделяне на буферния пул на множество екземпляри на буферния пул.

Докато за MyISAM, трябва да се справите с key_buffer_size, за да се справите с количеството памет, което ще обработва ключовият буфер. MyISAM също така разпределя буфер за всяка едновременна нишка, която съдържа структура на таблицата, колонни структури за всяка колона и буфер с размер 3 * N се разпределят (където N е максималната дължина на реда, без да се броят BLOB колоните). MyISAM също така поддържа един допълнителен буфер на ред за вътрешна употреба.

MySQL също разпределя памет за временни таблици, освен ако не стане твърде голяма (определя се от tmp_table_size и max_heap_table_size). Ако използвате таблици MEMORY и променливата max_heap_table_size е настроена много високо, това също може да отнеме голяма памет, тъй като системната променлива max_heap_table_size определя колко голяма може да нарасне таблицата и няма преобразуване във формат на диска.

MySQL също има схема за ефективност, която е функция за наблюдение на MySQL дейности на ниско ниво. След като това е активирано, той динамично разпределя памет постепенно, като мащабира използването на паметта до действителното натоварване на сървъра, вместо да разпределя необходимата памет по време на стартиране на сървъра. След като паметта е разпределена, тя не се освобождава, докато сървърът не бъде рестартиран.

MySQL може също да бъде конфигуриран да разпределя големи области памет за своя буферен пул, ако се използва Linux и ако ядрото е активирано за поддръжка на големи страници, т.е. чрез използване на HugePages.

Какво да проверите, след като паметта на MySQL е висока

Проверка на изпълняваните заявки

Много е обичайно за MySQL DBA да докоснат първо какво се случва с работещия MySQL сървър. Най-основните процедури са проверка на списък с процеси, проверка на състоянието на сървъра и проверка на състоянието на механизма за съхранение. За да направите тези неща, по принцип, трябва просто да стартирате поредицата от заявки, като влезете в MySQL. Вижте по-долу:

За да видите текущите заявки,

mysql> ПОКАЖЕТЕ [ПЪЛЕН] СПИСЪК НА ПРОЦЕСИТЕ; 

Преглеждането на текущия списък с процеси разкрива заявки, които се изпълняват активно или дори неактивни или спящи процеси. Много е важно и е важна рутина да имате запис на заявките, които се изпълняват. Както е отбелязано за това как MySQL разпределя памет, изпълняваните заявки ще използват разпределението на паметта и могат драстично да причинят проблеми с производителността, ако не бъдат наблюдавани.

Преглед на променливите за състоянието на MySQL сървъра,

mysql> ПОКАЖЕТЕ СТАТУСА НА СЪРВЪРА\G 

или филтрирайте конкретни променливи като

mysql> ПОКАЖЕТЕ СТАТУС НА СЪРВЪРА КЪДЕ ИМЕ на променлива В ('', 'var2'...); 

Променливите на състоянието на MySQL служат като ваша статистическа информация, за да вземете метрични данни, за да определите как се представя MySQL, като наблюдавате броячите, дадени от стойностите на състоянието. Тук има определени стойности, които ви дават поглед върху използването на паметта. Например, проверка на броя на нишките, броя на кеша на таблици или използването на буферния пул,

Преглед на състоянието на монитора на двигателя, например състоянието на InnoDB

mysql> ПОКАЖЕ СТАТУС НА INNODB\G на двигателя 

Състоянието на InnoDB също така разкрива текущото състояние на транзакциите, които обработва машината за съхранение. Той ви дава размера на купчина на транзакция, адаптивни хеш индекси, разкриващи нейното използване на буфера, или ви показва информацията за буферния пул на innodb точно като примера по-долу:

---ТРАНЗАКЦИЯ 10798819, АКТИВНО 0 секунди вмъкване, нишка, декларирана в таблици InnoDB 1201mysql в употреба 1, заключена(и) 11 заключваща структура(и), размер на купа 1136, 0 заключване(и) на ред(и), отмяна на записи в дневника 880 идентификатор на нишка 68481, манипулатор на нишка на ОС 139953970235136, идентификатор на заявка 681821 корен на локален хост копие в tmp tableALTER TABLE NewAddressCode2_2 ENGINE=INNODB…-------------------------- -----------ВМЕСЕТЕ БУФЕР И АДАПТИВЕН ХЕШ ​​ИНДЕКС-------------------------------- ----Ibuf:размер 528, свободен списък len 43894, сег размер 44423, 1773 обединени операции:вмъкване 63140, знак за изтриване 0, изтриване 0 отхвърлени операции:вмъкване 0, изтриване на знак 0, изтриване 0 Размер на хеш таблицата 553193, node heap има 1 буфер(и) Размер на хеш таблица 553193, купчина на възел има 637 буфер(и) Размер на хеш таблица 553193, купчина на възел има 772 буфер(и) Размер на хеш таблица 553193, купчина на възли има 1239 буфер(и) Размер на хеш таблица 3, node9 heap има 2 буфера(и)Размер на хеш таблица 553193, купчина на възел има 0 буфер(и)Размер на хеш таблица 553193, купчина на възел има 1 буфер(и) Размер на хеш таблица 5531 93, купчина възел има 1 буфер(и) 115320.41 хеш търсения/и, 10292.51 търсения без хеш/и.....----------------------BUFFER POOL И ПАМЕТ--------------------- Общо разпределена голяма памет 2235564032 Разпределена памет на речника 3227698 Вътрешни хеш таблици (постоянен фактор + променлив фактор) Адаптивен хеш индекс 78904768 (35404352 + 43500416) Страница хеш 277384 (само буфер пул 0) Кеш на речника 12078786 (8851088 + 3227698) Файлна система 1091824 (812272 + 279552) СИСТЕМАТА НА ЛОКТИЯ 0322504 (5313416 + 9088) Система за възстановяване 0 (0 + 0) Буфер Пули 131056Buffer Pool, buffers 8303Database pages 120100Old database pages 44172Modified db pages 108784Pending reads 0Pending writes:LRU 2, flush list 342, single page 0Pages made young 533709, not young 1819623823.06 youngs/s, 1706.01 non-youngs/sPages read 4104, created 236572, written 44122338.09 reads /s, 339.46 creates/s, 1805.87 writes/s Скорост на попадане в буферния пул 1000 / 1000, скорост на младопроизводство 12 / 1000, а не 5 / 1000 страници, прочетени напред 0,00/s, изгонени без достъп 0,00/s, произволно четене напред 0,00/sLRU len:120100, unzip_LRU:40 len:5 [8096], разархивирайте sum[0]:cur[0]… 

Друго нещо, което трябва да добавите, можете също да използвате схема за производителност и sys схема за наблюдение на консумацията и използването на паметта от вашия MySQL сървър. По подразбиране повечето инструменти са деактивирани по подразбиране, така че има ръчни неща, които трябва да направите, за да използвате това.

Проверете за размяна

И в двата случая е вероятно MySQL да разменя паметта си на диск. Това често е много често срещана ситуация, особено когато MySQL сървърът и основният хардуер не са настроени оптимално успоредно на очакваните изисквания. Има някои случаи, в които търсенето на трафик не е предвидено, паметта може да нараства все повече, особено ако се изпълняват лоши заявки, което води до консумиране или използване на много място в паметта, което води до влошаване на производителността, тъй като данните се избират на диска вместо в буфера. За да проверите за размяна, просто изпълнете командата freemem или vmstat точно както по-долу,

[[email protected] ~]# безплатни -m общо използван безплатен споделен buff/cache availableMem:3790 2754 121 202 915 584 Размяна:1535 39 1496[[email protected] ~]#procssstat - 5 ----------памет---------- ---размяна-- -----io---- -система-- ------процесор-- --- r b swpd безплатен buff cache si so bi bo in cs us sy id wa st 2 0 40232 124100 0 937072 2 3 194 1029 477 313 7 2 91 1 0 0 0 0 12 9 7 0 32 0 12 9 7 84 0 0 1 0 40232 124184 0 937212 0 0 0 35 751 478 6 1 93 0 0 0 0 40232 123688 0 937228 0 0 0 15 736 487 5 1 94 0 0 0 0 40232 123912 0 937220 0 0 3 74 1065 729 8 2 89 0 0 

Можете също да проверите с помощта на procfs и да съберете информация, като например да отидете в /proc/vmstat или /proc/meminfo.

Използване на Perf, gdb и Valgrind с Massif

Използването на инструменти като perf, gdb и valgrind ви помага да се задълбочите в по-усъвършенстван метод за определяне на използването на паметта на MySQL. Има моменти, когато интересен резултат се превръща в мистерия за решаване на консумацията на памет, което води до вашето недоумение в MySQL. Това се превръща в необходимостта от повече скептицизъм и използването на тези инструменти ви помага да проучите как MySQL използва паметта за обработка от разпределянето й до използването й за обработка на транзакции или процеси. Това е полезно например, ако наблюдавате, че MySQL се държи необичайно, което може да причини лоша конфигурация или да доведе до констатации за течове на памет.

Например, използването на perf в MySQL разкрива повече информация в отчет на системно ниво:

[[email protected] ~]# perf report --input perf.data --stdio# За да покажете информацията за заглавката на perf.data, моля, използвайте опции --header/--header-only.# ## Общо загубени проби:0## Извадки:54K от събитието 'cpu-clock'# Брой събития (приблизително):13702000000## Команда за служебни задачи Символ на споделен обект # ........ ...... ........................................................ ................................................................ ................................................................ ................................................................ ...............# 60.66% mysqld [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore 2.79% mysqld libc-2.17.so [.] __memcpy_ssse3 2.54% mysqld mysqld [.] mp ha_ke. mysqld [vdso] [.] __vdso_clock_gettime 1,05% mysqld mysql d [.] rec_get_offsets_func 1.03% mysqld mysqld [.] row_sel_field_store_in_mysql_format_func 0.92% mysqld mysqld [.] _mi_rec_pack 0.91% mysqld [kernel.kallsyms] [k] finish_task_switch 0.90% mysqld mysqld [.] row_search_mvcc 0.86% mysqld mysqld [.] decimal2bin 0.83 % mysqld mysqld [.] _mi_rec_check…. 

Тъй като това може да е специална тема за копаене, предлагаме ви да разгледате тези наистина добри външни блогове като ваши препратки, Perf Основи за MySQL профилиране, Намиране на проблеми с MySQL Scaling Използването на perf или да научите как да отстраняване на грешки с помощта на valgrind с масив.

Ефективен начин за проверка на използването на паметта на MySQL

Използването на ClusterControl облекчава всякакви неудобни рутинни действия, като преглеждане на вашите runbooks или дори създаване на ваши собствени плейбуки, които ще доставят отчети за вас. В ClusterControl имате табла за управление (използвайки SCUMM), където можете да имате бърз преглед на вашия MySQL възел(и). Например, разглеждане на таблото за управление MySQL General,

можете да определите как се представя възелът MySQL,

Виждате, че изображенията по-горе разкриват променливи, които оказват влияние върху използването на паметта на MySQL. Можете да проверите как са показателите за кешове за сортиране, временни таблици, свързани нишки, кеш на заявки или машини за съхранение innodb буферен пул или ключов буфер на MyISAM.

Използването на ClusterControl ви предлага помощен инструмент на едно място, където можете също да проверявате изпълняваните заявки, за да определите онези процеси (заявки), които могат да повлияят на високото използване на паметта. Вижте по-долу за пример,

Преглеждането на променливите на състоянието на MySQL е тихо лесно,

Можете дори да отидете на Performance -> Innodb Status, за да разкриете текущото състояние на InnoDB на възлите на вашата база данни. Също така в ClusterControl се открива инцидент, той ще се опита да събере инцидент и ще покаже историята като отчет, който ви предоставя състоянието на InnoDB, както е показано в предишния ни блог за MySQL Freeze Frame.

Резюме

Отстраняването на неизправности и диагностицирането на вашата MySQL база данни при съмнение за високо използване на паметта не е толкова трудно, стига да знаете процедурите и инструментите, които да използвате. Използването на правилния инструмент ви предлага повече гъвкавост и по-бърза производителност за предоставяне на поправки или решения с шанс за по-голям резултат.