LINUX.ORG.RU
решено ФорумAdmin

per file I/O


0

1

iotop и htop - показывают I/O для процесса. Нужно то же самое, но для файлов. Т.е. насколько интесивно используются произвольно выбранные файлы на диске. Для чего нужно: есть mysql сервер и ~1000 немаленьких таблиц в нем. Хочу узнать работа с какими из них сильнее всего нагружает винт.


Ответ на: комментарий от o

по strace я могу узнать сколько байт из файла было прочитано или записано в него?

дополню оппост - в iostat -xdk 5 есть %util. вот хочу как-то связать этот процент с активностью в таблицах. Как-то так.

fjoe
() автор топика
Ответ на: комментарий от fjoe

по strace я могу узнать сколько байт из файла было прочитано или записано в него?

Ну да, ты ведь видишь параметры вызываемых функций (-e trace=read,write). Можно их суммировать по ходу. Правда, это мне уже не кажется хорошей идеей :)

Подпишусь на тред, пожалуй.

o
()
Ответ на: комментарий от o
[root@db2 ~]# ps aux | grep mysqld
root     13843  0.0  0.0  65912  1376 ?        S    Apr21   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid
mysql    13911  105 48.3 8507412 7946528 ?     Sl   Apr21 166685:23 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock
root     15813  0.0  0.0   6008   640 pts/9    S+   08:34   0:00 grep mysqld

[root@db2 ~]# strace -e trace=read,write -p 13911
Process 13911 attached - interrupt to quit

Process 13911 detached
[root@db2 ~]# 

strace молчит, хотя в базе активность есть. ладно, это можно сделать немного проще с суммироваванием и сортировкой

inotifywatch -r /var/lib/mysql
но, как и в случае с strace, это всё косвенные значения. события открытия/закрытия чтения и изменения почти бесполезны. если я открою на 10Гб файл, буду его читать и начну вливать в него еще 20Гб - в счетчиках это покажет всего по +1 в каждом, а база встанет.

fjoe
() автор топика
Ответ на: комментарий от o

с -f работает, спасибо. почти весь выхлоп strace состоит из:

...
[pid  4233] read(620, "\3\n\t\t\tSELECT\t`userdb`.`account`"..., 241) = 241
[pid  4233] write(3, "\t\t227327878 Query       SELECT\t`"..., 261) = 261
...
т.е. SQL запросов к базе. в среднем их пару тысяч в секунду. иногда в пике до 10-15 тысяч. их можно как-то отфильтровать, оставив только обращение к реальным файлам?

fjoe
() автор топика
Ответ на: комментарий от fjoe

многие вызовы выглядят совсем нечитаемо

[pid  4233] write(57, "\1\0\0\2\376", 5) = 5
[pid  4233] read(57, "\t\0\0\3", 4)     = 4
...
[pid  4233] read(620, "\332\0\0\0", 4)  = 4

fjoe
() автор топика
Ответ на: комментарий от botkin

Еще как помогают. Дажее знаю что бы без них делал. с mytop не срослось - пользуюсь mtop, поглядываю на innotop. slow query log сложно использовать когда есть заведомо быстрые запросы(вставки в таблицу) и заведомо медленные(сбор статистики по нескольким таблицам с группировками и сортировками). Кроме того, запрос может оказаться медленым потому, что он сложный а не потому, что читает с диска. Таблицы могут быть закэшированы, а бОльшую часть времени выполнения будет занимать группировка(group by). Наоборот много легких вставок в таблицу я скорее всего не увижу в ни в show processlist ни в slow query log, а на диск это пишется.

fjoe
() автор топика
Ответ на: комментарий от fjoe

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

botkin
()

man auditctl. При должной сноровке ты сможешь настроить аудит операций с нужными тебе файлами, а затем проанализировать выхлоп. Одно можно сказать заранее - больше всего будет операций с файлом /var/log/.audit/audit.log (или где он там в твоей системе).

DonkeyHot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.