Блог на начинаещ сисадмин Откриване на лоши заявки в MySQL база данни

Идентифициране на "лоши" заявки в базата данни MySQL

Основната част от ресурсите на уеб сървъра (apache+nginx+php+mysql) се използват от MySQL. Понякога се случва MySQL да няма достатъчно ресурси по някаква причина, паметта е напълно задръстена, системата преминава в суап. За това са виновни дългите заявки, които натоварват много MySQL. И на мен ми се случи. След това ще ви кажа как да откриете проблема и как да му се противопоставите.

Има удобна помощна програма за наблюдение на системата, която може да се използва за наблюдение на системните ресурси.

# chmod +x mysql_processes # crontab -e */5 * * * * /root/mysql_processes

Сред заявките, които можете да видите много дълги, ще дам пример за средна заявка от една база данни: # cat /etc/mysql/processes.report 31/08/2014 12:30:01 Id User Host db Command Time State Info 329103 user localhost database Query 0 Изпращане на данни SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.language, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = 0 THEN a.created ELSE a.modified END като модифициран, a.modified_by, uam.name като modified_b y_name,CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hi ts, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore,CASE WHEN badca ts.id не е null THEN 0 ELSE a.state END AS state,c.title AS category _title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,(\nSELECT MA X(contact.id) AS id\nFROM tar_contact_detailsAS contact\nWHERE contact.published = 1 И contact.user_id = a.created_by) като contactid,parent.title като parent_title, parent.id като p parent_id, parent.path като parent_route, parent.alias като parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS рейтинг, v.rating_count като rating_count,c. published, CASE WHEN badcat s.id is null THEN c.published ELSE 0 END AS Parents_published\nFROM tar_content AS a\nLEFT JOIN tar_content_frontpage AS fp ON fp.content_id = a.id\nLEFT JOIN tar_categories AS c ON c.id = a.catid\nLEFT JOIN tar_users AS ua ON ua.id = a.created_by\nLEFT JOIN tar_users AS uam ON uam.id = a.modified_by\nLEFT JOIN tar_categories като родител ON parent.id = c.par ent_id\nLEFT JOIN tar_content_rating AS v ON a.id = v.content_id\nLEFT OUTER JOIN (ИЗБЕРЕТЕ cat.id като id ОТ tar_ca tegories AS cat JOIN tar_categories AS parent ON cat.lft МЕЖДУ parent.lft И parent.rgt WHERE parent.extension = 'com_content' И parent.published != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id\nWHERE a.access IN (1) AND c.access IN (1) И CASE W HEN badcats.id е null ТОГАВА a.state ELSE 0 END = 1 И a.featured = 0 И a.catid IN (85) И (a.publish_up = '0000-00-00 00:00:00' ИЛИ ​​a.publish_up = '2014-08-31 08:29:59')\nORDER BY a.created DE SC LIMIT 0, 3 329104

По този начин можете да търсите проблемни бази, но това е най-примитивният вариант. В интернет има отличен скрипт, който анализира MySQL с бавен журнал. Ако този лог не се знае, то препоръчвам да го зададете. # vim /etc/mysql/my.cnf . log_slow_queries = /var/log/mysql/mysql-slow.log

И така, качваме скрипт и анализираме нашия slow-log. # cd /tmp # wget http://www.maatkit.org/get/mk-query-digest # chmod +x mk-query-digest # ./mk-query-digest /var/log/mysql/mysql-slow.log

По извода на работата на скриптаможете да направите изводи за проблемни бази данни и заявки. След това трябва или да оптимизирате заявки, или бази данни.

---