И в очередной раз возвращаясь к теме мониторинга io. Как же найти самые грузящие систему файлы?

Посмотри на inotifywatch

мысли такие:
если бы десяток файлов были бы концентрированно узким местом IO, то они лежали бы в дисковом кэше, а раз нагрузка высокая, то значит она размазана примерно ровным слоем по всем используемым файлам; грубо говоря, твоего объема дискового кеша хватает, чтобы снизить IO до 30%

главное, не понятно, что ты будешь делать с топом файлов, к которым идет максимально интенсивный доступ? положишь их в память или на ssd? так они и так в кэше

Посмотри на inotifywatch

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

если бы десяток файлов были бы концентрированно узким местом IO, то они лежали бы в дисковом кэше

Тут, скорее, вопрос в _категориях_ файлов. Каждый читается, может, и раз в час, но их может быть 100000 одного типа. Понять, какие конкретно категории тормозят работу — это уже половина дела. Дальше может быть много способов оптимизации.

так они и так в кэше

Нет, увы. Кеширование в Linux плохо работает в случае большого числа разнородных файлов. Кеш тратится на одноразовые обращения, вышибающие что-то старое, но регулярное. В результате машина и уходить в глубокий io. Хотя, например, перенос активно используемых файлов в tmpfs может разгрузить систему эффективнее штатного кеширования.

Можно его на отдельные файлы или директории натравить.
Ну и эвент поставить на запись-модификацию.

Однако, сделал сортировку по числу обращений fatrace, обнаружил, что к одной таблице БД за 5 секунд 39 тыс. обращений :) Следующая на очереди — 2 тыс, потом — /lib/x86_64-linux-gnu/ld-2.19.so с всего 600 обращениями.

Вот и найдено одно местечко для оптимизации.

Можно его на отдельные файлы или директории натравить.

Да нет, оно ничем не лучше fatrace тут. Просто не даёт ответа о нагрузке, только про число обращений. А они не совсем прямо коррелируют.

Кеширование в Linux плохо работает в случае большого числа разнородных файлов. Кеш тратится на одноразовые обращения, вышибающие что-то старое, но регулярное.

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

реальный выход (на уровне админа, а не программиста) — это увеличение общей производительности IO-подсистемы: добавить памяти, поставить более быстрые диски

покажи свой free

Кстати, не буквально, но близко к теме. Есть у кого-то мысли, от чего в mdadm может быть неравномерная нагрузка на диски? На sda она раза в два больше, чем на sdb. raid1 (mirror). Диски абсолютно одинаковые, smartctl одинаковый, дисковый массив в полном порядке, все параметры симметричные. Но sda грузится вдвое больше. Когда sda загружен на 100%, sdb загружен на 50-60%.

Посмотри в сторону SystemTap. Похоже это то, что тебе нужно.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html...

в htop нет?

не надо думать, что ты всех умнее

Не надо думать, что linux-кеш решает все проблемы :)

если запинить в памяти файлы, которые читаются раз в час, то на все остальное этой памяти останется меньше

Остальное можно вообще не кешировать, потому что оно нужно раз в сутки.

Я это на практике не раз проходил — в случае большого количества разнородной мелочи, объёмом больше оперативки, переброс части самых активно используемых файлов в tmpfs в разЫ разгружает дисковую подсистему. Кеш в Linux в таких случаях реально работает очень плохо.

реальный выход (на уровне админа, а не программиста) — это увеличение общей производительности IO-подсистемы: добавить памяти, поставить более быстрые диски

Это не решается в имеющихся условиях.

Посмотри в сторону SystemTap.

Смотрел, но так и не понял, как пользоваться. Щупал https://sourceware.org/systemtap/SystemTap_Beginners_Guide/iotimesect.html#io... — оно просто долго тормозит, потом вываливает кучу ошибок.

сделал сортировку по числу обращений fatrace, обнаружил, что к одной таблице БД за 5 секунд 39 тыс. обращений :)

ну ты смешной :)
не каждое обращение приводит к io

Вот и найдено одно местечко для оптимизации.

интересно, как ты собираешься это оптимизировать?

Когда sda загружен на 100%, sdb загружен на 50-60%.

Как именно ты смотришь нагрузку на диски в процентах?

в htop нет?

Он не мониторит дисковую активность вообще, не то что файловую :)

Когда sda загружен на 100%, sdb загружен на 50-60%.

когда запрос на чтение меньше размера страйпа, то нет смысла читать оба диска, т.к. такой запрос не параллелится

Как именно ты смотришь нагрузку на диски в процентах?

atop, munin

...

Забавно, nmon показывает, что диски симметрично загружены и на чтение, и на запись, а iostat показывает, что sda всегда загружен на чтение, а sdb — всегда на запись:

 $ sudo iostat
Linux 3.13.0-77-generic (htz)   10.03.2016      _x86_64_        (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12,05    0,21    2,82   38,09    0,00   46,83

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             264,70     48399,29      1956,10  641845214   25940729
sdb             178,53       271,41     48144,72    3599245  638469217
md0               0,84         0,41         2,93       5480      38836
md1               0,06         0,35         0,00       4592         29
md2             244,02      2481,45      1953,56   32907637   25907104

ну ты смешной :)
не каждое обращение приводит к io

Ну так я об этом с самого начала темы и пишу. Но, в отличие от винды, как оценить реальную загрузку по файлам — не знаю.

интересно, как ты собираешься это оптимизировать?

Например, попробую определить конкретный тип самого частого запроса и посадить его в redis-кеш. Или, может, если структура документов позволит, вообще на статический кеш перевести. Надо смотреть, откуда лезут такие частые запросы.

когда запрос на чтение меньше размера страйпа, то нет смысла читать оба диска, т.к. такой запрос не параллелится

Речь о распределении параллельных запросов. Один — с sda, второй — с sdb.

Но, как писал выше, разные инструменты выдают разные данные. Х.з., кому верить :)

Ты случайно не это хочешь?

# sysdig -c topfiles_time 

Time      Filename  
------------------------------
403us     /dev/urandom
267us     /dev/input/event4
84us      /dev/dri/card0
63us      /tmp/vte7IZWFX (deleted)
34us      /tmp/vteL7ZWFX (deleted)
20us      /proc/3467/task/3467/stat
13us      /dev/ptmx
11us      /proc/16010/task/16010/st

sysdig

К iostat'у у меня больше доверия. ИМХО

а iostat показывает, что sda всегда загружен на чтение, а sdb — всегда на запись

Ребилд массива? Или может с одним диском начинаются проблемы

sisdig?

Речь о распределении параллельных запросов. Один — с sda, второй — с sdb.

приведенные тобой проценты как раз и говорят, что распараллеливание происходит не на уровне запросов, а каждый запрос делится на куски размером страйп-сайз, и выполняется параллельно на двух дисках (четные блоки на sda, нечетные — на sdb), и соответственно не всегда для четного блока есть нечетный блок

Ты случайно не это хочешь?

Похоже на то, что нужно :) Поставил, буду щупать.

Интересно, с чего у меня в топе /dev/fuse, хотя fuse-mount только один (amazon cloud drive) и сейчас никаким процессом не используется...

Что-то навскидку не найду, как интервал обновления увеличить.

Ребилд массива?

Блин. Глаз замылился, хотя несколько раз смотрел. А сейчас вывел статус, чтобы сюда отправить, а там, действительно, resync идёт.

atop, munin

Тут скорее вопрос в том, откуда они берут потолок в 100%.

Тут скорее вопрос в том, откуда они берут потолок в 100%.

ЕМНИП, 100% - это ситуация, когда очередь диска забита на 100% ( не в ядре, а именно в контроллере диска, т.е. он больше запросов не примет, пока не выполнит текущие )

Здесь ТМО во все поля

100% - это ситуация, когда очередь диска забита на 100%

Неправда твоя. 100% означает, что в любое время диск выполняет как минимум один запрос. Очередь здесь ни при чем.

Может у тебя зеркало синхронизируется sda -> sdb. Ибо с md2 читается в 20 раз меньше, чем с sda (тоже и с записью).

sysdig -c topfiles_time

впервые за лет 5, наверное, встречаю что-то такое, что намертво вешает линукс, полностью, только ребут спасает.

В RAID1, если читает один поток, используется один диск, если нужно что бы при чтении в один поток использовались оба диска делай raid10 на двух дисках с far=2.