Mysql Вопрос по статистике, нагрузке, iops, затраченным ресурсам, поиск самой жирной таблицы

[DiMA]

Есть инструменты типа лога медленных запросов, top, iotop и т.д., но они почти никакой полезной инфы не дают. Меня интересует, какая именно таблица создает наибольшую нагрузку на CPU/HDD по реальным затратам. Есть ли аналог iotop, чтобы тот считал не трафик ко всему диску или со всего процесса mysql, а к файлам/таблицам персонально? К примеру, делаю LOAD DATA CONCURRENT LOCAL INFILE, запрос отрабатывает почти мгновенно, но потом это вызывает огромное число дисковых операций по перезаписи таблицы, перестроению индекса и т.д. в результате база "лежит" и не в состоянии выполнять другие запросы к другим даже мелким таблицам за адекватное время.

 

[Yoskaldyr]

я вычислял по перформанс схеме, но это вообще не удобно, благо нужно было пару раз (юзал какую-то старую шпаргалку перконы, которая щас вообще не актуальна, т.к. перформанс схему полностью переделали и расширили в последних версих ) и вдвойне не удобно когда база еле ворочается и с трудом дает законнектиться.
так что если кто знает более удобные средства, то было бы неплохо узнать т.к. лично у меня такие проблемы бывают редко, но оооочень метко

 

[c0dex]

Посмотри на набор https://github.com/iovisor/bcc
Может быть найдешь подходящую утилитку на подобие https://github.com/iovisor/bcc/blob/master/tools/filetop_example.txt

 

[fixxxer]

Если конкретно mysql, то performance schema. При включенном history_long (или как его там) все вполне себе видно.

Если по io, то dstat чуть больше показывает, но все равно достаточно детализации не будет. Есть blktrace, есть /proc/sys/vm/block_dump, но это наверное наоборот слишком низкоуровнево будет. А вообще в procfs куча всякой фигни, надо только найти утилиту, которая что надо достает

 

[grigori]

какая именно таблица создает наибольшую нагрузку на CPU/HDD по реальным затратам

если смотришь на низком уровне - не обобщай тогда, индексы создают одну нагрузку, чтение из общей памяти - другую, чтение блоков с диска - третью, join-ы - четвертую, а LOAD DATA CONCURRENT - блокирует доступ к индексам в памяти пока они пересчитываются и переписываются, видимо, это на операции с индексами в схеме можно посмотреть