Обозревая 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.
Ура — виновник выявлен ! Что дальше ???
Далее я решил посмотреть, на каком конкретном запросе тормозит СУБД, для этого в /etc/my.cnf в секцию [mysqlq] были добавлены строчки
log-slow-queries=/tmp/mysql_slow_queries.log
long_query_time=10
и конечно же сам сервер был перезапущен service mysql-server restart
Опять же недолгое ожидание … и … поклёвка !
Оставил логироваться на ночь, утром смотрю файлик /tmp/mysql_slow_queries.log на предмет самого долгого Query_time
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 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, найденных мной в рунете.
5 комментариев на «“Вычисление нагрузки на сервер. Part 1 — MySQL”»
В принципе, если бы внимательнее погуглили, то проблему и без всех этих действий нашли. Виртуемарт постоянно ложит сервак при большой посещаемости.
Да, в Виртуемарт глюков хватает
Может и у меня та же проблема, потому как сайт то и дело ложится
Интересная статья, спасибо.
Подскажите есть ли на Denwer утилитки по вычислению медленных запросов?