Обозревая 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

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

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