.
29 сентября 2010

Вычисление нагрузки на сервер. Part 1 — MySQL

posted in NIX, Программирование |

Обозревая top процессов в период пиковой загрузки сервака, был неприятно удивлён нагрузкой на mysqld 50%-80% , таким образом мускул не только сам по себе давал нагрузку по процу — это ведь ещё влекло за собой более долгое пребывание в памяти httpd, который сам по себе не лёгок.

Сразу же созрел вопрос — какая падла ? :)

Чуток погуглив, было найдено решение mtop — утилита визуального контроля нагрузки на MySQL.

на  find /usr/ports -name mtop получаю
/usr/ports/databases/mtop -  ура, mtop в портах !
Ставлю

cd /usr/ports/databases/mtop/ && make install clean

Запускаю и наблюдаю

mtop -dbu USER -p PASS

Результат не заставил себя ждать, через несколько секунд  я наблюдал пожелтение, а потом и покраснение строки запроса, одним из параметров которой был host.

Ура — виновник выявлен !  Что дальше ???

Далее я решил посмотреть, на каком конкретном запросе тормозит СУБД, для этого  в <strong>/etc/my.cnf</strong> в секцию <strong>[mysqlq]</strong> были добавлены строчки

log-slow-queries=/tmp/mysql_slow_queries.log
long_query_time=10

и конечно же сам сервер был перезапущен service mysql-server restart

Опять же недолгое ожидание ...  и ... поклёвка !
Оставил логироваться на ночь, утром смотрю файлик /tmp/mysql_slow_queries.log на предмет самого долгого Query_time

# Time: 100928  9:48:43
# User@Host: user[user] @ localhost []
# Query_time: 39.222651  Lock_time: 0.000258 Rows_sent: 20  Rows_examined: 7432
SET timestamp=1285660123;
SELECT DISTINCT `product_name`,`products_per_row`,`category_browsepage`,`category_flypage`,`jos_vm_category`.`category_id`,
`jos_vm_product`.`product_id`,`product_full_image`,`product_thumb_image`,`product_s_desc`,`product_parent_id`,`product_publish`,`product_in_stock`,`product_sku`, `product_url`, `product_weight`,`product_weight_uom`,`product_length`,`product_width`,`product_height`,`product_lwh_uom`,`product_in_stock`,`product_available_date`,`product_availability`,`jos_vm_product`.`mdate`, `jos_vm_product`.`cdate`
FROM (`jos_vm_product`, `jos_vm_category`, `jos_vm_product_category_xref`,`jos_vm_shopper_group`)
LEFT JOIN `jos_vm_product_price` ON `jos_vm_product`.`product_id` = `jos_vm_product_price`.`product_id`
WHERE (`jos_vm_product_category_xref`.`product_id`=`jos_vm_product`.`product_id` OR `jos_vm_product_category_xref`.`product_id`=`jos_vm_product`.`product_parent_id`)
 AND `jos_vm_product_category_xref`.`category_id`=`jos_vm_category`.`category_id`
 AND `jos_vm_product_category_xref`.`category_id`=20
 AND ((`jos_vm_product`.`product_id`=`jos_vm_product_price`.`product_id` AND `jos_vm_shopper_group`.`shopper_group_id`=`jos_vm_product_price`.`shopper_group_id`) OR `jos_vm_product_price`.`product_id` IS NULL)
 AND `jos_vm_shopper_group`.`default` = 1
 AND `product_parent_id`=0
 AND `product_publish`='Y'
 AND `category_publish`='Y'
 GROUP BY `jos_vm_product`.`product_sku`
 ORDER BY `jos_vm_product`.`product_name` ASC LIMIT 120, 20;

Собственно — на этом расследование окончено — код запроса «затормаживающий» систему выявлен, далее уже этап оптимизации кода, запросов и БД конкретного хоста, в данном случае VirtueMart.

P.S. В принципе можно попробовать оптимизировать настройки MySQL — но лично мне это не помогло, у меня всё и так было настроено с небольшими отличиями от советов по оптимизации MYSQL, найденных мной в рунете.

Яндекс.Метрика