Аналогично, общий лог mysql тоже довольно сложен для быстрой обработки, нужно писать/искать обработчик, который бы показал разницу в количестве запросов/соединений в конкретные моменты или малые промежутки времени.

А еще вечером попробовали apache benchmark, в 2-х вариантах.
В первом варианте выполнялся простой скрипт, в котором открывалось и закрывалось соединение с mysql

ab -kc 150 -t 20 http://site.com/test_script.php (150 конкурентных соединений, каждую секунду, на интервале в 20 секунд)

mysql в таком сочетании поджирал до 200% CPU, потом нагрузка спадала почти мгновенно, как только отрабатывала команда ab

а вот в варианте ab -kc 150 -t 20 http://site.com/ потребление CPU подскакивало до 600-700%(это только mysql), top показывал 75%sy

очередь запросов завершилась где-то спустя 1,5-2 минуты после окончания теста.

В общем, решили увеличить еще thread_cahce_size, чтобы в него помещались 400 потоков хотя бы

После этого первый тест проходил вообще незамеченным, а вот второй все равно сопровождался потерями производительности, хоть и меньшими, чем при thread_cahce_size=128

Видимо, простыми изменениями конфигурации проблема не решается, так что наметили пути:
1. Переход на новый движок БД
не факт, что сильно поможет, но есть же исследование , где масштабируемость версий MySQL/Percona 5.6/5.7 существенно лучше, чем у 5.5, которая у нас на данный момент
2. Кэш, куда ж без него(к слову, мы уже один раз обожглись на плагине wp_supercache, поэтому это может быть самым последним пунктом)
3. Провести ревизию кода с упором на то, чтобы выкинуть лишние запросы, которые, в первом приближении таки существуют. К сожалению, процесс небыстрый, простым отключением плагинов не решается.